Elie Saad — OWASP WSTG, Cheat Sheets, and Integration

0:00Chris RomeoEli Saad is an application security engineer leading 3 different OWASP projects. He focuses on helping developers own and champion security in their projects by providing guidance, tests, secure pipeline design, and aiding them in applying external security measures. In this conversation, Eli educates us about the current happenings with WSTG, which is the testing guide, the Cheat Sheet project, and the integration standard. And he walks us through demos of each of these projects. We hope you enjoy this conversation with Eli Saad. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term, sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. Hey folks, welcome to this episode of the Application Security Podcast. My name is Chris Romeo. I'm the CEO and co-founder of Security Journey, and I'm also joined today by Robert Hurlbut. Hey Robert, how's it going?

1:42Robert HurlbutHey Chris, really good. Uh, good to be here. Uh, threat modeling architect, always enjoy our Application Security Podcast.

1:49Chris RomeoYeah, me too. And, uh, I believe you had a bit of an event where you earned an advanced degree. Is there any truth to that?

1:56Elie SaadI did.

1:58Robert HurlbutYeah, Master of Science in Cybersecurity recently.

2:02Chris RomeoCongratulations, that is very, very cool.

2:04Robert HurlbutThank you.

2:05Chris RomeoYeah, which— what university was that from?

2:07Robert HurlbutSouthern New Hampshire University. So it was an online program over a period of time, took my time through it.

2:14Chris RomeoGreat. We'll have to do another episode where we profile and ask a lot of questions for those that are thinking about getting a master's degree in cybersecurity. You know, the most important question is, If you had to do it all over again, would you?

2:27Robert HurlbutOh yeah, yeah, definitely. In fact, what's interesting, at the time there were a few programs around. A few, literally a few. Now, a few years later, there are many, many more universities that are providing it. So it's, you know, it's a topic again, 10 years ago you would never even heard of. Nobody carried this. And now you find bachelor's programs, master's programs. Even I've found a couple that are doctorate programs as well in cybersecurity. So really interesting, that changes in the last number of years.

3:00Chris RomeoYeah, we'll have to do another episode to come back and talk about your, your journey through the master's program. But I'm excited to say that we have with us today Ali Saad, who is an OWASP project lead for many things in the world of OWASP. Ali, we always like to start with the question, what is your security origin story before we get you any chance to warm up or anything. Let's dive into how you got into this crazy world called application security.

3:31Elie SaadSure. Thank you, Chris, for this introduction. So first of all, I went into college for a computer engineering degree, and while in there, I had the opportunity to be mentored in a development program. So for 3 years, I was doing development on the side, kind of an ambition, passion, whatever you want to name it. And I was a little bit lucky as well, because my brother went into cybersecurity ahead of me. And when I was at the end of my bachelor's degree, I was looking like, what am I going to do next? And he told me, why not look and see for cybersecurity? Like, you know, development, but you don't know about cybersecurity. So why not go ahead and see in an internship and then see if like it, go on, move forward with it. So I started an internship, started doing basic penetration testing stuff, did some blue stuff as well, monitored SIEM, built rules, understood the logs, how they functioned and all of that. So that was, that was a little bit between offensive and defensive. And as I grew into the field, I found that pentesting on its own is like it doesn't fulfill the full promise that it actually delivers. At the end of the day, you provide a report and you can give basic recommendations, but it's not your task to actually follow through with the developers, with whoever is going to build your remediation. It's not actually your task. It's just give them the report, give them remediation, follow after a couple of months later, and then move on. And I didn't like that. So I looked around and tried to see how purple can I go, and I landed on application security. I love that I can actually go back to being a developer and actually being a security professional. So having both worlds that I actually started with made me look like, all right, so I— when I was in college, I loved doing development, and then I went into cybersecurity. right, I have this chance to combine them. And when I went into application security, I just loved it. And as we all know, OWASP is the almighty knowledge base of application security, whether it was with tooling, documentation, requirements, all of these things. And okay, I want to contribute, I want to read stuff, I want to see how I can improve things. And I started off with the Cheat Sheet series because that project is actually the combination of writing secure code and actually looking for vulnerabilities. So when you look for a certain piece of code and you don't see the best practice being applied, then it means there's something wrong happening there. So that was somewhat interesting because it allowed me to be in the shoes of a developer better, and that's my end goal. Like, how is a developer looking at my recommendations And how can I make my recommendations more developer-friendly? So I started off with the Cheat Sheet series where Dominic was the project lead and he pushed me to contribute a lot. And suddenly I became a core maintainer of the whole project. And a couple of months later, I become— I became the project lead on that project. And the, let's say, WSTG, the Web Security Testing Guide, priorly known as OWASP Testing Guide. It was kind of what made me learn pentesting, and whenever I saw that it was being built for version 5, I said, all right, this is my chance to actually give back to this project what it gave me, how I started off. And that was a very lovely experience. And a couple of months later, I, I was helping Rick lead this project And now we're pushing forward for version 5.

