---
title: "Ochaun Marshall -- IaC and SAST"
url: https://appsecpodcast.com/ochaun-marshall-iac-and-sast/
date: 2021-11-29
duration_seconds: 2189
guests: ["Ochaun Marshall"]
topics: ["Security Testing", "Software Supply Chain", "Cloud and Infrastructure", "Privacy and Compliance"]
audio: https://www.buzzsprout.com/1730684/episodes/9629625-ochaun-marshall-iac-and-sast.mp3
transcript: true
---

# Ochaun Marshall -- IaC and SAST

*November 29, 2021 · 36 min*

with [Ochaun Marshall](https://appsecpodcast.com/guests/ochaun-marshall/)

on [Security Testing](https://appsecpodcast.com/topics/security-testing/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/), [Privacy and Compliance](https://appsecpodcast.com/topics/privacy-and-compliance/)

[Audio](https://www.buzzsprout.com/1730684/episodes/9629625-ochaun-marshall-iac-and-sast.mp3)

## Show notes

Infrastructure as code gives security teams something they have wanted for years: a readable description of the systems surrounding an application. Ochaun Marshall, a developer and application security consultant, explains how that visibility complements static analysis and penetration testing. He discusses where SAST belongs in development, what configuration files can reveal about cloud resources, and why deployed infrastructure still needs monitoring. The conversation covers Terraform, AWS development tools, open-source scanners, and using source access to make a penetration test more productive. Ochaun and Chris then connect those technical practices to developer empathy, explaining why overwhelming engineers with findings undermines trust and how a smaller, carefully tuned set of checks can make security genuinely useful.

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

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

Connect with Ochaun Marshall:  
→ [Ochaun Marshall on LinkedIn](https://www.linkedin.com/in/ochaunmarshall)

Mentioned in this episode:  
→ [Semgrep](https://semgrep.dev/)  
→ [Bandit](https://github.com/PyCQA/bandit)  
→ [Terraform](https://developer.hashicorp.com/terraform)

Chapters:  
00:00 Infrastructure as code and SAST with Ochaun Marshall  
02:35 Returning to cloud application security  
06:32 Where SAST fits in development  
07:15 Scanning applications and their infrastructure  
09:53 Configuration files versus deployed assets  
12:19 Rebuilding infrastructure instead of changing it manually  
14:23 Infrastructure programming with the AWS CDK  
17:19 Using SAST during a penetration test  
20:26 Open-source tools in the testing toolkit  
25:06 The security benefits of infrastructure visibility  
26:55 Tagging resources and monitoring changes  
29:06 Developer empathy under delivery pressure  
32:14 Introducing security checks without overwhelming developers

## Transcript

*5,826 words · assemblyai*

**0:00 Chris Romeo:** Oshan Marshall is an application security consultant. In his roles at Secure Ideas, he works on ongoing development projects utilizing Amazon Web Services and breaks other people's web applications. Oshan joins us to talk about SAST and IaC, static application security testing and infrastructure as code. We talk about what they are, how they work, the security benefits, some of the tools that make them possible, And then we finish our conversation talking about developer empathy and why Oshan has developer empathy as a result of some of the experiences that he's had as a developer and as a security person. We hope you enjoy this episode with Oshan Marshall.

**0:42 Ochaun Marshall:** You're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other show, High Five.

**0:53 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey. I'm also joined by my co-host Robert Hurlbut. Hey Robert.

**1:05** Hey Chris. Yeah, Robert Hurlbut, Threat Modeling Architect. Really glad to be here again talking about security.

**1:10 Chris Romeo:** It's all about application security. Every day we eat, sleep, breathe application security. When everyone else is sleeping, We're reading blog articles and looking for guests somewhere. So, I've had a lot of fun in the last couple of weeks. I was at LastCon and was sitting at the speaker's dinner doing what I normally do, which is sit off to the side and watch the sociological things happening around the speaker's dinner as a scientist, I guess. And so, I got talking with another one of the speakers who was talking about blockchain and AppSec and the connections in between them. And so, Let me tell you, I went down into the deep end of blockchain over the last 2 or 3 weeks.

**1:55** Wow.

**1:56 Chris Romeo:** I've listened to every podcast I could find on blockchain security, read every blog post, read everything I could find from Ethereum and all these other kind of sites and non-fungible tokens and proof of work versus proof of stake and all these concepts. And so, it's just fascinating. I don't know that I— I probably understand 5% of it at this point. So, but that's been kind of my journey in the last couple of weeks. And I also had a chance to go on the Down the Security Rabbit Hole podcast with Rafael Los and James Jardine talking about— Robert's going to shock you what the topic was, but it had to do with threat modeling. I know that's going to shock you.

**2:33** Oh, really? Threat modeling?

**2:35 Chris Romeo:** Yeah. I don't know that there's anything else that I can talk about at this point. Well, I can talk about general AppSec stuff as well. So, we're super excited to have O'Shawn Marshall back with us today. Oshan, this is his second visit to the podcast. Previously, we discussed securing web applications in AWS, and now that we've solved that, we're able to move on to another episode, right? I mean, everybody, everybody that's out there using AWS is like, wait, what? You guys solved that somehow?

**3:02 Ochaun Marshall:** How'd you, how'd you do that?

**3:03 Chris Romeo:** So, yeah. So, Oshan, welcome back to the show. We're so glad to have you with us again.

**3:08 Ochaun Marshall:** Glad to be here. So, yeah, let's get ready and get started.

**3:12** Excellent. You know, Sean, we were just talking a moment ago about this closed S3 bucket story you were mentioning. Tell us more about that and what happened.

**3:22 Ochaun Marshall:** Okay. So you know how in pretty much every headline it's like, oh, open S3 bucket that's just open out into the internet. And my story is kind of the opposite because as a like because I work for a pen testing firm, the whole security culture is different. So as I was working with the infrastructure around the app, we had to use some S3 buckets for some things, and I was messing with the bucket policy, and I actually did a deny statement in there, but deny with the star on action, meaning like for this particular bucket, all actions of it are denied. And I was just fiddling with it because I was trying to troubleshoot an access issue and I've locked myself out of the bucket and I knew it was bad because it's like the console wasn't responding at all. And then when I refreshed the page, the access level allowed to me was error. So at that point, like every action that includes read/write access, being able to look at the bucket, look at objects within the bucket, all of that, and being able to upload or download or delete or modify or delete, change the bucket at all, anything related to what's in it, the bucket itself and what's in it, completely locked out of it. And administrative— I assumed role— tried it with administrative access and tried to mess with it. Then it's like, nope, nope, I can't mess with it. So I had to Go to infrastructure team, have someone with root— with assume root user and then delete the policy because that was the only way I would actually be able to mess with it and work with it again.

**5:15 Chris Romeo:** So when I think about that, I'm like, hey, finally a secure S3 bucket. Yes, let's do this for all of them. If we could apply this policy across the enterprise, we would never have another data breach as a result of S3 buckets.

**5:29 Ochaun Marshall:** Yes, absolutely.

**5:30 Chris Romeo:** You wouldn't be able to use the buckets. No one would be able to do anything with them.

**5:33** You're secure.

**5:35 Ochaun Marshall:** I mean, listen, like, let's forget the A part of the triad, you know?

**5:39 Chris Romeo:** Oh, wait, that's in there. Ooh. Yeah, no, I have a, I have a number of certifications that caused me to have to say that I knew that the A was for availability. But yeah, that's, that's interesting that they let you go down that corner case of being able to create something I'm almost imagining like a denial of service loop condition where somebody's creating these buckets. I mean, it would take a lot of buckets to be able to cause some denial of service condition in AWS's world, but still seems like there's a threat there that if you wanted to pull on that thread, it would be possible.

**6:12 Ochaun Marshall:** Oh yeah, absolutely. So you should, you could, there are many ways you can just make, lock things down. It would be like ransomware for the cloud easily. Now you've given me another nightmare.

**6:31** Why?

**6:32 Chris Romeo:** That was not my intention. This is, you know, we do a lot of threat modeling around this podcast as well. We not only do we talk about it, but we also apply it in how we think and what we do. And so that threat was jumping off the page at me like, ooh, denial of service condition. Love it. Well, that's great to hear that perspective and to hear how you were able to create that thing in the cloud. But I want to transition us into talking about SaaS and infrastructure as code, not 2 things that I normally speak about in the same sentence. Normally, I think of SaaS as being something very separate from my infrastructure as code. But from your perspective, where does SaaS fit in?

**7:15 Ochaun Marshall:** for a security program? And I'm going to say not everywhere, not at the beginning, obviously, because there's no code, and definitely not the end. And the best place is honestly in the middle of it all. So in some cases where on the application itself, running— they're running the SaaS tool is just be able The goal is to find high-level, like OWASP Top 10 sort of items. Like, that's what you're trying to get when you're trying to scan it and look for those type of vulnerabilities within the application. But one of the beautiful things about SAST is, is that you can analyze source code without running it. And now, since now that you have infrastructure as code, you can actually— there are some tools out there like CFN Lint and CFN Nag where you can actually not only just scan the web application, but the actual infrastructure surrounding that. And when I go to your local BSides or talking with security practitioners, it's just infrastructure as code is just one new like dev feature and new thing. And what blows my mind is like no one is rejoicing about this. Like we've been asking development teams for years to like, all right, we need a detailed inventory of your infrastructure you're going to use and the configurations to manage it all. And we have that. We didn't even ask. We've been asking for that for years and then they just handed it to us. That is what infrastructure as code is. And like once you actually see it as that way and there's like, no, I actually know what's on this EC2 instance, including the AMI, down to the configurations of the machine, like whether or not if it's encrypted at rest, and you can analyze the IAM policy. You have that in your hands. And I don't get why people aren't like rejoicing that that is the greatest thing, because it is. It really does help get a big picture view, not only the application, but the nest, the rat's nest of infrastructure that surrounds it. Yeah.

**9:36 Chris Romeo:** So, I'm going to give kind of an alternative thought about that, and I want to see how you kind of react to this idea. But infrastructure as code is a set of configuration files that define what we're going to build.

**9:52 Ochaun Marshall:** Yes.

**9:53 Chris Romeo:** It doesn't necessarily categorize the assets that I have in production or in a given cloud provider. So, yeah, it does give us— I think it gets us part of the way. But does it get us all of the way? Because we still have to have some type of monitoring of our actual assets, because, right, because like cloud, like Terraform, for example, is a set of configuration files that are saying, hey, run it, and then we'll spin up these EC2 instances and have them be connected in this way and all that. Like, there's still, for me, there's still a disconnect there. Now, am I onto something or am I just going in the wrong direction?

**10:26 Ochaun Marshall:** For the most part. And this is unless you go— and this is unless if you go into like the console or programmatically make some changes that aren't in the CloudFormation template, that aren't listed in those configuration files, then yes, you will get some deviation. That's absolutely sure. But at that point, you shouldn't be doing that at all because it makes it— defeats the purpose of infrastructure as code. The whole point of being able to have the configuration files to spin up and build the infrastructure in the first place is so that you can delete it, you can tear down, you modify it and have a centralized location and know what and know how it, what it, how it connects to other resource cloud resources. You need to know the IAM policy set into it. It actually makes the solution as a whole less reliable if you go in and make those sort of changes. So you'll get that sort of deviancy. And so yes, you will have to monitor that on the other end, and you'll have to have that. But if you, if you try to go back to the best practice, and this is not a security best practice, this is just, hey, I want to build a web app that, that is continually able to function sort of best practice. You would keep it, you would keep the configuration files, have those be the source of truth for the infrastructure. And it's honestly easier just to, if something's not working, tear it down, build it back up. I mean, your bill's gonna run over, but yeah.

**12:18** Yeah.

**12:19 Chris Romeo:** I mean, and I only have a sample size of one. I'll say this for my infrastructure as code kind of knowledge of how it's being used in production. And so I'm curious to see if this is consistent with what you've seen in maybe a bigger IaC-style community. But the way we approach infrastructure as code here at Security Journey is we're using it to deploy various components to build up services in AWS, for example. And we're not touching them at all. Like, we're using— Terraform is doing all of the build process for us and nobody's doing anything. If we need to, we just burn it down and we kick up another one, right?

**12:55** Yes.

**12:55 Chris Romeo:** Like, it's that. And so that— but I've only got a sample size of one. And so I'm curious from what you've seen, I know as a pen tester, as well as somebody who's focusing and watching IaC, is that consistent like in a large enterprise that they're having that level of discipline?

**13:10 Ochaun Marshall:** Unless you have it locked down to the point where the administrator, like certain administrators can't tear it down. So there have been instances like that. Again, I'm, as a developer, I have a sample size of one. As a pen tester working in a, tinkering with other people's clouds, it seems to be the same thing. Your goal is for IaC is just to spin it up and if it doesn't work, tear it down, make one tiny configuration change to the file and then spin it up again. The dev cycles on that, like building infrastructure, is horrendous because I've worked in a pre-CBK and post-CBK world and we can go on and talk about that a little later. But if you're manually messing with the CloudFormation template, it can— you have to just wait like what, 10, 5, 10 minutes, it feels like for it to tear down, make that little tweak and then wait for it to build back up slowly. So yeah.

**14:20 Chris Romeo:** You said CBK.

**14:22 Ochaun Marshall:** Oh yeah.

**14:22 Chris Romeo:** Does that mean—

**14:23 Ochaun Marshall:** I don't know the— no, CDK. CBK is Common Body of Knowledge. I'm studying my CISSP at the same time. CDK is the common body of knowledge in the CISSP. But CDK is a new programming interface for infrastructure as code. So before, you would normally, you get your YAML, you get your JSON, you write out your configuration files, and then you would just run that and hope and pray that you actually follow the documentation correctly and that it would work. And you wait 10 minutes only for a failure. Now for like the CDK, you've got 3 levels of infrastructure configuration. So you can be at a high programming level and say, look, I just want a deployment pipeline that gets from GitHub, does code has a, has a CodeBuild project and then deploys to an EC2 instance. That is actually a sort of template that you can craft on and then you could just write that configuration at the high level without writing manually the 600 lines of YAML or JSON that would actually be in the template. So it's sort of, it's sort of like the same use case with Terraform. for a lot of people. So I personally don't use Terraform. I've seen organizations that have used it and is successful, but usually in our shop we try to keep it AWS native because if we build it and say, and then, and then the client comes back and asks, oh, how keep— how do we keep this secure? And we can't give them an AWS native answer.

**16:19** Right.

**16:20 Ochaun Marshall:** we felt that that wouldn't be the right way for us. And this was just how we built things.

**16:24 Chris Romeo:** Yeah. So I did have one other question about SaaS. I know we started on SaaS and then we, we went down deep into the IaC world, which is great because I learned some things. And yeah, when you said CBK, I was like, CBK, common body of knowledge. I don't understand how that works, how that fits in here. So thank you. I didn't even know that the CDK, I didn't even know that was a thing. Like I didn't know there were different levels of like a high level where I could, you know, write a very few set of lines and then it, you know, ends up resulting in 600 lines of a template. So that's helpful. And there's got to be some attack surface and threats that exist inside of that somewhere that we could dive into on another day. But I know for you as a pentester, let me kind of switch back to the pentester side of the house, side of your brain. We were in the dev side. Let's switch back over to the pentester side.

**17:16** All right.

**17:16 Ochaun Marshall:** Click, click.

**17:19 Chris Romeo:** So when you're— how do you use SAST as a pen tester? So I'm fascinated. I've always thought of SAST as like, this is a tool I use for my devs. It helps them to figure out where the problems are so we can fix them. Like you said, you know, somewhere in the middle before we get something closer to production. But as a pen tester, how does SAST fit into your world?

**17:37 Ochaun Marshall:** And so I've done this talk on this and I'm trying to bring it back to like TTP, like In this case, I'm sort of re-changing— I'm changing another acronym on you. Instead of— it's just tools, techniques, and then people. What I do not want to bring SAST into as a pentester, as a security consultant, I do not use SAST as a club with which I bludgeon the dev team into some sort of compliance. The SAST is just a starting point in which you can make some initial investigation because any static analysis tool will need multiple runs and will also need configuration changes as well. So there are— there is like a pure code review where we take every SAST tool that we can find that is open source. Sometimes we even use Veracode. if the client requests that, and we would just do formally focus on, all right, is— are there like OWASP Top 10 level types of vulnerabilities? Are there like subtle vulnerabilities within there, within the code base itself? And then you can stretch the gambit to a full-on like white box penetration testing engagement. And, you know, like normally it Penetration tests are either black box. You have this web app, but you don't even have credentials. You have nothing. You're supposed to just. It's like let's see if you can get in. Gray box is your what most people do. Hey, you've got some credentials. You've got access to this web application. You can see it as an admin. You could see it as a low-level user. Let's see what you can do within the application. What vulnerabilities you can. find. Full-on white box assessment that we like to do with SAST is, all right, we have access to the source code even. So not only do we have like the ability to dynamically test, dynamically test vulnerabilities within the application, we can actually run our SAST tools against the source code. All right, this part like seems weird. Let's see if we can actually exploit that as a user. And that's the area— white box assessments, I love when that happens because you can like get a deep dive, you can get in the weeds, and you get a full-on understanding of the solution that you're testing. And you can pop CVEs like that. You can find a lot of things that you wouldn't be able to find if you were just even in a gray box situation, just poking at it, throwing requests at it and see what sticks, you know.

**20:26 Chris Romeo:** So you mentioned open source static analysis. What, what are your, what are your go-tos? I have a, I have a guess as to what one of them is, but—

**20:35 Ochaun Marshall:** SonarQube?

**20:37 Chris Romeo:** Shall I guess?

**20:38** Yeah, sure.

**20:39 Ochaun Marshall:** Go ahead.

**20:39 Chris Romeo:** I was wrong. I was wrong. I was wrong.

**20:41** I shouldn't have guessed.

**20:42 Chris Romeo:** I should have— I shouldn't have even said anything about guessing. I was going to say Semgrep. I thought Semgrep might be on your list.

**20:47 Ochaun Marshall:** Semgrep is something that we're looking into. So I've actually heard a podcast on Semgrep. We actually spin up a Vagrant box of static analysis tools. That way we can like keep the— because for clients, typically if we're doing like source code review, that's like, that's trade secret type of information. So you would like to— So you would like to safely not have that sitting on the host machine and safely dispose of that later once the engagement is done after a certain retention period. So yeah, we are, we are, have been looking into incorporating some grep into the toolchain. You haven't yet. The go-tos that we've had so far is usually like Yarn audit, npm audit for JavaScript and Node. Like everyone runs Node. And so now this is much less of a SaaS thing, but more of a dependency checking thing. So what you will find in an npm audit or Yarn audit would be, all right, your dependencies, your packages, your— not full SBOM, like software bill of materials situation, But hey, what patches are you missing and things like that? There are, there's Bandit is an easy go-to for Python, whatever tools that we will pick up. And I can just, if you, you have to stop me because I will rattle off multiple tools because usually when a client hands us a solution, it's in multiple languages. So we will pick multiple different tool sets based on—

**22:37** Mm-hmm.

**22:38 Ochaun Marshall:** that particular client. So if C#, we do use PumaScan and Security Code Scan as well as, as well as some other tools and things like that depending on the language and the tech stack.

**22:54 Chris Romeo:** Yeah, very cool. We've, we could also, you know, have fun going through lots of different SaaS tools and stuff. We have had Drew Dennison from R2C, the company that's behind Semgrep, that he's been on the podcast in the past too. So we got a chance to dive deep into kind of how they were doing. Because the thing about Semgrep that just blew my mind is like, they're doing this at lightning speed. Like, I'm used to SAST in the enterprise where it's like, you know what, we're going to take a vacation and when we get back, we hope our scan will be done. I know it's been 7 days, but it's almost time. And then Semgrep is like, bloop, bloop, bloop, done. Like, you're like, wait, SAST just happened? Are you sure? Might have just been a fault. You know, it hasn't even been 24 hours yet.

**23:36 Ochaun Marshall:** And that's how SAST has to be. Okay. And this going back to a previous question that you had on where does SAST in a security program, I'm going to put on the— since you've turned on the consultant security consultant switch, I have to say it depends. And I will say SAST is nowhere in a security program if it takes excess of 10 minutes and thousands of dollars per each run and per each scan. That's, that's not, it's not how it works. That's not how it's going to happen, especially since the— you don't get— you have to then manage it, do the configurations and all of that. So we— it should be in the worst case scenario, minutes, but it really should be seconds. You should be able to look at the code. and see, look at the code, see vulnerabilities, see certain consistent patterns like, hey, we're taking user input and then somewhere down the line we're concatenating it into something that we query in the database. Now, you may, your wheel may be turning, you may be thinking I'm talking about SQLi, but there are plenty of other injection flaws where that is where that exact pattern shouldn't be present, and it should be easily discoverable by looking at the code.

**25:06** Talking about IaC, I know some of the benefits for developers and thinking about structuring how they're putting together some things, but what about from a security perspective? What is one benefit that you can think of from IaC perspective?

**25:24 Ochaun Marshall:** The security benefit is the ability to inventory. So for like that, the fact that, all right, we've got a list of, we've got a list of AWS resources that are closely coupled and closely tied to this. So if you are the one guy managing, one security person managing at least 20 dev teams, you need to like, if you want to see, if you have questions on like how is this particular EC2 instance, how is this, how is this particular container or deployment pipeline, how is this being secured? You have the answers, you have the answers in that, in the— you should have the answers to that in the configuration files because you have access, you have visibility, you can actually see like where you can actually see the resources that are currently being used. So like, I know that's kind of a repetition of the previous benefit, but it is the number one benefit. Like inventory, like this is, I think, is it still OS number 9? Is it top, not number 9 in the top 10? Like inventory access and— No, I think it's number 8. Logging and asset management.

**26:50 Chris Romeo:** I think it's— I think number 9 is logging and monitoring.

**26:55 Ochaun Marshall:** Logging and monitoring. So now you can— so now you have the ability to monitor the infrastructure around it. So I'm repeating myself, but that is really the benefit to security teams is, hey, you now know like everything that you now know most of any dev team that wants to push things quickly, most of the infrastructure that's closely coupled with the app. Now, if you've got a DevOps situation with a strong security influence, I will not say DevSecOps because that's a slur to me. You can then have tagging set in the CloudFormation template. So that way all the resources— so for billing, for example, this particular resource is taking— this particular set of resources is getting really expensive. Is there a way to re-architect, re-engineer that? Another way is, hey, this isn't— these particular sets of EC2 instances aren't on the usual maintenance cycle. Meaning the underlying OS systems aren't in the cycle where they get patches and updates, and that is scripted and automated frequently. So the ability to tag resources then gives you the ability to see that. You can also set scripts to only point to those tagged resources and then run those changes, and that should be automated. The maintenance, like, the maintenance, the same, like, scalability problems that you will find in most DevOps shops are the same scale, are very similar to the same sort of problems we have as security practitioners. How do we defend? How do we reinforce? And then also from an adversarial offensive position, how do we assess the solution as the security of a solution as a whole?

**29:06 Chris Romeo:** Yeah. So, we've talked about SAST, we talked about pen testing, we talked about IaC, we've talked about how these things all kind of fit together and support or are mutually supportive of each other. I want to end with yet another topic, but it still influences all of the other things that we've talked about right now. And Robert and the rest of our listeners know that They're almost getting sick of me talking about developer empathy. I feel like I've said those words many, many times in the last year, and I'm going to keep saying them over and over again until we all get it. But you had, when we were kind of preparing for the interview, you had sent something and said, you know, hey, how can you empathize with devs pushing into production? And I was like, ooh, this is a topic I want to hear Oshan's take on this because I'm a big developer empathy person from a security perspective, but I want to get your take as well.

**29:57 Ochaun Marshall:** So the reason why I can empathize, and I can speak for myself, is because I work for a small business. And not only— all we are all pentesters, like, like a vast, overwhelming majority of us are pentesters. So not only as I'm a developer, I'm also a pentester. The reason why I can empathize with the dev teams is because, um, in August I had a 2-week sprint where I had to get an internal application running from off— running off of my laptop in a VM into a production environment in 2 weeks. And so I had written code, I've written the application, but deploying into production is complicated. And so there were times where, okay, I've had to work with the infrastructure team and tried to figure out solutions. One is like, okay, I know in your dev environment you do this, but in production, infrastructure has to be listed off in this sort of way in order to align with security best practices because we are a security company. So pushing through that without doing all-nighters, because that's the one thing that my my boss explicitly, Kevin explicitly said, do not stay, do not pull all-nighters on this. It's sort of a weird rule, but sort of just like running through and trying to get it into prod. That's how I empathize is because I've actually lived it. And I could see if this is just an internal web application, And I could see if you're dealing with a much larger dev team and $3 million are riding on this product launching on this date, the marketing team had already set a deadline. All of that, all of that, I can easily imagine how it scales up for a dev in a different— in the enterprise.

**32:14 Chris Romeo:** environment. Yeah. And there's an example, since we're talking about SaaS, I've used this example 100 times, but it does illustrate the importance of developer empathy. So, what do we do when we get a SaaS tool as security people? We take it, we add it to the pipeline, and what do we do with the policy? We crank that thing up. Oh, it has 127 checkers? Guess what we're turning on? Because we paid money for these 127 checkers, so turn them all on. And then what do we do? We send the developer their first dump of 10,000 10,472 issues that are blocking their ability to, you know, push a piece of code to production. So, what do they do? They throw their hands up in the air and go, how could I possibly deal with 10,472 issues? It's not possible, right? And so, as security people, when we sit on the other side of the table and we start to realize, hey, what are we actually asking people to do? That's developer empathy. That's saying, I'm not going to enable this tool with every— all 127 checkers. I'm going to turn on the one that is the biggest pain for us as an organization.

**33:13** Right.

**33:13 Chris Romeo:** SQL injection or cross-site scripting or whatever it is, I'm going to run that tool for 2 or 3 months with one checker so that the one that I know has a very high positive rate of what it's finding, like it's not, it's not sending false positives down the channel to our developers so that those developers over a period of time go, hey, that tool is actually helpful. It's finding things. And when I go look in my code, that problem is actually there. I can fix it, right? And then they can, they can gain some assurance in that, in that SaaS tool and say, this is something that, you know, I can get behind. And then the next time you bring another tool to the table, They're like, oh, the security team, they're thinking about us when they do this. They're not just saying, here's tools that are going to help me in my mission as security. They're saying, how am I going to help developers work better and write more secure code? And so, for me, that's developer empathy.

**34:01** Yeah.

**34:03 Ochaun Marshall:** And also fitting that into the structure of make that process as natural as possible. So, don't have it be, all right, you've run the tool. Now, even if it's for SQLi, these hit spots, don't have that be like the number one priority. Drop what you're doing, fix this issue now. Actually have that, these are bugs that you as a security practitioner or even the security champion that you've already embedded into the team has already brought up. Have this in the backlog.

**34:38** Yeah.

**34:39 Ochaun Marshall:** budget the time and have resources and think— have resources, personnel budgeted for tackling that bug because that's what it is. And then on that same— on the release cycle, all right, let's get this patched, let's get this fixed. Have that— have empathy is actually much— if it feels natural and fluid, that is what's going to That's how you know you've got a lot of developer empathy there. And it also helps push code faster. Oh, and it is also more productive.

**35:14 Chris Romeo:** Yeah, that's very helpful. I like that. I like that conclusion, kind of bringing that together. So, Oshan, once again, thank you for being with us here on the Application Security Podcast, sharing your knowledge about SAST and IaC and developer empathy and pen testing, something that I'm always curious to learn more about what it looks like in the real world and how it how AppSec and pen testing kind of bump up against each other. So, we're super grateful that you could be here to share with us again, and we look forward to your next visit to the Application Security Podcast. I'm not sure what we're going to talk about yet, but there will be something to talk about because you have so many awesome ideas and awesome stories and things to share. So, we look forward to catching up with you again on a future episode.

**35:56 Ochaun Marshall:** Look forward to it.

**35:58 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, with application security, there are many paths, but only one destination.

---

Source: https://appsecpodcast.com/ochaun-marshall-iac-and-sast/