---
title: "Conclusion: OWASP is for everyone"
url: https://appsecpodcast.com/conclusion-owasp-is-for-everyone/
date: 2017-12-05
duration_seconds: 1901
topics: ["Threat Modeling", "OWASP Top 10"]
audio: https://www.buzzsprout.com/1730684/episodes/8122701-conclusion-owasp-is-for-everyone.mp3
transcript: true
---

# Conclusion: OWASP is for everyone

*December 5, 2017 · 32 min*

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122701-conclusion-owasp-is-for-everyone.mp3)

## Show notes

Why does OWASP matter beyond its famous Top 10 list? The Season 2 finale revisits guests who demonstrate the breadth of the foundation’s work. John Melton explains AppSensor, Andrew van der Stock and Brian Glas discuss Top 10 governance and data, Mike Goodwin walks through Threat Dragon, Jim Manico and Katy Anton explain Proactive Controls, Tanya Janca and Nicole Becher introduce DevSlop, and Tin Zaw describes ModSecurity. The clips connect guidance, tools, standards, training applications, and community participation. Chris and Robert frame the episode as an invitation: OWASP is not reserved for established security experts. Developers, testers, project leaders, documenters, and newcomers can all learn from the projects and contribute to making them more useful.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Chris Romeo and Robert Hurlbut:  
→ [Chris Romeo on LinkedIn](https://www.linkedin.com/in/chrisromeo-appsec)  
→ [Robert Hurlbut on LinkedIn](https://www.linkedin.com/in/roberthurlbut)

Mentioned in this episode:  
→ [OWASP Top 10](https://owasp.org/www-project-top-ten/)  
→ [OWASP AppSensor](https://owasp.org/www-project-appsensor/)  
→ [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/)  
→ [OWASP Top 10 Proactive Controls](https://top10proactive.owasp.org/)  
→ [OWASP DevSlop](https://owasp.org/www-project-devslop/)  
→ [Pixi (DevSlop)](https://github.com/DevSlop/Pixi)  
→ [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)  
→ [Microsoft Threat Modeling Tool](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool)

Chapters:  
00:00 Season 2 and the breadth of OWASP  
00:50 John Melton on OWASP AppSensor  
04:55 Andrew van der Stock and Brian Glas on Top 10 governance  
09:54 Balancing data for the OWASP Top 10  
12:55 Mike Goodwin on OWASP Threat Dragon  
14:24 The Threat Dragon workflow  
17:14 Jim Manico and Katy Anton on Proactive Controls  
23:12 Tanya Janca and Nicole Becher on DevSlop  
27:25 Tin Zaw on ModSecurity  
30:19 OWASP is for everyone

## Transcript

*5,149 words · assemblyai*

**0:05 Chris Romeo:** The Application Security Podcast. Here we go. Hey folks, this is Chris, and welcome to the conclusion of season 2 of the Application Security Podcast. Season 2 has been primarily dedicated to the world of OWASP, and so in this roundup episode, we're going to share some of our favorite clips from this season. And this season took us all across the United States to different conferences interviewing people, and so we hope you enjoy, and please look forward to season 3 in early 2018. We begin our review of Season 2 with a clip from Episode 2 where we talk about insufficient attack protection and how that was almost added into the OWASP Top 10. All right, so here's A7, the, uh, the first new one to the list here. This is insufficient attack protection, and like we said already in this conversation, that this is one that's really draw— has, has drawn a lot of controversy in the industry. And so this is the idea that the application should have something within it to help it detect, log, respond to, and even block security attacks that are happening. Because security, the way we've approached it for the last 20 years, as long as I've been doing this, is security from the information security side has been about putting devices some level or some number of metal boxes with network interfaces that provide all of the protection that we need, whether that's DDoS protection, which then feeds to my firewall, which then feeds to my IPS, which then feeds to something else and something else. And so this is the idea that some of that protection capability has to be brought into the actual application itself, which I actually believe in this because when you think about trying to do things at scale, That's one of the things that I learned over— as I've kind of had a chance to explore some very high-end or high-performing websites that are passing gigabits of traffic per second. There's not enough firewalls in the world to keep up with a site that's pushing gigabits per second of data consistently throughout all the time. So you've got to have something else to do security there, and I think that's what insufficient attack protection is trying to do. Right.

**2:51 Robert Hurlbut:** Yeah, so like you said, some kind of inherent in the application itself understanding some attack patterns, understanding what's happening, and getting real-time understanding of what's happening with your application so that as it's running it— I could think of, for example, out of OWASP, there's the AppSensor that does this kind of thing as well, where you build it in and it can detect certain things. That's what we're talking about, is just ways of building in detection of patterns that may be seen in the code so that— and then determine what you do next.

**3:31 Chris Romeo:** Yeah. And I mean, some of the controversy, I guess, that surrounded this is— so Jeff Williams and Dave Wickers are the 2 project leads for the OWASP Top 10. And Jeff Williams actually is the CTO of a company called Contrast Security. And they're building, they have a product that provides that in-app instrumentation type of approach to detecting attacks and responding to attacks in real time. And so that's where some of the controversy I think is coming from is because people are saying, well, you know, this is something that's like a self-serving type of thing. And I really don't think it is though. And I have the benefit, I had a chance to work with Jeff and Dave. back in the '90s at a small security company for a few years. And so I really don't think, I don't think they're trying to game the system here at all. I think this is a necessary move forward for the OWASP Top 10 because this is where security has to go closer into the applications. So I think that this is, this is something that, that really does have to happen for the industry to move forward. Robert and I had a chance to sit down with the new OWASP Top 10 project leadership team at AppSec USA and talk about what's transpired with this project over the last number of months.

**4:55 Robert Hurlbut:** In late May, I was approached by Dave Wickers. There was a lot of criticism of the first release candidate of the OWASP Top 10, which seemed to pop out of nowhere. I had a couple of extra items in there that people were, for whatever reasons, I'm not going to get into the drama cycle of that particular thing, but the 2 major thrusts of it were, these aren't top 10 vulnerabilities, or, these are controls, they don't belong, or, I don't like Company X. And sometimes all 3 of those wrapped up together. And there was a lot of pushback. I mean, way more than we've ever seen before. And I think to a certain point, Dave and Jeff felt that they weren't able to contribute any further and they were looking for someone to put it back on the rails and get the project released. And so they said, do you want to look after it? And I thought about it for about 3 seconds and said yes. But then I started delving into what this actually meant and I realized that there was a whole bunch of things happening. One is that I think many of the people on Twitter and the social media drama cycle We're very interested in improving the governance. So one of the very first acts I did is I appointed Neil and Torsten Giggler, who'd basically been involved in the project for the last 7 years, and Neil even further. And you, 2004? 2004, I think, was the first one I worked on. So even longer than I've been involved in it, because, you know, I did the OS Top 10 2007, and when I realized how the sausage was made, I thought, this is not good. The reality of the situation is that this is the OWASP Top 10. Everyone likes and uses this. Everyone, for better or worse, uses it as an information security standard. It's not a security standard, but that's how it's used. We needed to get it back on track. So once we delved into some of the other reasoning, there's no data behind this. Brian did a fantastic set of blog entries And I think I'll let Brian talk about that, but effectively it really highlighted the fact that we didn't have the right answers right now and we needed to get that on track. And so in time we brought Brian on as a co-leader as well. So now we have 4 leaders. So I think we've actually dealt with the governance issue, which is I think many people got really upset that one company seemed to be pushing in the product type So what does that governance look like then right now?

**7:27 Chris Romeo:** Is there— is it like the 4 of you have to vote and decide, or what's the— that's something I'm fascinated as to. How are you going to do governance for this moving forward knowing what's happened in the past?

**7:38 Robert Hurlbut:** That's a very fine question. I think it's probably— we're just collegial at the moment. We haven't had to make any hard and fast decisions other than the release date. We've disagreed over the simple decisions.

**7:51 Chris Romeo:** actually.

**7:52 Robert Hurlbut:** But also balanced.

**7:54 Chris Romeo:** Right. But, you know, I think that was sort of part of the reason why so many people were brought on board is to make sure that no one person has undue influence of the project as it moves forward.

**8:06 Robert Hurlbut:** And I think that's really critical. I think we're working transparently, which is OWASP in a nutshell. Everything you see us do is in relation to a GitHub issue or a comment that's made somewhere that's traceable. We want to make sure that the end result of RC2 and the final version is because we've had community feedback, we've had data, we've had surveys. There's no more it's popping out fully formed. That's— those days are done. If we have good hard discussions where we disagree with each other, it's because it's difficult, not because it's easy. It's not because I'm saying this is the way it's going to be. We need to get to a place that if we're all in, or mostly in agreement, most of the community will probably back us. And they can see how we came to that decision as well.

**9:01 Chris Romeo:** How are you taking the kind of public comments? How is that handled? How does that impact your kind of thinking about I guess, I mean, I can say how you're gonna vote. It's not really a vote at this point, but it kind of is because you're, you're either saying, you know, we all agree or we disagree. How does the public kind of weigh into that? Because I don't see a day where we're gonna have a website and we all vote like, what do you think should be on the top 10? Well, I like these. Well, there is a website, right?

**9:27 Robert Hurlbut:** We have 516 responses, I think, um, from, from anonymous hopefully security professionals. I don't think my mom voted, but it's anonymous.

**9:40 Chris Romeo:** So to round out the OWASP Top 10 discussion, Brian Glass from the Top 10 leadership team describes how they use data analysis to influence the Top 10.

**9:54 Robert Hurlbut:** So we have 1, 2, 3 good-sized datasets, and I think a 4th potentially coming on top of the original one that we had. So we're no longer in the scenario where one dataset's dwarfing all of the other contributors, and it's far more balanced. But, and so now we have the task of trying to balance because it's a mixed set of data. Some of the data is driven by human testing assisted by tools, and some of the data is tool testing assisted by humans. And so trying to figure out— and to be honest, we probably won't be able to use all of the data because some of it will just—

**10:35 Chris Romeo:** Okay.

**10:35 Robert Hurlbut:** not fit in terms of a general, you know, based on criteria of can we compare this against each other. But I'm excited about the new set that we have because there's a whole lot more I think we can glean from it. It's one of the few times I've seen actually being able to build an aggregation of multiple large-scale vendors being able to contribute data.

**10:58 Chris Romeo:** So you're normalizing that data then into a standard format, which then So you can run all this data together and then really draw some good conclusions.

**11:07 Robert Hurlbut:** So the goal right now is to essentially try and build 2 views. And one is the more traditional that had been done before, and that's the aggregation of everything found per application. But what that does, and like if you've ever played with statistical averages, you hide a lot of things when you run averages. So the other thing that we've been getting is number of unique apps that the occurrence actually appears in one or more times, regardless of how many times it shows up, but just unique apps that that vulnerability actually shows up in, in the vendor data. And so I'm interested in that because that's a whole different level of incidence rate than looking at an aggregation altogether.

**11:50 Chris Romeo:** So what do you, what do you hope to get out of that number of unique apps? Is it I mean, what's— I guess what's the— yeah, what's the data point that you're going to be able to take away that'd be different from the big aggregation view?

**12:02 Robert Hurlbut:** So there's a difference between— so if, say for instance, if I have 50 applications and I— or 50,000 applications and I have 2 million cross-site scripting, then I have 40 cross-site scripting per application. But that's a very different picture than if I have 50,000 applications, only 8,000 of them contributed the 2 million Now all of a sudden I have 8,000 out of 50 had cross-site scripting and 42,000 didn't. That's a totally different picture of incidence rate for cross-site scripting across apps than trying to average out both totals.

**12:37 Chris Romeo:** Absolutely.

**12:38 Robert Hurlbut:** And human testers tend to say when they do like a pen test, they say you have cross-site scripting vulnerability in your application, right?

**12:45 Chris Romeo:** And that's sort of it.

**12:47 Robert Hurlbut:** They might list a couple of examples. But when you use some automated tester tool, it lists out hundreds or thousands of the same thing.

**12:55 Chris Romeo:** So it sort of really skews it to the things that static analysis checkers are good at if you start counting instances. In episode 6, we talk with Mike Goodwin about the OWASP Threat Dragon project. So Mike, what is the OWASP Threat Dragon?

**13:13 Robert Hurlbut:** Okay, well, first of all, it's, um, It's open source, as all the OWASP projects are, and it's a cross-platform threat modeling tool, so it's designed to work on any platform, be completely free. The emphasis of it is around making it enjoyable to use and simple to use, and also to interact well with the SDLC generally. I mean, during my time kind of learning threat modeling and also working with other teams developing it, I've seen a lot of models which have sort of fallen by the wayside, become sort of dusty documents sat on the shelf and never used. So one of the key aims that I have is to make it a living thing, so to make the models closer to the developers, you know, continually up to date and relevant to what they're doing. But it's basically a simple enough diagramming tool. It's going to have a powerful intelligent threat generation component to that. It's going to have a number of features which help with that integration into the development lifecycle.

**14:24 Chris Romeo:** Next, we asked Mike to describe for us how the user flow of ThreatDragon actually works.

**14:38 Robert Hurlbut:** So it's easiest if I compare it to the Microsoft tool. So the templates and the stencils that you have in the diagramming part of the Microsoft tool are quite comprehensive. There's a lot of different elements you can put on the diagrams. It's a regular data flow diagram, but kind of enriched with different styles of data store and different styles of external actor and things like that. And I just find that that's quite—

**15:03 Chris Romeo:** Yeah.

**15:04 Robert Hurlbut:** overwhelming, especially for somebody quite new to threat modeling or new to the tool. So the Threat Dragon approach is really just to boil that down to the fundamentals, so you have just the straightforward types of elements, not really enriched in any particular way, so it's simple to get you drawing your diagrams out, understanding the data flows quickly without having to try and figure out, well, okay, well, what type of a process is this out of the there's several that might be on offer from the Microsoft tool. The kind of next step after that— and again, I should say that, I mean, the project, I mean, it's still an incubator project in OWASP terms, which means it's quite early stage. But the next stage after the diagramming will be to have the tool suggest some threats to you. Now, again, Microsoft tool and other tools, they do a quite comprehensive job about that, but to me, it's a little— they try actually to do a little bit too much. So one of the visions, I guess, I would have for Threat Dragon is that it emphasizes having the developers and having the threat modelers thinking about the solution and doesn't attempt to give a, you know, a very comprehensive set of automated threats that are generated, and then they just have to kind of say, okay, well, now I have to— okay, I have to implement mitigations for these 17 threats that have generated in a kind of mechanistic way. I really want it to suggest more, somehow more high-level threats, and then have the people, the teams, the threat modeling teams discuss them, kind of critically evaluate them, and figure out for themselves what, uh, you know, what exactly is the, the threat. Is it real? How do we mitigate it without trying to do too much for them? Obviously, that's a quite delicate balance to strike because you run the risk of making it so high-level, actually, that it's worthless in terms of helping people. But at the same time, I think, you know, I see it as much as anything as an educational tool to get people thinking critically about what threats their applications are facing.

**17:14 Chris Romeo:** In episode 17, we spoke with Katie Anton and Jim Manico and asked them the question, what are the proactive controls and where did the proactive controls come from?

**17:26 Robert Hurlbut:** So, the proactive controls are targeted for developers and are created by developers. So, Jim Manico, one of our developers, background, and Jim Bird as well, who is a CTO. And they are controls, security techniques that we would like developers to use while they write their code. So this would be something that they can easily use while writing the code without being security experts, but they still are able to produce a more secure software.

**18:11 Chris Romeo:** If I may, like the— this is Jim, hello everyone. The proactive controls document, it's kind of like a comment on the OWASP Top 10. The OWASP Top 10 is risk-based, really for more risk managers or more traditional security people. And very often as the OWASP Top 10 made its way around, I found that developers— it didn't always speak to developers, right? It's not in their language. in security language. So, proactive controls is a kind of a comment on the OWASP Top 10, a similar kind of list that's made for developers by developers talking about high-level security areas that they need to concern themselves with. It's an awareness document. It's meant for one read. So, my hope is developers read it once, then they never read it again. They go focus on other documents that go into more detail and do So how much of a— how much practitioner-type stuff is in there though? Is it enough for somebody to really get an idea of what they should go and do? Is that the intention of it, or is it supposed to be a little bit higher level, kind of like OWASP Top 10? First of all, it's a Top 10 document, so it is meant to be a high-level awareness document. And we were fairly liberal in how we picked the categories. There's not like a stringent criteria here per se. For example, one of the categories, number 2, is parameterized queries, which is very specific, and we give exact code examples of how to do that.

**19:40 Robert Hurlbut:** Right.

**19:41 Chris Romeo:** Another area is implement identity and authentication controls. We could go read a book on that and still have a lot of ways to go. In fact, look at NIST 863. This is like a 300-page document that talks about identity. So these categories aim at different levels, but we think they're the kinds of topics that developers really need to be aware about, especially for their first approach towards web security, to help them be able to absorb other material around secure software building. Normally we focus on the origin story, like we already heard kind of where Katie came from and her experience here, but I'm curious as to the origin story of the Proactive Controls. Like, what was the— what kind of started this thing? Was it like 2 people kind of sitting around a table going, we should write another list, or how did it start? The project started— I'm the original project leader of it. The project started with Andrew Vanderstock and I discussing, you know, we need to have a developer-centric top 10. Andrew got the project started, and Andrew moved to other things. Andrew is is very active within the community. He's working on the OWASP Top 10 now, ASVS, and many other projects. So he didn't have time to stick with the proactive controls, and we just started building it out. I and a few others started just building it out. It got near the end, Katie and Jim Byrd joined around this time and were extremely active contributors. So I asked them both to be co-leads. I don't think any OWASP project, especially documentation projects for awareness should be controlled by one person or vendor. So, so Jim and Katie joined, and now we have— and all 3 of us are from very different development backgrounds, and we do different kinds of software development. So we have exceptionally civil conversations, I would say, to help determine, you know, what the next version is going to be.

**21:37 Robert Hurlbut:** Okay, good. Awesome.

**21:38 Chris Romeo:** So what are some of the changes you're looking at for the next version? that are kind of floating around in your head? We're in transition right now. So right now we're just about to finish the current version, version 3.0. And keep in mind, up until now, version 3.0, this is Katie, Jim Byrd, and I doing the best from our experience to pick items developers need to be concerned with. And so 3.0 is a reshuffling of some of the items, but it's not a— it's honestly, it's more of a point change. It's not a major change. And we're getting community feedback. We actually made the document world editable, so anybody in the world can anonymously provide comments. We make those comments not fully submitted so we can review them and accept or reject them as the project leaders, but we allow feedback from the entire world. We're in the 3.0 feedback phase. And again, this is a relatively subtle change, I think, right? It's not like a prolific change. After version 3.0, though, we want to be more in alignment with the OWASP Top 10 and be more in alignment with data. So now that the OWASP Top 10 leadership has changed, they have 4 different leaders from 4 different companies, a new call for data, they're on GitHub now, all these very positive changes. I'd like us to be more in alignment with them. But what we asked is, we're so close to the end of 3.0, we're going to finish 3.0.

**23:12 Robert Hurlbut:** Yeah.

**23:12 Chris Romeo:** And then as we approach 4.0, we're going to try to be more in alignment with OWASP Top 10, with the call for data, and try to build this proactive control list as something that's more than from, from our heads, right? And more from just community feedback as well and get some data so we can make sure we're picking the right categories. In episode 13, we were joined by Tanya and Nicole from the OWASP DevSlop project. And so we asked them, what is DevSlop and what was your motivation for creating it?

**23:52 Robert Hurlbut:** So DevSwap is going to be the overall project.

**23:56 Chris Romeo:** Okay.

**23:56 Robert Hurlbut:** And it's going to be a jungle gym for hackers to learn on. And we want to have lots of modern, new, different types of web application and web issues that can exist, like especially DevOps-related things, and let people learn on them. And then Pixie is the first release of things we're releasing. So, I'm gonna let Nicole explain Pixie, but our plan is to just release a new thing. Basically, like, when we see terrible things at work, then we are going to change them so that the victims cannot be revealed, but, like, change them and then, like, plug them in. So, for instance, like, I really wanna, like, store our keys to something in our GitHub repository so that people—

**24:45 Chris Romeo:** Oh, no.

**24:45 Robert Hurlbut:** people will come get them. Like something like that. So it's like things that we've seen where we're like, oh no, we just want to like make all of those part of DevSwap over time to help people learn. Do you want to tell them about Pixie? Yeah, yeah, totally. So yeah, I mean, hopefully DevSwap will be a bunch of apps, right? That's sort of the goal. And Pixie is its first little app. And it's basically like this photo sharing website that you can like a photo and give it like a heart, kind of like, you know, all the sites we know of today. Or you could love it and give it, like, a little bit of Bitcoin, like a micropayment in Bitcoin. So it's sort of like this little play there. But it's vulnerable. It's got a bunch of really horrible things under the hood. But it looks cool, right? It's using the latest and greatest, so it kind of looks cool. It's built in Mongo Express, Angular, Node. So it's got some vulnerabilities inherent to that exact MEAN stack. Lately, I've been messing around with writing a pure HTTP/2.0 app because There's a lot of proxies out there and a lot of different testing tools out there that really don't know how to deal with HTTP/2.0. So, I've been teaching myself the new spec here and trying to write an app that maybe we could use to test and train on that. So, I think just as Tanya said, as we see trends and paradigm shifts in the development industry that is becoming more microservice-oriented or maybe HTTP/2.0 is going to become a thing. You know, like, as we see these trends happening, what we want to do is, like, really showcase them with, like, a vulnerable app that people could, like, look at and test on. So that's sort of what DevSwap is supposed to be. So, like, yeah, like, as Tanya mentioned, people, like, git commit PEM keys and all sorts of other keys, right? So, like, yeah, like, we're going to build in, like, that sort of stuff. But we kind of want to make them more, like, app-focused things where it's, like, these little apps that you can test on, like, understand, all right, this is an HTTP/2.0 app. This is a you know, a web of microservices that no one really understands. This is like all sorts of other things that can go on. So, you know, we're in the market for ideas. So, you know, we only see our slice of the world. So anybody out there that has a really great idea for like a, you know, a fun dev slop app, we'd love to hear from you. I think it'd be really fun too. Like Pixie's in a container. I think it'd be really fun if eventually we had different containers and the containers could work together or work separately. And obviously we need a terribly vulnerable container. And I think the OWASP mobile guys where they have a vulnerable mobile app. I think it's Mobile Goat. And they were talking about possibly like figuring out a way that they could call the Pixie APIs. Like, I think it could be fun if like different things call each other and stuff. Like, there's a lot of opportunity to do cool stuff.

**27:25 Chris Romeo:** And finally, on episode 19, Tin Zaw joined us to answer the question, what is mod security?

**27:36 Robert Hurlbut:** Yeah, so mod_security is really one of the success stories of OWASP, and it started as an open source project by the gentleman named Ivan Ristic back in 2002, and it has been growing in user base and still going strong with the new releases and new people actively working on that. And there are some principles behind more security, that is to be open, to be flexible, and also to be passive in monitoring things so it doesn't interfere with the traffic or the pattern unless you tell it to do so, and predictable behavior in that what you see is what you get. These rules are open and visible by everyone, so you know what these rules do and you get the predictable behavior out of it.

**28:24 Chris Romeo:** Okay, so when you say it's open, is it The source code? Is it— how does it implement?

**28:30 Robert Hurlbut:** Yes, so MOSS Security is an open source project, and actually it is open source projects in that there are 2 components related to MOSS Security.

**28:39 Chris Romeo:** One is what we call the engine, right? The engine is just an empty set of rules, but it has, you know, ability to execute these rules. And the other MOSS Security project is what we call the call rule set, and that is the standard and the basic rule set for going together with the mod_security engine.

**28:59 Robert Hurlbut:** So they are 2 different projects, but they work very closely and they are deployed as a package together.

**29:05 Chris Romeo:** So maybe we can back up a little bit and see when we're talking about mod_security, where does mod_security actually fit in the architecture here? So I feel like I really don't know the answer to that, so I'm curious as far as where do I put this mod_security Right.

**29:24 Robert Hurlbut:** So, that's mod_security, the combination of engine and the rule set.

**29:28 Chris Romeo:** You can put it inside your web server, right? So, whether you're running Apache or IIS or Nginx, you can use it as a mod. It's a module inside the web server.

**29:41 Robert Hurlbut:** That's one way to deploy that.

**29:43 Chris Romeo:** The other way to deploy that is as a proxy somewhere in between the user browser and your application or web server, right?

**29:51 Robert Hurlbut:** So that would be like your load balancer, you know, or, you know, SSL terminator in your data center, or it could be at the CDN or content delivery network.

**30:00 Chris Romeo:** So it's like a web— so you could actually take a web server and install mod_security on it, but it doesn't actually host the applications itself. It's acting as that proxy thing. And then the other option would be to install mod_security directly That is correct. Okay, okay. So, okay, I have a better idea now about kind of where these things are.

**30:19 Robert Hurlbut:** Great.

**30:21 Chris Romeo:** So we hope you've enjoyed season 2 of the Application Security Podcast, and we look forward to the creation of season 3, which is underway right now, where we've identified a number of different people to go out and interview. So please stay tuned in early 2018 for the return of the Application Security Podcast.

**30:42 Robert Hurlbut:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/conclusion-owasp-is-for-everyone/