7:24Chris RomeoThat's exciting, the different projects. I mean, Robert and I are both big fans of the Cheat Sheet series and the Testing Guide. It's hard not to be because they're such interesting resources and very valuable. And we'll dive deeper into what they actually contain. I'm curious though, how did you find OWASP the first— like before, like go back to the time where you had no idea who OWASP was. What was your introduction to OWASP that brought you to where you are now?

7:55Elie SaadOkay, so while I was getting into cybersecurity, I started to join communities and mostly on Discord. I first joined it because a couple of friends were there, so they invited me and I was kind of interested. Hey, I'm interested in security, so could there be some kind of servers that relate to these projects to security overall and similar things. And I slowly started to join multiple servers. And OWASP always was mentioned somewhere when people were describing application security. And if you even write how to do application security, one of the resources that you're going to find on Google, it's going to be related to OWASP. So all you need is just, hey, I want to learn application security and just click OWASP anywhere you find it, which is almost everywhere. It's just at the start, it was a little bit difficult to choose which project to look at because it contains so many. And will you choose a mid-level, a flagship? Which one are you going to choose? What focus are you going to focus on? So there's mobile, there's web, there's tooling. Like, whenever you come forward as a starting person, it gets daunting. and you start to look, all right, I know zero of this stuff. Where do I look? What do I start with? And that's why I started to dig deeper into it because I thought, okay, this is a very huge world. I better start from somewhere. And I decided to start wherever I loved most, which was kind of testing and development. And that's how I chose the first 2 projects.

9:34Chris RomeoOkay. And now, are you part of a team or a local OWASP chapter?

9:40Elie SaadSo in my country, there's no chapters, sadly, and launching one would be a little bit too much for me because I already am leading a lot, especially as well in the quarantine and all of the hardships currently going on. I would prefer not starting a chapter in my local space.

9:59Chris RomeoYeah, I mean, you're doing a lot in the world of OWASP as we're going to get into here in more depth. So Let's go ahead and if you want to share your screen now, this will be kind of our break. I'm thinking that you'll share your screen and then introduce the projects while we're kind of looking at them. Is that what you were thinking?

10:16Elie SaadSure, that works. So first I'm going to start off with the Web Security Testing Guide because it's one of the kind of biggest achievements recently. So the WSTG started off as OWASP Testing Guide in 2004. And it mainly focused on bringing testing to the SDLC, to software development lifecycle. How could people integrate it? How could people look at it instead of just a certain barrier at the end? So how can we make testing kind of a, let's say, adding unit tests, doing threat models, all of these parts that relate to actually seeing where the threats are and where to conduct tests. So it started off in 2004 and focused mainly on those aspects, the small bits. And later on, let's see here, after iteration after iteration, they started to add the tests and slowly it grew to what it is currently. And on the main page of the WSTG project page, you can see where someone can go and contribute, which is on the repo, the main repository of the project. There's a stable branch, there's the latest branch, and then there's the version release. And whenever you want to reference a certain test— because we mentioned several tests over here which are on chapter 4— so whenever you want to reference any of these tests in any of your reports, you can reference it using WSTG, whichever category you're going under, and giving the number. And In order to make it a little bit more robust over the years, we added a small version. So whenever you want to put a certain WSDG scenario, you go ahead and pick the version, whichever the latest is under the release, and you set it under the reference that you pick, and you can directly use it however you want. And to add a little bit on why WSDG is something that I enjoy more than other projects that are related to testing? Well, because it's kind of a little bit more than simply testing. It's more than simply providing the test scenarios that you're going to do. What it does is it gives you a small introduction— well, not so small, it's a little bit big. So what it does is it tackles what is the project, how to do testing, and it gives you a small explanation at the start, how to look at code, how to do threat modeling, source code review and everything that you need to actually follow a full SDLC testing pipeline. And that's something that you can't find anywhere and everywhere. You could possibly find it in random blog posts, but you don't find it in one book. And that's something that's very valuable.

