Andrew van der Stock and Brian Glas -- The Future of the OWASP Top 10
With Andrew van der Stock and Brian Glas
OWASP Top 10OWASP ProjectsSecure DevelopmentVulnerabilities and Exploits
How should the OWASP Top 10 balance data, expert judgment, community feedback, and a format people can actually use? Andrew van der Stock and Brian Glas discuss the governance and research behind the project’s next release during a contentious revision cycle.
Audio hosted by Buzzsprout. Nothing loads until you press play.
Episode chapters · 15 chapters
- 00:00The future of the OWASP Top 10Audio
- 02:21Andrew van der Stock’s security origin storyAudio
- 05:30Experience maintaining the projectAudio
- 06:36Governance and decision-makingAudio
- 08:13How public comments affect the releaseAudio
- 10:57Data concentration in the first candidateAudio
- 13:15Comparing findings across applicationsAudio
- 16:07Scoring and understanding impactAudio
- 19:30The origins of ASVSAudio
- 21:22Connecting the Top 10 to other OWASP projectsAudio
- 23:06The release-candidate scheduleAudio
- 26:21Preserving the one-page formatAudio
- 28:58What the Top 10 should becomeAudio
- 33:16How listeners can participateAudio
- 34:26Final thoughtsAudio
About this episode
How should the OWASP Top 10 balance data, expert judgment, community feedback, and a format people can actually use? Andrew van der Stock and Brian Glas discuss the governance and research behind the project’s next release during a contentious revision cycle. They explain how public comments affect decisions, why a large share of contributed data came from one source, and how the team planned to compare findings across applications. The conversation covers scoring, release candidates, the familiar one-page format, and connections to ASVS, Proactive Controls, and the Web Security Testing Guide. Chris presses them on what the list should become in the future and how listeners can participate. The result is a candid view of maintaining a widely influential community standard.
The Application Security Podcast is brought to you by Security Journey.
About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey
Connect with Andrew van der Stock and Brian Glas:
→ Andrew van der Stock on LinkedIn
→ Brian Glas on LinkedIn
→ OWASP Top 10
Resources
→ OWASP Top 10
→ OWASP ASVS
→ OWASP Proactive Controls
→ OWASP Web Security Testing Guide
→ OWASP ESAPI
Actionable
From this conversation
- 19:30
Test access controls beyond automated tools
If you're saying you need to test access controls, tools don't do that.
- 21:31
Use OWASP Proactive Controls to guide secure coding
It's literally things about how to do input validation, how to do good crypto, how to do solid authentication and things like that.
- 23:35
Follow and contribute to the Top 10 on GitHub
We're going to be working in GitHub, so anyone who's truly interested in following us for whatever reason, like day by day, they can follow us at GitHub and see where we're at.
- 30:58
Treat the OWASP Top 10 as a starting point
Because essentially it's an awareness document, and it's treated as a baseline. It's that starting point, and we can't emphasize that enough. This is a starting point.
Transcript · 36 min conversation
0:05Chris RomeoThe Application Security Podcast. Here we go. Hey folks, Chris here. Today's episode begins our set of interviews that we did at the AppSec USA conference in sunny Orlando, Florida. And in this episode, we talk about the future of the OWASP Top 10. And we do this by meeting the new project leadership team for the Top 10, understanding the process for how they're doing governance and how they're taking feedback and understanding what the different changes are gonna be. And so we really get a look behind the curtain about how they make decisions, how are they using the data and the feedback that's been provided. And as a side note, at the AppSec USA closing, they did announce that A7 and A10 are formally being removed from the OWASP Top 10. So we hope you enjoy this deep dive into how the OWASP Top 10 project works Behind the scenes. Hey folks, welcome to this episode of the Application Security Podcast. Robert and I are in sunny Orlando at AppSec USA, and we are joined today by the folks who are now responsible for the OWASP Top 10 project. And as we always do here on the show, we're going to start with their security origin stories And I'm just going to let you guys introduce yourselves. Tell us, how did you get into the world of security first so we can kind of have a foundation for where you're coming from? So who wants to go first?
1:53All right, my name is Brian Glass. I'm currently working as a director for Invisium. My origin story was I was an enterprise Java developer for FedEx for several years and then got lured by the promise of an identity vault, and then within 3 months became part of an AppSec team, and it's only gone on since there. So, helped build that program and then moved on through a bunch of different things. Oh, very cool.
2:21I'm Andrew Van der Stock. I'm a director of the OS Foundation. I'm a senior principal consultant at Synopsys. My origin story comes from slightly different tack. I started out being a developer and then I got into system administration, and I looked after about a third of the state's health system where I used to live. And from that, I started getting very interested in patient privacy and data privacy issues, and that's how I got into security. And then I have never looked back. So I did my first code review in '98, got involved in OWASP. Most people think I was involved from the very beginning. That's not true. I know who was at Mark's flat, and it certainly wasn't me. But certainly from late 2002, I've been involved in OWASP. Cool.
3:06So I was— I'm Neil Smithline. I was an enterprise Java developer architect, and 17 years ago or so, I was working for WebLogic, and the WebLogic security architect had gotten himself promoted but couldn't leave his job because it turns out they needed a security architect. So he said, hey, Neil, have I got a deal for you. And like Andrew, I mean, it's Very cool.
3:34Chris RomeoSo you guys are now responsible for the OWASP Top 10 project. Just give us a little bit of background about kind of what's kind of transpired. Our listeners are going to know, I mean, everybody knows OWASP Top 10, but also our listeners are going to have a basic idea what we're talking about. But give us kind of a rundown on what's happened in the last 6 or 9 months.
3:54I'm probably the best person for that. So Neil has been a very long member, part of the team, so Neil, jump in when you find some details that are either wrong or—
4:05Happy to correct you.
4:06Chris RomeoYep.
4:07In late May, I was approached by Dave Wickers. There was a lot of criticism of the first release candidate of the OS Top 10, which seemed to pop out of nowhere. It 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 aren't 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 were 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?
5:302004, I think, was the first one I worked on.
5:32So even longer than I've been involved in it, because, you know, I did the AUSTOP10 in 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 their product type into the top 10.
6:36Chris RomeoSo what does that governance look like then right now? 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?
6:49That'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.
6:59We've disagreed over the simple decisions, actually.
7:02Chris RomeoOkay.
7:03But also balanced.
7:05Right, 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.
7:18And 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.
8:13Chris RomeoHow are you taking the kind of public comments? How is that handled? How does that impact your kind of thinking about— I guess I could say how you're going to vote. It's not really a vote at this point, but it kind of is because 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 gonna have a website and we all vote, like, what do you think should be on the top 10? Well, I like these.
8:35Well, there is a website, right? We have 516 responses, I think, um, from, from anonymous, hopefully security professionals. I don't think my mom voted, but, but it's anonymous. So yeah.
8:53Chris RomeoSo how did that— I mean, how did that impact where we are right now Based on what you saw from that survey information?
9:00So, I mean, one of the things that came out of the summit was, you know, one of the big things that was brought up in the keynote this morning as well was the need to be data-driven but also to be forward-looking. And trying to strike a balance between those two, at the OWASP Summit in London, we determined for this go-around we would try having 2 items on the list of the top 10 that were driven by Industry Love Survey. So letting industry professionals come out and, as Neil said, vote anonymously and tell us from their experience, you know, from what's not there, what are the things that they think most likely need to be part of the top 10. The other 8 will be driven off of the data we've been able to collect from the revamped Call for Data. So, I mean, every— almost every question on Twitter, everything that's gone through the issues and such, I mean, we talk about every one of those. And there's a reason. I mean, it's friendly arguing, but we all have a fairly diverse background about where we come from and the experiences related to the different top 10 topics. And so we have some very lively-spirited debates about you know, how we should handle some of these comments and the way we should respond. But we're also right now very much in agreement that we need to talk that through and speak together as a cohesive team.
10:29Yeah, I'm, I'm really looking forward to once we've made a decision, we've got such a short amount of time, let's not revisit those decisions and just move on. I don't think we need to have 100% agreement on every single item we do. As long as we've got most of the team on board, let's go for it.
10:49Chris RomeoAnd so you referenced the keynote this morning, and just for our listeners' benefit, Jim Manico and John—
10:57Steven.
10:57Chris RomeoSteven did a keynote where they talked about OWASP Top 10 and kind of where they saw the challenges right now. And they mentioned in their conversation that 99% of the data from the RC1 came from one vendor. And so I guess, is there— have you gotten more in the latest call? So I knew there was a second call for data, but I hadn't yet been able to see what had happened. So did you get a lot more good stuff?
11:23So 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.
11:53Chris RomeoOkay.
11:53And 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 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.
12:24Chris RomeoSo 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.
12:33So 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, like if you've ever played with statistical averages, you hide a lot of things when you run averages.
12:52Chris RomeoMm-hm.
12:53So 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.
13:15Chris RomeoSo what do you hope to get out of that number of unique apps? Is it— I mean, what's the data point that you're going to be able to take away that would be different from the big aggregation view?
13:28So there's a difference between— so 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 cross-site scripting.
13:50Right.
13:50Now all of a sudden I have 8,000 out of 50 had cross-site scripting and 42,000 didn't. And it's a totally different picture of incidence rate for cross-site scripting across apps than trying to average out both totals.
14:03Chris RomeoAbsolutely.
14:04And human testers tend to say when they do like a pen test, they say you have cross-site scripting vulnerability in your application, right? And that's sort of it. 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. So it sort of really skews it to the things that static analysis checkers are good at if you start counting instances.
14:27And I think that comes down to the weighting. And honestly, humans are really good at doing things like business logic flaws and access control testing, which are not visible to static code analysis or tools augmented by humans because that pathway is not even open to them. So what we need to do is, and I think Brian, you said that essentially this weighting is only like 1/6 of the total. that ends up being like the ordering?
14:55Yeah, that's the way it was, yeah.
14:57Yeah, but essentially we need to work on the impact as well, so that essentially we've got data that suggests this is the impact, this is the number of times it occurs, therefore we've got data to represent. Will it end up ordering it differently? I think the end result out of the Project Summit is If it appears in the list, we probably won't reorder. Probably won't. But it depends. I mean, we've got to see where the data leads us.
15:26Yeah, and it's one of the things that we've said that we're looking at leveraging CWSS. So it's a close companion to CVSS scoring, trying to basically determine impact. And so because we're talking about SQL injection and cross-site scripting in general terms, We have to look at generalities in terms of not the extreme cases of SQL injection in either case, but on average, what are the attributes of SQL injection versus on average what are attributes of cross-site scripting. And so we're looking at trying to weight the impacts of each of these different types of vulnerabilities along with the incidence rate that they show up in applications.
16:07Chris RomeoSo with this CWSS, Are you able to have a better idea of impact based on— do you know some things about the apps that the data came from that allows you to kind of plug into that CWSS formula? How do you get to that? Because I know CVSS really well. I'm fascinated now by the fact that you're saying CWSS is going to be something that you're going to potentially use here.
16:33So looking at CWSS, CWSS is more geared toward impact of CWEs. And so not right now, technically one of the OWASP Top 10 doesn't have a CWE except for the fact it was created for it after 2013.
16:50Mm-hmm.
16:50But in general right now we're looking at, you know, weighting each of the things in the Top 10 and each of the— basically all the CWEs we've collected data for. And there's a bunch of different weightings, but essentially we have to pick an average weighting, and that's something that we'll go back and forth on in terms of what we're comfortable with on that weighting, and then compare that into incidence rates. So, I mean, if something's horribly heavy but has like shows up twice in 2 million apps, it's probably not going to have as much weight as something that's moderately heavy but shows up in 1 out of 10 apps.
17:25Hmm.
17:26So, and it's an interesting challenge. It really is because, I mean, we're going to almost the highest level of abstraction to try and the essence of application security into here is a baseline of 10 things we're hoping you start with and then continue from there.
17:42Chris RomeoYeah, if we could just have the top 1,000, this would be a lot easier. Maybe I'll start that new project, the OWASP Top 1,000, where I just add a bunch of stuff.
17:49You'll be in an internal argument over the ordering.
17:52Chris RomeoI always joke, even the OWASP Top 1, I sometimes refer to the OWASP Top 1 just to try to spur people on to focus in on let's just fix that one thing know, if we get a handle on it.
18:04So with the ASVS, we basically have the top 153. And which ones you do first? Well, you know, we've made a guess. There is no data behind that. But at the end of the day, you know, that's one of the things that we're being brought on as leaders is to work on that impact. There is going to be a section within the top 10 about things that are on the cusp, like things that didn't quite make the cut. And the data is going to be available for everyone so they can actually do their own analysis if they disagree with us violently. At the end of the day, we want to make sure the OWL Top 10 is useful for the types of things we're describing, but we also want to make sure that people understand how we got to where we are. And so by providing those items that are on the cusp without as much detail, like this is where you go to find more about this, that's fine too because the OWASP Top 10 isn't where you stop, it's where you start. And as long as people understand that and then there's more, good.
19:07Chris RomeoYeah, and I think that's somewhat of a challenge at the moment. I run into lots of developers who know about the OWASP Top 10 but they may not know much beyond that and trying to help them understand that's just the starting place. You know, and there's some other things out there that you know, we want them to look at as well. You mentioned the ASVS. Tell us a little bit about that, what it is and how it came to be.
19:30Okay, so the Application Security Verification Standard is actually a certain consultancy whose name we won't mention. It was their checklist for secure code reviews. Chopped out some of the things and then it was made into the ASVS 1.0. And so Mike Babursky and Jeff Williams brought that to fruition. Over time, I started— I moved back to Australia in 2009 and I started using it for code reviews and pen tests and things like that. So I was an actual user of the ASVS and I just realized it's not working really well for pen testing. And so I ended up revising it. So we have 3 levels. We used to have 5. The original version had 5 levels, which was just crazy. I mean, people don't do one level, let alone 5. So I tried simplifying it. Then we basically tried to make it so that the ones in level 1 were all testable by tools, which is difficult. It's a very difficult problem. If you're saying you need to test access controls, tools just don't do that. So the ASVS is what you should do as a developer. So you can write your functional and non-functional tests, unit testing and integration tests, using the stories that are described in the ASVS. For example, as a user, I should only be able to edit and view my own profile. Job done. This is a very different type of thing than the top 10, which is you shouldn't have SQL injection. There's 1,000 things you shouldn't do, but there's only really about 13 or 14 classes of things you should do.
21:06Uh-huh.
21:07And so from a developer point of view, this is actually a good thing. So the ASVS comes from that more of a developer focus, but it's also a great test suite. It's also a great pen test checklist. It's also a great secure— in fact, its best use is as a secure coding checklist.
21:22Chris RomeoSo how does the OWASP Top 10 fit with many of the other popular OWASP projects?
21:31There's a references section within the OWASP Top 10, and I've already spoken to the proactive controls team. I'm going to reach out to the testing guide, and I'm obviously on the ASVS team as well. I want us to heavily interlink the proactive controls, which is the developer-focused controls of things that developers should do well. That's run by Jim Manico and Katie Anton. Katie Anton is the current project lead on that. It's literally things about how to do input validation, how to do good crypto, how to do solid authentication and things like that. So it's It's really a better list for developers, full stop, end of story. If you're a developer, you should go to that one first. But we know that OS Top 10 is the most heavily referenced. So we want to have good interlinking, and I think we need to review every one of our references because there are some older projects and older references which are not maintained. And for 2017, we need to make sure that everything that's in our references is something that's directly useful. So, for example, there were some ESAPI links. We're going to get rid of those because ESAPI is not maintained. We want to make sure that everything that we link to is directly relevant and useful, because we only have a limited amount of space and we want to make sure that we make the best use of that space. So we want to get the testing guide in there. We want to get proactive controls in there. And I think the ASVS has a place for folks who are writing code and need to do integration and unit testing. So we will go through each one of those with a fine-tooth comb and make sure that we're heavily interlinked into those other projects.
23:06Chris RomeoSo what does the schedule look like then for kind of how we're going to go into the next release cycle here? What should folks be— when should they be looking for RC2? When should they be looking for RC3? what are you thinking about for a final?
23:24Well, correct me if I'm wrong, we're aiming for a final on the week before Thanksgiving.
23:31I think it's November 15th is what we said.
23:33Yeah, we're going to be—
23:34Chris Romeo18th.
23:35We're going to be working in GitHub, so anyone who's truly interested in following us for whatever reason, like day by day, they can follow us at GitHub and see where we're at. A formal RC2 release, we're thinking of committing ourselves to the middle of October, is that right? Yep. So once we've done the data analysis, which should be today or tomorrow— okay, Sunsoon.
24:00Next week, yes.
24:01That's what he's saying. We have to write 2 new items pretty quickly and then go through and actually address each one of the issues. So I think we're going to have some long sessions on our Friday afternoon meetings. We meet weekly, but I think we might need to extend them out and actually deal with the feedback that we've got on the issues and to revise the text of the existing ones so that we can actually say, well, this is now ready for release. Because there's a lot of feedback. We've got over 80-something issues open.
24:30I think it's 90.
24:32I think I looked this morning. And so if you think about that, like, that's 10 issues on each 4 paragraphs of text. That's— we, you know, you could easily rewrite each one of those things based on one of them. So we need to decide which ones we're going to action, which ones need to go forward, which ones are going to go away. Obviously, we'll probably be retiring A7 and A10 as they stand. We'll work out what's coming in their place and where it's going to come in.
25:00So I think you touched on something that a lot of people may not realize is how much time has to be spent determining format, trying to make sure we can handle internationalization, all the different translations, trying to figure out, you know, the best way to represent There is— I mean, there is time spent in data analysis and such as that, but there's a lot of time spent trying to figure out the right structure. Because this can't essentially be a Notepad file. There has to— I mean, being one of the premier crown jewel flagship project, whatever you want to term it, it has to be a professional production at the end of the day. And so there is a lot of effort from our side that we're putting together trying to figure out how to have something that it's easy to be able to edit, to make comments, to find out, you know, get people to collaborate on, but still be able to turn around and produce it quickly into a professional-level product.
25:59Yeah, we have this competing constraints of we really like the one-page format for each entry. On the flip side, we want to put everything possible into every entry, so you know, we've had conversations about removing whitespace, you know, and various other things of that sort. We're going to be hiring a designer to come help us.
26:21Chris RomeoSo you're leaning towards still staying with the one page, trying to keep it tight?
26:27I think it's necessary. It's an awareness piece. It's not the end result of, you know, if you look at a true security standard such a— or a true standard such as ISO 31000 or ISO 27002 or ISO 2734, they have many pages for many of the things. This is not a standard. It's an awareness piece, but people treat it as a standard. Now, the reason why they like that as a standard is it is one page per thing.
26:57Chris RomeoConcise.
26:58Yeah.
26:59So we need to distill the essence. And I think one of those things is we need to revisit the way that we do the header. There's a There's a lot of redundant text up there. There's also, I think it's a little bit confusing. When I was doing the Markdown conversion the other day, I realized there were 2 columns that were always app-specific. It's like, why even have that column? It makes no sense. It's always app-specific. We need to do a lot better with the space that we have. And I think it's actually much harder and longer to do a concise version than a long version. Because this is the other thing, is that English is such an expressive language. You can say things in 3 or 4 words that are literally a sentence or 2 in any other language. And to get the same meaning in another language, we need to be clear.
27:46So Torsten, who's one of our co-leaders who's not here, he has been running the German localization team. So he has You know, that's a more verbose language, I guess. Right. And he's talked about the fact that they had to trim words to fit it onto one page in previous versions.
28:05They also use small text.
28:08Yeah.
28:09Which has an accessibility issue as well.
28:11Chris Romeo7-point font on there.
28:13Yeah. So he's been able to provide wonderful insight. And we do appreciate him getting on the calls at like 10 PM or 11 PM his time most weeks. But being able to provide that level of internationalization, a lot of times when we're US-based— and Andrew probably doesn't have this as much as Neil and I do— but when you're US-based, you have a tendency to think that that's as far as you go, and you forget that there's an entire globe that you're addressing.
28:41No, it's on the top of my mind. It's one of the reasons why I was thinking that the PowerPoint version was possibly not the right way for us to work initially. And so we're still— this is one of those healthy discussions that we're still yet to resolve, but once we've made a decision, it'll be resolved until we finish.
28:58Chris RomeoYeah. So I'm gonna kind of circle back around to something, the kind of the forward-thinking idea. And I'm just curious as to— I mean, we're all— you're ultimately saying, or we're kind of saying, when you think of forward-thinking, we're gonna try to predict the future. future to some degree. And I think it's a valid approach. I think we do— I like the idea that we're looking further down the road than kind of where we are today. But kind of from your perspective as a team, how do you— how do you— how are you going to try to make that prediction? What are you going to base that on?
29:30So what we did for this go-around is we put out an industry survey. Basically, we selected a number of topics that were on the cusp of for the last couple versions of the OWASP Top 10 and items that people brought up in the feedback from RC1. And we put out a survey in Google Docs for people to fill out those forms. And they basically— it was a ranked survey, so they voted their number 1 through number 4 choice in terms of what they felt from their experience should be one of those 2 topics. And so, like we said, we had over 500 submissions. So we are going through right now and we are essentially analyzing that to determine, you know, of those different vulnerabilities that people voted for, which ones end up coming out on top. And so we will look at inclusion of those— 2 of those, the top 2 out of that into the top 10 in the 2 spaces. And so these are things that we there may be limited data for, but they're not things that we would have collected a whole ton of data for necessarily. But also, forward thinking doesn't necessarily mean something shiny and new that we've never seen before. It may be something that's either resurging or things that are a problem, but they haven't reached a critical mass yet to where we need to include it within the top 10.
30:55Chris RomeoOkay, so something to watch out for, be aware of.
30:58Yeah, because essentially it's an awareness document, and it's also treated as a baseline. It's that starting point, and we can't emphasize that enough. This is a starting point. And so it's a baseline that says at a minimum you should be able to cover these 10 things, but you shouldn't stop here, and you should be able to continue. But we're trying to give you something reasonable to bite off to start with.
31:21So to give you an idea of why this was a problem, in 2007 I stuck CRSF in There was no data about CRSF, but every application, bar a few of them, was vulnerable to it. And so I put it in knowing that this would actually lead the conversation to resolve CRSF. And now it's more or less a solved problem. So as an agent for change, the OWASP Top 10 should have room for a forward-looking item. In 2010, it was outdated components.
31:51No, that was 2013. Which I vehemently argued against, and now it's the number one concern I have in my job.
31:59Yeah. And so outdated components has obviously— it's bitten a certain large credit reporting agency quite hard as well. So there's a reason why these things were shoved in, and when A10 and A7 became part of it, I was like, what? And then I thought about it. Well, actually, I've exploited those things this year. But we had to take the community feedback on board, and I think this is the right way to do it. It's not just some people in the back room deciding what's in and what's out. It's transparent. There's no tools required, no specific class of tool you need to solve this problem, which is the thing that's OWASP-like. We need to make sure that a small person, like a 1 or 2 person project, can solve the OWASP Top 10 by themselves without buying anything. I think that's where we need to land. I think that was where I think the mistakes were made with A7 and A10.
32:51That's part of the baseline. We can't take the top 10, the super advanced stuff, whether or not we want to. That's not its space. A baseline has to be something that can be actionable and actually be accomplished by different sizes of teams. You shouldn't need to have a 10-person security team and at least 400 developers and the whole program to be able to meet that baseline.
33:16Chris RomeoSo how do our users, if our listeners, how do they get involved? So when the RC2 comes out, there's going to be another comment period. So we want, I guess we want to encourage them when, around the time, watch for when the release, I'm sure you guys are going to announce it everywhere. The last one went live wildfire. Didn't even need a marketing department. It just kind of seemed to have— people were just aware. But so that's going to be the best avenue for them, is going to be to take a look at RC2, submit through whatever the feedback forms are, and, you know, kind of be heard. And you know what, if you don't offer your feedback, then you can't complain. People still will, but at least you can say, I'm complaining now because I gave my feedback.
34:00Well, I mean, we're gonna— I mean, we'll announce through the the OWASP Top 10 Twitter. We'll probably do a small piece on the OWASP blog and leader mailing lists and whatever we can get our hands on to tell folks, because it's going to be a small window because we're trying to get it out this year yet. But if at all possible—
34:19Chris RomeoAbout a month, right?
34:20Yes, 3 weeks, month, depend.
34:23Chris RomeoYeah, November.
34:24So yeah, somewhere in that space.
34:26Chris RomeoAnd you guys don't have day jobs, right?
34:27No kids either.
34:30Chris RomeoNo kids, no day job. Wow. You guys just do OWASP Top 10 all day long.
34:34For free. Absolutely. For free.
34:36Chris RomeoYou're philanthropists. So yeah, I mean, thanks for taking the time here today. This has been great to get some insight into what's kind of happening in this project. And I know you guys, you can— it could almost be a thankless job because you're always going to have people that are going to be mad at you. But I want to thank you on behalf of our show and the listeners just for taking this and moving it forward. We all know how important it is, and you guys have been willing to dedicate a lot of time and potentially take a lot of punishment and pain over the process. So I thank you for that, and thanks for being here with us.
35:05I'll just mention our GitHub repository is OWASP/top10 on github.com, and comments are welcome.
35:14Cool.
35:14Chris RomeoThank you very much.
35:15Thank you. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born 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.
6,347 words · transcript by assemblyai
More like this
View all episodes →- July 21, 2020 · 41 minElie Saad — OWASP WSTG, Cheat Sheets, and Integration
- July 25, 2017 · 44 minDave Ferguson -- The OWASP Top 10 Proactive Controls
- November 27, 2018 · 44 minJeff Williams -- The History of OWASP