Meet the experts who power Synack’s strategic security testing platform. Our Synack Red Team unites over 1,500 of the world’s most skilled and trusted security researchers, who work with patented technology to deliver best-in-class offensive security testing on a continuous basis.
Jim Manico on Secure Coding, OWASP and Being a Decent Human
Guest:
Jim Manico
Published:
Updated:
Duration:
49 min
Episode summary
Jim Manico is full of opinions. The founder of Manicode Security has advice on how to use the OWASP Top 10, on secure coding and especially on the OWASP Application Security Verification Standard (ASVS). He has advice for people starting out in security and on what it means to be a decent person. Jim is definitely one of those! He’s also an educator, author, investor and entrepreneur. There are so many reasons to listen to this episode. Here are just a few:
Hear from one of the leading educators focused on helping developers code securely.
Learn more about all the important projects and initiatives happening at OWASP.
Get Jim’s perspective on how organizations can best implement DevSecOps.
Use the Top 10 for awareness only Jim says the OWASP Top 10 itself warns against being used as a standard. Read it, then base a program or test plan on ASVS, which can be forked into an internal standard.
Design flaws are expensive to unwind The 2021 Top 10 added insecure design because microservices, cloud, and third-party libraries make architecture decisions critical. Jim advises bringing approved reference architectures to threat modeling sessions.
ASVS shows how complete a test was Mapping a pentest or scanner to ASVS sets a baseline, and good reports also list what was tested and found secure, not just a few critical findings.
Start DevSecOps with two fast checks Jim recommends running a fast static analysis tool such as Semgrep as a check-in blocker, plus Dependabot for outdated libraries. He would skip dynamic scans and slow traditional static analysis at first.
Learn some code and some cloud His advice to newcomers is to learn the basics of coding, even an hour of JavaScript tutorials, and spend time in the AWS consoles to understand cloud deployment.
Topics covered
DevSecOps
Security Testing
Vulnerability Management
Notable quotes
You can call it being a decent person, but it's also a good life and business strategy.
…you should read the OWASP Top 10 once and then put it away because honestly, you shouldn't be basing a security program or anything on the OWASP Top 10.
…if you don't think about your design ahead of time, trying to unwind an insecure design is massively expensive.
DevOps is all about automation. Anyone tells you differently, they're just wrong.
Questions this episode answers
What is secure coding?
Going beyond code that works to code that resists attack, such as using parameterized queries instead of string-built SQL, or rejecting JSON Web Tokens with the signature type set to none. Jim says it means getting hundreds of requirements right. Read this section
Should the OWASP Top 10 be used as a security standard?
No. Jim says it is meant only for awareness and should be read once and put away. ASVS is the comprehensive standard to build a program on. Read this section
What does insecure design in the OWASP Top 10 2021 mean?
It is a new 2021 category for design flaws, calling for more threat modeling, secure design patterns, and reference architectures. Jim says complex modern systems make upfront design critical. Read this section
What are the ASVS levels?
Level 1 is for every app and largely automatable, level 2 for more sensitive apps, and level 3 for critical infrastructure with more manual testing. Jim wants to make the levels risk based, like NIST SP 800-63-3, and the debate was open in issue 1127 on GitHub at the time of recording. Read this section
How should an organization start a DevSecOps program?
Jim says DevOps is about automation. Start with a fast static analysis tool as a blocker on every check-in, then add Dependabot or other third-party library scanning. Read this section
About the guest
Jim Manico is a developer turned educator who, at the time of recording, ran Manicode Security, a company that trains software developers in secure coding and security engineering. He is a former OWASP global board member, a contributor to the OWASP Application Security Verification Standard (ASVS), and the author of Iron-Clad Java: Building Secure Web Applications, written for Oracle. He is also an investor and entrepreneur.
And I'm Jeremiah Roe. Today, we're talking to Jim Manico, founder of Manicode Security, where he trains software developers on secure coding and security engineering.
Jim does so much. He is a teacher, an author, investor, and a former OWASP global board member. And he's a guy with a lot of opinions about a lot of things, especially the OWASP top 10, Secure Coding, and the OWASP application security verification standard, ASVS, which is one of my favorite things.
WE'RE IN is brought to you by Synack, the premier crowdsourced platform for on demand security expertise. Synack delivers twenty four seven pen testing, intelligence, and vulnerability management from a global network of vetted and trusted researchers. Their work is enhanced by smart technologies to accelerate your critical cybersecurity missions. Synack gives businesses the best chance of finding every vulnerability that matters. Find out more at synack.com. That's synack.com.
I'm doing good. Thanks, Bella. I am currently on vacation traveling. Jim, thank you so much for joining. Again, it's our pleasure to have you on the show. You've had such an impact in the industry, and and we're just happy to be able to highlight that. So thanks for joining.
So getting started, ultimately, you know, we just kinda... Given your history and everything you've done in security so far, I'm kind of curious as to why you why you decided to start Manicode Security and why you focused your career around the secure coding aspect.
This is my my wheelhouse. Right? I've been... I'm primarily a developer. Even today, I don't think of myself as a security professional. I'm a developer. And I... And throughout the course of being an architect in parts of my career, I had to learn about how to defend my code and how to defend my applications. We're talking like mid nineties when it wasn't really in vogue to do so, and I was getting attacked and learning about this. So I ran into OWASP with my research, and I began arguing with Jeff Williams about security, and he was he was very helpful early on. And I... As I continued to study of Secure Coding, I realized there's just not much out there on this topic. So I began to collect the information that I was studying and starting to organize it for my own use. And like you, I started a podcast on application security because as I'm collecting this research information for my own work, I'm meeting all these rock stars in application security at the time in this really small, you know, unique community.
So I did my own podcast to record the beginning of this industry and all the the brainiacs who were who were teaching me around about secure software. I met Eric Sheridan, Dave Wichers, Mike Burstsky, and all these originals, some of the... Andrew Vanderstock and a lot of the the early folks at OWASP. And so I eventually collect this information and wrote a book. I wrote a book for Oracle on how to build a web application securely in the Java language, and I was kind of bit from there. It's like writing a book was hard. It was not a profitable endeavor at all. It was a intellectual endeavor and a mental and a marketing piece, but also a way to organize my thoughts. And writing that book is really what prepped me to be a teacher. And I've been teaching for about a decade now. Manicode's been around for about six years.
And it's, you know, it's not just a business, it's my joy. I love teaching. You know, my grandfather and father are both I feel that for sure. Just something I love doing. That's the kind of progression from developer to getting attacked, to being introduced to OWASP, to writing a book, to starting a training company. I feel very fortunate, and I love what I do.
So I know Manico is kind of focused around teaching secure coding. Can you tell us exactly what you mean by that phrase, secure coding? And specifically, like, what is the difference between learning secure coding practices and just learning to code generally?
Like, for example, when I'm learning to code, I might be working with the SQL data access meta language, right? The SQL, standard query language. And if I'm adding variables to my developer built queries with the raw string building, guess what? My functionality works and the application works and I can accomplish my business goals. But one of the nonfunctional characteristics of that way of building a query is that it leads to SQL injection. Secure coding is when you're just not satisfied just to build functionality that works, that you want to use something called a parameterized query and other techniques to access that database in a secure fashion. For example, another example of Secure Coding is I'm using JSON Web Tokens, and maybe I'm doing a really bad job of verifying that signature, but my authentication system works.
And then I find a flaw. Like, maybe I'm using an old library, and I'm using... And and the attacker can do a weird trick. They can set the signature type to none to bypass my signature check on your JSON web token. That's the insecurity. Doing it securely means I'm aware of this problem, I keep my library up to date, and I have my server verify a limited number of valid signatures for that kind of JSON token mechanism. That's a little bit of extra effort. And it's not that much effort, but it does require specialized knowledge. And Bella, it's a lot of minutiae. I don't think people talk about this a lot, but doing defensive secure coding is like hundreds of requirements that a developer needs to get right. Some are functions and some are non functional characteristics of software.
So this body of knowledge is brutally complex. There's a lot going on. That's why something like the ASVS, that's one of the OWASP documentation projects, the Application Security Verification Standard, is the combined wisdom of over 100 professionals that come together to build a requirement list as a standard that the whole world can benefit from. Right? I'm an expert in this area supposedly, right? But as I work on the standard, I learn more than I give. And I learn a lot just by keeping a close eye on the standard, I guess, the collective wisdom of security requirements for many. And this is the minutiae of Secure Coding, you know, written down in GitHub for us for us all to to benefit from.
So I'm a I'm a huge believer in contributing into the community, not just utilizing the resources that are there, but also giving back. And and to that point, I'm kind of curious, you know, how did you transition from just sort of chatting with folks around Secure Coding and and and having those those community conversations to becoming a really, really big contributor in something like, you know, OWASP or what what OWASP is doing with the ASVS?
You know, that's an interesting question. I mean, this is just my nature. It's like, you know, I don't I don't have kids. I have free time. I run my own business. I don't have, like, the standard nine to five job. I have a lot of freedom in my life to do what I wanna do. And it's very selfish of me to do this because the more that I give to OWASP, the more I do free talks, the more when some random person says, can you please mentor me? I need help. The more I do that, what's the side effect of that kind of behavior? It's, you know, I I I get recognition. I get kudos. I get the guy who I helped ten years ago, some, like, low level engineer who, like, barely talked security, and I gave him my time. Guess what doing now eight years later? Oh, he's a developer manager hiring me at no small expense to do like professional instruction with him. So being a decent human being, being a community supporter, trying to help people out, give free talks, It's just...
You can call it being a decent person, but it's also a good life and business strategy. I don't do sales. I don't do... I do sales. I'm sorry. I don't do marketing. I just try to, like, give to the community. And as a result of that, people wanna hire me to do training. And so it's it's my way of life, and it's... And I and I think it's an important one. And I... I'm not perfect. I make mistakes, but I I feel the more the more I give out to the community, the more I benefit from it, and the more my business benefits from it. And and more I emotionally benefit from it. Like, you know, what do I get from OWASP? People saying thank you to me a lot or grateful for my effort, and that warms my heart. So this is my business and life strategy to to give as much as I can to the community. It's something I've done for a long time, and I'm very selfish as I do it.
I don't know if you could describe that as selfish at all, but completely fair. Understood. So OWASP top 10 is widely used in the industry. I've referenced it all the time in my career. How does the top 10 and other OWASP projects as well, including ASVS that you've mentioned, and I know there are plenty of others, How do these projects help organizations learn about security and kind of focus in on their own security posture? Certainly.
Why do we get a lawyer? Why do we hire a lawyer? Mean, the law's all written down. Why not just go read the law and be your own lawyer? Because the interpretation of the law is super complicated. And I kinda see, like, security in that vein as well. Right? And so I'm not sure... Give me your question one more time. I wanna make sure I'm going down the right the right path. I... I'm going somewhere, but give me your question one more time, Bella.
No. You're good. I I think what I wanna talk about with you is how OWASP, I mentioned top 10 because I think it's referenced and used a lot, but really every single OWASP project. How do these projects help organizations learn about security and focus, like, focus on improving their own security posture?
And I wanna strongly differentiate because the purpose of the OWASP Top 10 and the purpose of the Application Security Verification Standard, ASVS, are very different. What I was trying to make is that... I get it now. That, look, we hire a lawyer because we have massive complexity. And when you're a developer who hasn't really addressed security in your career much, suddenly learning about security is like interpreting law. There's just so many little details you have to get right and it's esoteric knowledge. Less so these days, but it's esoteric knowledge. So what does OWASP Top 10 do? OWASP Top 10 is really for someone who is new at web security and API security. There's also the m... Really, the ASVS is really the W A S V S, web application verification. There's also the mobile and IoT and other ASVSs. But back to the OWASP Top 10, it's for initial awareness.
If you're a developer or a security professional and you want to learn about web security, this is a good document to start your research of web security on. But the thing is, you should read the OWASP Top 10 once and then put it away because honestly, you shouldn't be basing a security program or anything on the OWASP Top 10. The OWASP Top 10 is meant for one purpose only awareness. This is not just my opinion. This is actually codified in the introductory of the OWASP top 10 that explains, please don't use it as a standard because it's just a top 10 list. But it is a de facto standard because of how many. It's an easy thing to attach to. Oh, my product supports the OWASP top 10. Who cares? I mean, like, it's nice. I mean, I I don't wanna be that that much a curmudgeon, but to some degree, it's an incomplete message.
What you're... Because I'd rather you start addressing, hey. I I... My testing tool handles ASVS level one requirements according to the four point o three standard. Oh, that's a bit more comprehensive. So the OWASP Top 10, and I love it. I'm out there giving OWASP Top 10 talks like three times a day. I went to LinkedIn and said, Hey, anybody want a free OWASP Top 10 talk? I got my new talk. And I'm like, Okay, I'm booked now. Woah. So that... I love the OWASP Top 10 for breeding awareness, for giving conference talks as one of my training modules. Yeah. Then stop. Put it down and pick up the ASVS, the OWASP, Application Security Verification Standard, a comprehensive almost 300 requirement standard to help you as a web developer or a tester evaluate web security of web software. And now we can base a program off the ASVS standard.
We can fork it for our own standard. And it's... I love the team that works on it because it's like Daniel Cuthbert, Andrew Vanderstock's been a big part of it for a while. We have, Elar Lang, who's a new leader of the project, Joshua Grossman. We have, Svorn and several others who participate who are just amazing volunteers. And here's how I see the group. We are the biggest group of pedantic bastards I've ever worked with. Oh my. We will like fight to the death on like three words and a requirement and get really don't stubborn think I've ever been
Want those, oh, there you are. You're repeating the word cookie twice in that sentence and it doesn't make sense. And I love it. Can we all forgive each other? We move on, but we've... And this thing Does
We we need that level of meticulous eyes on the standard, though. And I wanna applaud... Here's the real driver right now. I wanna give him credit for what he's been doing. The person who's really been driving the most meticulous work of the standard and pushing us towards being a much more respectable standard is a gentle... A gentleman from Estonia named Elar Lang. And he... His work was so great. He was pestering me so much. I'm like, I am so sick of your constant pestering and demanding you do more work. Guess what? You're a project leader now. Boom. And he's... I'm I'm being a little joking here, but he's been a great project leader. And he's he he has that, like, real meticulous eye on each requirement and the structure of our document and everything that he's one of the reasons we just released four point o three, which really was a really great job. Thank you, Elar.
So I've I've got a question around this. So so looking at OWASP top 10 more as treating sort of symptoms instead of addressing sort of underlying root cause, which is what I think of when I think of ASVS. Right? So building that foundation and treating a root cause of insecure coding practices to both educate and to inform those developers. I'm kind of curious, right, because there's there's been a new inclusion in just the toe... OWASP top 10 that includes insecure design. Sure. And so as as a developer, right, I reference the OWASP top 10, and I look at these things so that I can sort of be informed as I'm coding things following the ASVS, but there's that interesting addition to include insecure design.
So so so when when we look at that, how does that tie back into the ASVS? And from a testing perspective, just just for those testers out there, right, how do they how do they begin to test for insecure design? Do they do they reference back to the ASVS? How does that tie together?
Let's take a step back first. Let's let's look at how the OWASP top 10 has changed in 2021. If you look at the 2017 category for for data loss, we called it like... I forgot what, let me go through this stuff real quick. We gotta go check this out. So I'm gonna open up my slide deck here. I'm so ready to talk about this. So I wanna look at how the cryptographic category changed from 2017 to 2021. So I got my slides up. That's my whole world. I'm ashamed to say I'm a PowerPoint expert. So cryptographic failures is the current category this year. That's the root cause. Back in 2017, we caused it... We called it sensitive data exposure. That's a broad symptom, but the root cause is you messed up crypto.
Right? Use a bad library or the wrong algorithm or you're not doing proper key management. So I like that change. Cryptographic failure is more like directed at the developer. Let's get crypto right. And now we can point in that, like, TLS right, do key management, use a secret vault, have a proper key life cycle, use the right algorithm, use a well library, and more. Take a look at the cryptographic storage cheat sheet to see some of those details. And so now let's look at secure design. This is a little controversial, but I like it. What we're trying to say... What this new requirement really trying to say? And this is the fourth one. Let me read this from the document. It says, A four, insecure design, is a new category for 2021 with a focus on risks related to design flaws. If we genuinely wish to move left as an industry, we need to do more threat modeling, secure design patterns and principles, and reference architectures.
So it's not just threat modeling. I like the term reference architecture because if you're a threat modeler and you're just walking into a meeting, start talking about security, you're like in one of those dinosaur blow up costumes. You ever see those little dinosaur blow up costumes like this? You're flopping around. So when you go into a threat modeling session, you want to have a plan, reference architectures that your company approved, secure design principles and standards you're trying to conform developers to. Don't flop around. Have a plan to conform the different projects to your standard architectures. And then I think the secure design is really useful. But the point is that the problems are not just individual technical vulnerabilities anymore. As we move to these really complicated end tiered microservice based systems, to software is now how we design that system is really critical upfront.
Go back to your traditional web app in late nineties and two thousands, it was a web server and a database. And it was really straightforward architecture most of the time. Today, I'm in the cloud, I got the Hadoop's and JWT verification and key management servers. And I'm breaking things up in hundreds of microservices. I got to have revocation endpoints in my... A lot more going There's lot more I'm using tons of third party libraries because of the massive complexity modern software sometimes is a part of. Planning that dive at the architectural level, I think is really important. That's what insecure design is all about. It's acknowledging that problems are more than just low level technical vulnerabilities. And if you don't think about your design ahead of time, trying to unwind an insecure design is massively expensive.
It sort of sounds like the 2021 OWASP top 10 is very, like, in keeping with the whole trend of shift left. Like, those multiple changes that you mentioned really make it seem like... I know earlier you talked about how OWASP top 10 should not be used as a testing standard. And I think in my experience, I see that like I see a lot of customers who say, hey, can you test for OWASP top 10? And I think that these changes really help to kind of say what you've been saying, which is like, this should not be a testing standard. You have to do more, you know, this is about kind of beyond that, if that makes sense.
The way I address this as an educator, as a as a tester, when somebody approaches you for the OWASP top 10, there's nothing wrong with that. That mean... What they're really saying is I need help with web security issues. They got trans... And then no... You know what? I can definitely help you with that OWASP top 10 testing, and here's and here's the category... Here's all the things we're gonna be searching for if you're a good testing company. You have a clear list of like what you're going after, not just... Here's here's what you don't tell customers. Yeah. Just trust us. We're gonna flop around and do some testing. We'll find
No. No. You should wanna let customers know what you're up to. Transparency helps. And I just... I don't... And people ask me, I need OWASP Top 10 training. Great. So I have my content broken down into individual learning modules. I'm like, Yeah, I can do that. And I give them a list. OWASP Top 10 is one of those items. And I show them all the 40 other modules I offer. It's never a problem. As long as you convert the OWASP Top 10 request from a customer into just a general web security ask, I've never had a problem with that conversation. And in fact, it gives... It's actually a good thing because when they ask the question, I know exact... When they ask the question, I know where they're at and what they're asking for instantly, and I can give... I can help them out. I know I can lend service to them. Yeah.
So I wanna talk a little bit more about OWASP ASVS. So I'm a huge fan of ASVS. I used it in my previous role as a pentester. I talk about it all the time now. My coworkers probably get really sick of hearing about ASVS from me. But one of the things that I talk about a lot with it, which you mentioned already... We we mentioned already was that it's a different approach to security than a lot of other, you know, references out there. And and then a lot is different than a lot of bug bounty and pentesting can be. It's that kind of proactive looking for security controls instead of finding exploitable vulnerabilities kind of mindset. So why is this approach to security important?
Know, ASVS is supposedly a set of requirements that both a tester and a developer can benefit from. And so let me open up ASV. Let me open up ASVS while we're talking and give you an example of some of these requirements for the sake of our conversation. So I'm going to, I'm gonna go do a little Google on OWASP, ASVS, and GitHub because all of our work is done very transparently right now. So I'm at the main GitHub repo now, and I'm gonna click on the five point directory English where our current work pushing towards the 5.0 standard is done. That's where you see the most recent changes. So I'm gonna go a little deeper into validation and sanitation and encoding section. Here are some requirements. Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the framework makes no distinction about the source and request parameters, GET, POST, cookies, headers, environmental variables.
I don't deal with this much in my practice, but that's the level of detail that you'll see in a requirement. And this doesn't give the exact answer. You can do a little more research beyond the requirement. Well, how do I test for HTTP parameter pollution attacks? There's a whole body of knowledge around that. As a developer, how do I stop it? Sometimes my framework handles it. That's mostly the common answer now. There could be some other problems as well, other things I need to do at my framework level to stop this. So the requirement is not about giving you all the answers. It's pointing to the problem as clearly as we can. Now, some requirements do get a lot deeper. How about this? Verify five thirteen in the five point bleeding edge branch. Verify that all input HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSVs is validated using positive validation and allow lists.
So we want to verify that all input, all of it entering your software goes through some validation layer. We're not specifying what the validation is. Am I going to do a regular expression? Am I going do numeric validation? Am going to use an HTML validator or sanitizer to do my validation step? That body of knowledge is super complex, but we're pointing, Hey, every input should have some kind of input validation. And we try to get deeper into that, into the different sections. But it's only about just this section, input validation and similar, it's about like 20 or 30 requirements. It's not all the answers. It's not like a... It's as comprehensive as we can get without starting to branch into details that are not common to all of us building web apps. When I start talking about, there's this problem in React or Angular and you have to do this, we keep away from those requirements.
We keep it so it's general, points you to the problem from both a defense and attack point of view to understand what a complete assessment or Secure Coding program would start to look like. So I'm not sure if I even answered your question. But
No. I think that that that absolutely hit it. I think, you know, again, I said this already, huge fan of ASVS, and I think there is so much value in that type of approach. And I think it's important to kind of discuss why, like, where does that value come from and how that is used both by, like you said, both by testers and by developers. So it's interesting to discuss that.
Let me add one more brief note to that. The way I think of it is, like, as a developer, I'm from the late nineties. We we used to do a lot of waterfall stuff, so we really planned out our requirements before we built apps. I see less and less that in the modern era, but we were very requirement driven. I started my career at GE, very engineering heavy firm. Is actually a big company back in the nineties. And so we were engineers and we wrote out our requirements. So my answer to your question is this is the list of requirements that's in the language mostly for me in developer language. This is how I build... Because I'm sorry, I rarely see testers being like, Let's have a requirements doc to plan this pentest. You know, I don't see... I see a lot... I got my tools. I'm gonna go do some scanning and hacking, pentesters. But for developers, we're a bit more requirements driven.
Here are the specific things that we need to build in this project for it to be complete. Our list of requirements, business requirements, as well as technical requirements that drive our work. And so this is in the language of developer building requirements that attackers and testers should also benefit from. And and to your point, Bella, that we moved the the... We've moved in that direction from the original version, which was mostly testers who built it. Now we're developer pack who are mostly working on it now.
I think... So I mentioned already, I I worked previously as a as a penetration tester, and this is... ASVS was a resource that I used a lot when communicating with customers. And I think, like, one of the values that that I saw and continue to see is that a question that I have heard from customers when doing pentests without this type of resource is like, Okay, but what was good or Okay ish? Or what what what was going on other than, oh, no, this is a critical vulnerability? And I think to your point, there are I think when developers are looking at an application and thinking like, you know, here are all the things that we have in place and then they get a pentest result that is here's one critical vulnerability in only one area. It's there's so much information that isn't there. And I think using a framework that that kind of covers everything is really helpful when you're able to communicate like, yeah, you know, we're we're only delivering this one vulnerability, but here's...
I think that's a really great point. It's it's it's a way to establish a baseline between a customer... Between a tester and the recipient of those results to understand how complete the test was. It's a great way to measure if someone is doing manual pen testing for you or if they have a tool scanning you even to measure how complete of a tool that really is, is to compare it against the ASVS for completeness. So again, it's got multiple uses for for... And and I I was even told that, like, there's the the OWASP testing guide, which is amazing resource. I know some testers who don't use that and use the ASVS instead because it's not as detailed per requirement as the testing guide, but it's more detailed in the completeness and the number of requirements to give testers an idea of things they should look for and to give customers an understanding of what the testers actually look for.
And a good tester will not only point out what was wrong, but will point out the good things they run into. Hey, I tested for deserialization like crazy. Didn't find any. I tested for this. Didn't find any. And that's way more of a mature pentest report out than if you're just showing them a few crits.
I think additionally too something... And again, this is me as a user and lover of ASVS. Something that I've noticed is that, like, ASVS offers the language to say, you know, here's an issue that we found, and here's the way that it should be. So it's not... The the the requirements aren't don't have this vulnerability. They're more like have this protection in place to prevent against this vulnerability. And so something that I've noticed in my time around pentesting is that when you're delivering a vulnerability report and all you say is, Oh no, you have this issue, it's really hard for a developer to do something with that unless they're super well versed in security as well because developers aren't coding in issues intentionally. They're trying to code things that work and that are secure. And so with ASVS having those, here's how it should be, that language is so useful in bridging that gap that we've been talking about because as a tester, you can say, hey, developer, like, here's what you should do.
I'm I'm with you. Like, look at the bleeding edge requirement five three four. Verify that data selection or database queries use parameterized queries. The main defense stops SQL injection. I did not help you as a tester find SQL injection. I mentioned that you should be testing for this and look for this. This is a white box test. This is actually looking in code to see how the coding construct was done. That's not a pentest requirement. That is a code review requirement to look for. So that shows developers how to really check to make sure the developer built that control correctly, and it directly informs the developer what the control is. This is another reason why I feel like ASVS has migrated more into a developer centric standard, right? Because five thirty four is not a pentest requirement. That's a code review or developer requirement.
I like to think of sort of pentests as as an obvious result as to how something's been put together. Right? And so if you've put something together and and maybe maybe you weren't aware of something like the ASVS or maybe you weren't aware of certain processes that you need to fall... Follow like like parameterization or or or filtering or something like that. Right? Then then a a pentest or or something along those lines are directly gonna call out those aspects in which you failed to implement. And then you can reference back to something like the ASVS to incorporate a thought pattern while developing that process flow. And so to that, understand there's different levels with ASVS in the framework that's around there.
Sure. Right now there's level one, two, and three. And level one is basically the way it stands today, this is what every app should have for level one. And these are things that are very easily testable via automation. Level two, we have these apps with more sensitive data, a bit more critical. Level two is a lot less can be test with automation. Level three is for critical infrastructure, is gonna require more manual testing. And I dislike these categories. This is one of my pet peeves. I'm trying to migrate ASVS away from just being a testing standard for levels and do what all other standards do, make them risk levels based on the... Based on, like, I want to map this more towards what NIST Special Publication 800-63-3 is doing. That's the digital media standard for US government, digital identity standard framework for US government.
And their AAL level one is for public data only. And AAL level two is for sensitive data and more serious risk. And AAL level three is like Fido and Smart Card for more infrastructure level security. These are risk levels. And the fact that we made it testing level, again, this started as a pure testing standard. I strongly disagree with these three levels mapping to different testing techniques because good pen testers use some scanning tools and I got to interpret scanning results with a pen tester and what's automated and what's not is really a muddy topic. I don't know any pen tester who only does manual testing. They're all being aided by a wide assortment of automated tools to get your job done better and faster and more thorough. So, we're in the middle of this discussion right now.
In fact, if you go to the issue tracker, by the way, Bella, anyone who really loves ASVS, know what they do? They contribute. I'm luring you in to submit issues. You see anything wrong? I want your feedback. But if you go take a look at, let me do a quick search, risk based, let me see if I could, that's my big cry now. Let's make these levels risk based instead of testing based. If you look in our issue tracker, issue eleven twenty seven, you're gonna see Elar and myself and some others debating whether or not we should be at testing level, which I don't agree with, or risk level, more in line with NIST standards. And we're debating that right now. Join the debate. Again, this is issue eleven twenty seven at the ASVS GitHub repo. Jump in and give me your perspective.
Think it's funny that that we are talking about this because one of the biggest questions that I've gotten from from customers when I've talked about ASVS is like, if I say, okay, based on what, you know, the the... What type of business you do, the things I'm going to test, we should probably test with or, like, we're gonna use ASVS level two. And so many times I've gotten customers say, like, well, isn't level three the best? I wanna be the most secure. Can I use that one?
Oh, Bella, I'm help you out here, Bella. Bella, work with me here. Hey, Bella. I think we should do a level two a level two ASVS test. What do you think of that, Bella? Go ahead. Give me that.
I agree. Level three is the best, Bella. Absolutely, we should do level three, and that'll be an extra $35,000, please, for that assessment. And, like, checkbox. AA level one, $10. AA level two, 25. AA level three, we're gonna... Oh, you know what? I agree with you. You know what, customer? You are right. You're brilliant. You've read the standard right. You know what to do. I'll take your extra 35,000 in cash or gold bullion.
it. And, also, Bella, I'm joking around, but that's a fair answer. If you want an AA level three assessment, you gotta pay. Or someone's really nice giving you, like, weeks of free service. But AA level three, you gotta pay. And there's nothing wrong with that. Security assessment's expensive. There's... And we're like lawyers. We're specialists. And you need us right now. So AA level three is not cheap, and that's okay. Yeah.
So so shifting a little bit from ASVS, but still staying on the development topic. Right? So you've described yourself as as sort of the self professed, like, developer, both in nature and heart, and you originated from the developer space. I'm kind of curious. For those individuals coming up into the development space, what what is sort of that that thing that you would recommend to them that... For those individuals just getting started. Right? What would you recommend to those individuals?
Right? Just getting started. IT career? Yep. Look, every time I say this, I upset people I care about. So I want the... So I just want you to know when I state this opinion, I'm not trying to offend anyone. It's just my opinion to have a good career. The act... That comment, the controversial comment is learn how to F'EN code. And you don't have to be an expert at it. You don't have to be a software engineer. But if you're an IT professional and you don't even understand the basis of coding, it's going to limit your capability. The best pen testers I know, hey, they write scripts. They automate some of their work. And you don't have to be like an uber, like super coder who's coding sixty hours a week or whatever or more, but have some understanding of what the discipline of software engineering is. Do some of it yourself and go take one...
There's like a million online free classes to learn the basics about JavaScript. It would take you, even if you're a non coder, an hour to watch one of those tutorials and write some basic JavaScript that runs in the browser. And guess what? Now you're a little bit of a coder. So when I say this, people who are in management or people who do GRC take great offense. And I don't say this to offend anyone. I'm just saying that when you have a base knowledge of doing some coding, it's gonna benefit every other type of IT discipline, and I encourage you to do it. Nobody wants to hear this, Jeremiah. They get mad. So when I
One of my good friends, Ben in GRC, blocked me when I said this on Twitter, and I'm still I'm still hurt because he was... Because he's a GRC guy who did not get a job he wanted because he didn't know how to code. And I wasn't saying it to hurt his feelings. It's just that there's a lot of people who don't code. Take... I can I can get a 100 people throwing smack at me because I say this on Twitter? Hey. Start your career. Learn to code. Here's a little tutorial. It'll benefit your career. Again, it's controversial for some reason, but I stand
by I think if you can code today, it's a little bit like being a wizard. Right? And so I'll tie this back to something. If you can code, you can you can almost create anything that you can think of. In addition, it's gonna benefit anything that you do going forward because you could both automate, you can streamline, you can alter the effectiveness. There's so many things you can do from a coding perspective. So I align very much with that statement personally.
Yeah. That's the first thing I would do in my career. Learn a little... And here's the second thing I'll recommend. Right? Here's number two. Understand how AWS works. Understand some of the basics of what it means to use a cloud service to deploy software. Even a little bit... Even just... Like for me, I spent like an hour messing with some of the AWS consoles and I'm like, boom. It opened my mind up so much to what capabilities are there so I can talk about it more. It took me an hour of looking at their admin screens to have my brain explode. So start to understand cloud deployment of software, that's the future of the world and understand a little bit about coding. It's gonna help your career in really significant ways.
So continuing with advice, but I wanna hit kind of a a different crowd here. Do you have any advice for organizations that are, like, beginning to implement a DevSecOps program?
How do you start DevSecOps? Right? I'll give you some... The thing is, I don't like talking about DevSecOps because it's usually, like, a lot of buzzwords, and it's very, like, nonscientific. I like talking about digital signature types for for JWT validation. That's hard science. So DevOps Yeah. Alright. I'll do it. I'll do it. DevOps is all about automation. Anyone tells you differently, they're just wrong. It's all about maturing your automated capabilities. And yes, there's a culture change. Where's my violin? Oh, DevOps culture change. Yeah, whatever. Automation, CICD is what DevOps is all about. And in the world of security, it's about automating your security testing program. So here's my advice. My advice is get an automated pipeline going that does one thing for testing, just to start with, run static analysis against your code base as a blocker. I'm gonna recommend a tool that I'm affiliated with.
I'm a little biased. I'm gonna recommend a tool called Semgrep from r2c because it's free, and I ran a 5,000,000 line code base in like fifty seconds. Boom. Now I can integrate GitHub, automated pipeline easy. So that's one... Just one thing to get started. Wire in static analysis that runs fast and use it as a blocker before you allow a check-in to come in. There's one achievable simple security goal from a DevOps pipeline perspective. Here's the second thing I would do. Why... Get Dependabot up and running to give you PRs when your third party libraries are out of date. There's another thing. And those two things alone, if you can mature your capability at running static analysis and running software composition analysis, third party library scanning as a blocker for every check-in. Woah, now you're starting to do...
I don't care about DevOps, DevSecOps, right? The security testing part of DevOps, that's a good place to get started, I would dare say. I wouldn't start with dynamic scanning in the DevOps world. It takes too long to run a dynamic scan. I wouldn't use a traditional static analysis engine in a DevOps workflow. They take hours to run and devs don't wanna wait hours to finish a check-in. So use one of the newer lean, mean, fast static analysis engines to scan your code for security and check your third party libraries for out of date security issues as your first main tasks to automate security in the DevOps pipeline. Boom. There you go.
I like this advice because I think like we're having a... A lot of times, I hear this a lot at least, security is is like an annoyance and a blocker and it gets in the way of things. It slows processes down. And I think sometimes there is, you know, I'll say I've experienced it. There's some animosity from developers when working with security professionals because we get in the way. And I think it's really cool to have this conversation where, you know, we've been talking about a standard that is like kind of designed for developers to use. You're giving advice that is, you know, you're addressing that knowledge of like slowing things down is not fun. And I I just think it's really cool to be be able to have this conversation while, you know, conscious of the things that people don't like about security.
Absolutely. One of the power of DevOps is to get security professionals out of the way. It takes a huge amount of automation and scripting work and similar to get there. But the point of DevOps is, I'm going to check-in code and that piece of code is I want to go to production. So we're going to run through a bunch of static analysis testing, pass. I'm going to look for third party library scanning, pass. I'm now gonna do the build and get ready to deploy. I do pre build testing and those tests all pass. So guess what? You're live. And who stopped me? No one. How about this? Oh, can we talk about that requirement first? No, you're out of the way. Or can we do a threat model first? You're out. Or I need to review those results. You're out. Any people who get in the way of a live release, that's what DevOps is about. And it takes mammoth automation, security testing and discipline process to be able to get that reward for all of your work in building a proper testing pipeline.
the overall shift left you know, mentality impacting the industry as a whole? Is it shaking it up a bit, or or what are you what are you personally seeing?
It depends on it depends on the the kind of company and the pressure they have to write secure software. But one my customers doing training for me for seven years now, and they're in a medical field and they're doing well. And they really care about not hurting people. So they're... One of their... One of the risks they worry about is, like, public safety and similar. And so ever... I gotta watch what I say with them because they take all my advice. And and they they they take my advice seriously is what I'm trying to say. And I've watched them, like, seven years ago, SQL injection was an issue. I look at him today, and they're running a pretty badass scanning collection of tools and testers at their stuff and it's bouncing. It's not because I'm not because I'm, you know, dumb a teacher, it's because they took... They they did the work for years and developer security was never questioned for them.
They're in the world of public safety and medical and they just do it. And they, little by little, matured their capabilities over seven years, and now they're security rock stars. Absolutely rock stars because of their subtle shift left over many years as a company.
Again, I I think it's a good life and business choice to volunteer your time to help the OWASP foundation do better, help everyone do better at web security. And Bella, I'll be looking for your issues or PRs or any feedback you have. If ASVS you as much as you do, then you will you will share your amazing knowledge with us and help us out the project. So I'm I'm waiting
Here's an honest truth, Jeremiah. And it's it's not it's not something... It's just the way I'm built. I'm I'm pretty transparent, open book. I don't carry a lot of secrets. I don't have a secret vault. I have a big mouth and a lot of like open nature. And even when I don't want to, I usually just say it like it is. So I'm not built with a lot of, I don't have a secrets vault. I I have a big mouth. So there there... There's some people... Everyone knows about me who knows me because I'm a big talker, and I'll say anything, and I'm an open book. Alright. That's it. That's my story,
Jared. Awesome. Thank you. Again, like Bella said, thank you so much for joining the show. I know I've certainly enjoyed speaking with you today. It's been a pleasure.
Does your penetration testing meet compliance requirements? Does it adhere to the most rigorous security standards on the market today? Now you can find Synack on the FedRAMP for all of your agency's security testing needs. Synack recently received moderate in process status from FedRAMP, meaning that even more US departments, agencies, and contractors can utilize Synack's global network of trusted embedded security researchers for on demand around the clock pentesting. Learn more at synack.com. That's synack.com.
If you like today's episode, please give us a five star rating and subscribe wherever you're listening to this. It'll really help us get noticed on your favorite podcast platforms. Also, you can share this episode with your friends and make sure to check out all of the other fascinating people that we've already interviewed. We're also open to your suggestions. If you know someone that we should be talking to, drop us a line at we'[email protected]. That's we'[email protected].