13:11Chris RomeoThere's definitely lots of blog posts about how to exploit cross-site scripting, for example, but there's not a lot about kind of the process, all the different pieces that go into this. And so, yeah, that's a very valuable resource for folks that are, that are thinking about how do I integrate web application security testing into my secure development lifecycle, or maybe just my software development lifecycle. And so, yeah, that is, that is gold right there. The experience and wisdom and knowledge that's been transferred through that section is something that's really, it's a really special kind of description.

13:46Robert HurlbutAnd if I remember correctly, there are also some tie-ins from the OWASP Top 10. Am I correct that it would point back to some parts of this as well?

13:59Elie SaadYes, in a very vague way.

14:02Chris RomeoIndirect, but—

14:03Elie SaadYeah, so let's say injection. So you have these tests that follow under input validation or injection attacks. Let's say you're going for SQL injection. So they kind of map together. There are 11 main sections, they kind of follow more to what ASVS is. OWASP Top 10 is more related to risks than actual attacks. They kind of relate, but it's not directly related. They just have to be because there are risks at the end, so they better have some kind of an attack somewhere. And just to add one thing to Chris, it's not— so these first 2 chapters So chapter 2 and chapter 3, they are not particularly related to web. They are more related to testing. So you are going to do some mobile testing? Yes, go ahead. You can read this. It doesn't go into the details, but it provides you a general overview. Well, for mobile testing, you can go to the MSTG, which is fantastic. But as a general resource, these 2 chapters are somewhat independent from being only to web. And when you hit chapter 4 and the checklist that we provide for testing, yes, those are web-based testing, definitely.

15:21Chris RomeoYeah, that makes sense. So what I'd love to do here is I'd love for you to show us an example of a particular test, and I'm going to give you one because I've used this before. And this is one of the things I always point to to show the depth of the WSTG. So if you go to the cross-site scripting section and click through and show us.

15:42Elie SaadThere are 2 parts, so which one would you like to do?

15:46Chris RomeoLet's go to the server-side one. Let's do that. Let's look at the reflected cross-site scripting on the server side because that's one that I always look to. And I know this document has a huge amount of depth to it, but this is one that just— when I look at this one and I scroll through, there is so much depth. Like, somebody could pick this up and truly understand reflected cross-site scripting. and how to do it because this document is so— it has so much detail in it.

16:13Elie SaadYeah, definitely. So what we did is, first of all, just a small update on this. So we put certain IDs, we made it a little bit uniform to have 4 characters, 4 characters, and 2 digits to make things easier for people to use. And then all test scenarios contain a summary, and the summary is basically just trying to explain what the attack is on a high-level overview. It doesn't dig deep into the details. And then it goes into, okay, what are we going to test for and how are we going to test it? There are definitely multiple types. There are black box and gray box. We're a little bit shifting away from that because sometimes the gray box and the black box can be merged into one type of attack, so it kind of creates a redundancy. But let's take this as an example. First of all, you definitely need to detect where you're going to send your input and what is happening to your input. So definitely for cross-site scripting, we're talking over here for basic HTML tags. So script, alert, or prompt, or whatever we decide for it to be. And then we check how it's going to impact the page using multiple types. So let's say we are creating a script tag or we are injecting a certain HTML attribute. So they kind of differ and people need to check. So, and there's a certain filter evasion cheat sheet. And now I'd actually push people to look at PortSwigger's new XSS cheat sheet to reference and look at because it contains a lot more. And following through into the testing scenario, you can find more examples and some bypasses that you might find. But I'd like to point to something very clear that The test scenario allows you to understand the attack and start testing for it, but the attacker still needs to dig deeper into their specific application or their specific attack scenario because there is no possible way that a certain test scenario is going to cover everything that could be possible. Because sometimes people build custom applications and these custom applications will have their specific integration with other tools and applications that are not possibly covered. So it's very important for people that are using WSTG to go a little bit further as well. And we do that by providing references and tools for them to look and understand better the attack, to see how people could modify certain input strings and how they can be manipulated in the backend. And that's very crucial for people that are learning as well to keep that in mind and not only say Hey, I went through this test scenario, but I didn't look at anything additionally from the references or the tools. Okay, I'm good. There's nothing additional for me to do. So this is just a small pointer for people that are using it.

19:07Chris RomeoYeah, that's great. And it just, it shows the depth. That's, that's what I'm so impressed with, with this document, is the depth of information that exists here from the test scenario to the, the tools, the references, the book references. Like, you know, this is a— there's so much information that's available here. that's in this WSDG. And we're just seeing one scenario of many others. So back to Robert's original question, the linkage that you have, that you've been kind of working towards, is linkage with ASVS. Is there a mapping right now that exists between ASVS and WSDG, or is that something that you're working on for the future?

19:50Elie SaadYeah, so I'd like to keep a little bit for the integration standards. I'm going to give it as part of what is Integration Standard. So this question can just wait a little bit and I'll be explaining everything related to referencing.

20:06Chris RomeoYeah, that's fine. Yeah, Integration Standard was the one of your projects that I'd never heard of before, so I'm actually very curious. So before we get to Integration Standard, let's talk about Cheat Sheet Series. So let's, let's pop over there and, and take a look and see what we have.

20:20Elie SaadSo what I'm going to do, it's something that I usually like to do. It's just search for it and then grabbing the cheat sheet from a certain Google search. And this is what I perfectly love about this project. The cheat sheets, this is the only project that contains cheat sheets related to security. So whenever you have any issue or any particular implementation that you're building, just add a security Just add the security word and then add cheat sheet, and you're going to find definitely something around it. And this is the new website that we released a couple of like a month ago. It uses material, and we kind of changed a little bit how the cheat sheet works. It's going to give you first of all an introduction. It's going to tell you what we are telling you how to secure things in a general in a general overview. We're going to give you sections on the main specific issues that you might find. So let's say you are talking about database security cheat sheet. There are some issues with the connection to the database, how you're going to build your string and how you're going to communicate with it. So let's say over TLS or over non-encrypted communication and what can you use with it. And then you have authentication, your username, your password, how you're going to store them, how you can use them. So for example, for Microsoft SQL, you definitely need to use integrated authentication, so you don't implement any username and password. Then you have how to store the database credentials in a safe manner, and the permissions of your user. Let's say I created a new DB and I want to use it. Okay, make sure that you create a certain user that has specific permissions to actually communicate with the database and not access multiple databases, delete tables, do random things that you don't want to be happening and make sure you harden things based on certain baseline recommendations. And then we dig into every specific generic, let's say, DB provider. So Microsoft SQL Server, MySQL, Postgres, and MongoDB are a couple of the examples. And in the cheat sheet series, there is a little bit of what you discussed. We have an index with the ASVS. So let's say you are tackling architecture, you can go to the architecture section and then see, okay, I'm building a secure SDLC, all right, there's a threat modeling, the use case cheat sheet, and the attack surface analysis cheat sheet that could help us with it. This is one example. And Dominic went one step further as well, and he made a certain mapping between proactive controls and the cheat sheets to use. So let's say I'm building— so for those that don't know what proactive controls are, they are the top 10 major mitigations that you can build into your product. So first of all, it's define security requirements and it provides you a couple of cheat sheets to help you do that, so on and so forth. So these are quick wins for people to use. And to go over to the repository, people can open up issues, pull requests that provide us with, let's say, grammar fixes, logical fixes, how the cheat sheet could be made to be read better. Because the cheat sheet mainly, it's how can we help builders build better security products or more secure products. And it's very essential for us that Hey, as a developer, what I am reading is understandable and I can use it to implement whatever security measures I'm doing. Because this is the major weakness that we mostly identify with pen test reports. Hey, I found some XSS on your website, go ahead and fix it. But I don't provide you any actual remediation tips or fixes. You just tell me to fix the XSS issue. I go ahead and fix it, and then you find another issue in it because I didn't know how to implement it properly. So the Cheat Sheet series is mainly focused on providing these good security practices. They are not the best, they are the good ones, because let's say I'm going to implement the best security practice, some developer might not be able to properly implement it, and it's going to, to be very hard for them to do. What we actually aim to do is have enough security and good security till an actual security officer comes in and provides you with the topmost security practices. But whatever you implement from the cheat sheets, you are very secure. It's not just the top of the line, you can add more security, but that's not on us to actually worry about. We actually want to make your product secure, but it's not going to be government level or Fed level or any of those, because those are beyond this project scope.

25:16Chris RomeoYeah, the thing I love about the Cheat Sheet series is that it is one issue per cheat sheet, and it's designed to be simple, as simple as it can possibly be, so that you can point a developer towards one cheat sheet when they're having a specific issue. Like, password storage is one that I'm fond of because that's such a hard thing.

25:38Elie SaadYeah.

25:38Chris RomeoIt's such a hard thing to actually do. Like, I couldn't imagine how somebody is sitting there thinking with no cheat sheet or no kind of background information. Like, they're sitting there, developers, going, hmm, I need to store passwords. Like, yeah, what are they gonna do? Like, nobody's gonna be like, oh, I think there's a thing called bcrypt somewhere, or Argon2, or, you know, there's, you know, all these different things. And so, yeah, the cheat sheet, like, this is one that I point to all the time when people are like, hey, How do we store passwords? Boom, go look at the OWASP password cheat sheet.

26:13Elie SaadYeah, so this is— this in particular was updated a couple of months ago into the new format. It actually discusses the introduction, small bits of what is password storage and why do you need it, and then it provides quick bits. So let's say I'm a developer in a hurry. Okay, okay, use bcrypt unless you have a good reason not to. All right, bcrypt is good enough for me to use. If I am allowed to set a work factor, I need to set a very large work factor, and we discuss this later in a different section. Use a salt despite bcrypt doing it on its own. If you are meant— if you are made to do it, just add a salt. And if you are looking for additional layers of security, use a pepper. And we discussed this and when not to use a pepper, because sometimes using a pepper, for example, could compromise a certain DB by not being able to use it anymore, because peppers are— they cover the whole database and And if you lose the pepper, you lost everything inside of the DB if you don't have proper management of the peppers. So that's very critical for people to use.

27:16Chris RomeoAre you gonna add that? It's kind of like the TL;DR, too long didn't read, at the top. Is that the plan to add those for all the cheat sheets so that it's like a really simple version?

27:26Robert HurlbutAnd you probably, same thing, Chris, you hear that often. What's the latest? What's the best right now? What's, you know, that's a great great feature there. I can go there and update that just to show what's the latest greatest feature that I should maybe think about. So that's a great, great addition. I like that.

27:44Elie SaadYeah, so some cheat sheets won't be able to contain certain recommendations because let's say cryptographic storage cheat sheet, what are you using it for? There are so many use cases. You have to actually read a little bit. So we made them extremely concise and let's say I'm only looking to Uh, check. I want to randomly generate a certain ID. How can I do it? Or I want to implement a certain, uh, cipher. All right, which are the best to use? Okay, I can just click cipher mode and then just look around. Hey, GCM and TCM. Well, GCM because it definitely adds authentication, uh, to whatever you're using. And if you're not using, uh, any of the top recommended ones, uh, we kind of try and help people to use something else. So let's say you're using CBC, which is not the best, but if you use CBC with proper encryption after MAC, then MACing, it becomes a little bit more bearable to use and it becomes secure. In order to break it, you'll need a lot to do. So it's still secure than doing a bad implementation of any other algorithm. And then we say, so for example, ECB should not be used outside of very specific circumstances. And we give some tips for people that are looking at ventures. So don't implement your custom cryptography because just don't do it. No need to actually explain it. Don't do it. Simple. I don't need to talk about it.

29:13Robert HurlbutJust don't do it.

29:15Chris RomeoSo let's, let's go ahead and transition over to the integration standards because like I said, I have no idea. I have never heard of the integration standards. So I'm very curious as to what it is and what you're trying to accomplish there?

29:29Elie SaadSo while I was going into the OWASP world, specifically WSDG, Cheat Sheets, MSDG, ASVS, Dependency Track, all of the projects, and definitely ZAP, I looked around and I didn't see anything that could link them together. So whenever I looked around, I just saw that, okay, the Cheat Sheet sometimes references ASVS and the proactive controls, and ASVS sometimes references NIST and CWE. ZAP as well references CWE but doesn't have any testing. So it provides you 2 lines of testing recommendations, but it doesn't tell you how to do the full test, and it doesn't tell you properly how to remediate it. And the WSTG is still a standalone project. I looked at WSTG and said, hey, I want to integrate WSTG with ASVS. Okay, how am I going to do it? I started to look around and see that, hey, no project is properly linking to other projects in a very agnostic manner. For you to add every project, you need to build it from scratch. So for example, if you look at the proactive control and ASVS with the cheat sheet series, I can't take that and use it for WSDG. I'm going to have to start it from the start. And in November 2019, I decided to communicate with most project leaders, mainly the flagship project leaders, and told them, hey, I'm seeing this issue and I want to fix it. I want to create a certain SDLC pipeline that actually communicates together and is not just sectioned. So let's say ASVS is the requirements part and the WSDG is at the testing part. And I have the cheat sheet series at the implementation part, but none of them can communicate with each other. So let's say I'm a pen tester, how can I just set one reference that is going to link all of the pipeline together? And that didn't exist. No one uses it. The, the closest that you can find people referencing CWE, but CWE is not enough to actually describe the requirement. So ASVS and MASVS can't use it enough. So let's say I find a certain CWE for the length of a certain random string. All right, is this random string being used in a session or in a certain identifier? Where is it being used? What's the criticality of it and how am I going to test against it? And that's going to create so many problems because CWE actually focuses on the testing part and not the requirements part. And the requirements part is actually the small bits. So I had a small chat with the leaders and I was introduced to Rob, Rob Van der Beer, and he's my co-lead. And we discussed the possibilities of creating such a thing, a repository that could help build a certain ID, which we're going to call it CRE, Common Requirement Enumeration. And that CRE is going to help link all of the projects, all of the standards together. So let's say you're building for a certain password storage requirement, it's going to link between ASVS, the Cheat Sheet series, NIST, CWE for testing, WSTG for testing, all of them. It's going to be linked under one ID that mainly focuses, all right, I need to build a certain implementation, I need this requirement, How can I ensure that the whole SDLC is covered underneath it? And this is what the integration standard is going to do. It's going to provide you with a certain ID that you can just plug it into your report. And this report is now usable by testers. It's usable by implementations, by implementers, by QA testers, by business owners, because it's going to link everything together. It's a very difficult project, but we are looking to MVP it at the end of the summer. We already have a big testbed of requirements that we have made, and we have a huge repository that we're building for it. And what this project aims to do as well, it's, it's as well describing OWASP and the SDLC, because OWASP has so many projects as I described at the start, but it doesn't tell you where is each. So me and Spyros decided to All right, let's go ahead, start talking about the SDLC, and then slowly start, hey, we are doing planning and requirements gathering, whatever you want to name it. All right, so SAM helps you, ASDS helps you, SKF helps you, and we provide certain examples on a good maturity level, which is low, which is high, and we slowly go into every design stage. And if you notice, there are links across it as you go through. These links are tools, documentation, best practices, and how you can properly look at things. So this is a little bit on threat modeling, which is in the design stage, and what you can use to do it. You can start off by simply doing a draw.io, but I don't heavily recommend it because it's on the cloud, so be careful what you store on the cloud. You can just open a PowerPoint and start drawing, or just a whiteboard and start drawing. SKF helps you build what the project is going to contain. As you go through, you can see all of the stages covered and how you can properly provide recommendations across all of the stages, which is something that was lacking inside of OWASP. Why you don't know about it? Because it's still an incubator. It's still new. We are hoping to have it grow very soon. with the work that we're pushing, and we have some support from certain standards. So we hopefully look to push forward this project.

35:23Chris RomeoYeah, it's great. It's a piece that's been missing is the integration between all the different documents. So that's really exciting that you're gonna have this CRE and it's gonna be tagged to all the different documents. So I can look up a CRE and I can get references to all of the places where that exists inside of the OWASP universe. I think the OWASP SDLC work is also something that's been needed, and I'm excited to see kind of where that goes because I know a lot of folks have tried that in the past. There's been a few projects in OWASP. If you could go back to the wiki, there's a few projects in the OWASP graveyard that have tried to do that and have failed. So I think it's a piece that's been missing for a long time of how do you— how do I take OWASP and build an SDL out of it? And so, yeah, I think, I think you're— it's going in the right, the right kind of direction there. So basically, I guess at this stage, what would be your kind of key takeaway? You know, we've talked about WSTG, cheat sheets, integration standards, all these projects that you're a leader and a big contributor to. What would be your key takeaway then for our audience or call to action? Like, what do you want them to do? as a result of all of the projects that you've told us about today?

36:49Elie SaadWhat I want to actually mention is these projects are all open source. Anyone can look at them, anyone can use them, anyone can contribute to them. But people always decide to just point fingers and reference at the end OWASP Top 10. It's a great project, but it's not enough. People need to look at application security from another perspective. They need to see that I need to help application security because it's a very, let's say, it's a newborn field. It hasn't been there for long. Well, it's been around for more than 20 years, but it's not being pushed properly. People are still giving keynotes about it in major conferences just to tell how much needed it still is. Applications are everywhere where there are vulnerabilities. Even security products are having big, big vulnerabilities. Not to mention a couple of days ago, a big security provider had a certain CVE that was major. And I'm going to mention a little bit for people that are starting off in the field or that they still don't know about the field. Just look around, touch on what you love. So let's say I love doing pen testing, I love doing web testing, or mobile testing, just go ahead, grab the document, try to find, let's say, grammar issues as a starter, try to find logical issues. So this chapter doesn't make sense with the next chapter. All right, I can just go ahead and open an issue. And as far as I know, most of the project leaders that are currently in place, they are very welcoming and they help people push forward commits. Even if it's very basic, because for us, let's say a grammar fix or any of the like, it's something minimal. But let's say a person that has never contributed is going— they're going to say, hey, I just contributed to a certain project that I'm using, and it's going to give them a big push to do more, to communicate with the leaders. And contribution doesn't have to be on the projects. Sometimes project leaders just need a small feedback. Hey, I loved the book. I prefer, let's say, to have a certain section just before this particular reference because I didn't understand it. All right, we go ahead and create an issue. And that's a, that's a very major contribution because feedback is essential for us to understand, hey, are we going in the direction that the community needs us to? And I want to say as well, being a project leader, On open source projects, it's very daunting because sometimes you really don't know when to separate. So should I do more work because I'm the project lead on this project? Or should I just relax a bit? Or what should I exactly do? And I'd say that people sometimes forget about that. I'm referencing other project leaders. And I'd like to say that, please take breaks as you move forward. Being a project leader is definitely something hard, but it shouldn't take over your life. You should definitely focus on your life, and being a project leader is enough for the community because you're keeping a project alive, you are taking in contributions, you are putting a certain vision, and that on its own is very critical for the community.

40:13Chris RomeoYeah, definitely. That's, that's very wise words that you share with the whole OWASP community here. So, Elie, we want to thank you for for taking the time to be with us today. Also, thank you for your leadership on all of these different projects. And I know being a leader means you're always contributing as well. And so thank you for, for doing that. And we look forward to having you on the show again in the future for updates on all these projects, talking about how to be a successful project lead, how to contribute. There's a lot of things we still have to talk about, so we'll, we'll have you on again in a future episode.

40:46Robert HurlbutThank you.

40:46Chris Romeoepisode. So thanks for being here today.

40:47Elie SaadDefinitely. Thank you, Chris. Thank you, Robert.

40:51Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security Beauty is a journey, not a destination.