---
title: "Dustin Lehr -- Advocating and being on the side of developers"
url: https://appsecpodcast.com/dustin-lehr-advocating-and-being-on-the-side-of-developers/
date: 2021-05-07
duration_seconds: 2194
guests: ["Dustin Lehr"]
topics: ["Building an AppSec Program", "Security Testing"]
audio: https://www.buzzsprout.com/1730684/episodes/8478968-dustin-lehr-advocating-and-being-on-the-side-of-developers.mp3
video: https://www.youtube.com/watch?v=VSUNXJT0cYc
transcript: true
---

# Dustin Lehr -- Advocating and being on the side of developers

*May 7, 2021 · 37 min*

with [Dustin Lehr](https://appsecpodcast.com/guests/dustin-lehr/)

on [Building an AppSec Program](https://appsecpodcast.com/topics/appsec-programs/), [Security Testing](https://appsecpodcast.com/topics/security-testing/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8478968-dustin-lehr-advocating-and-being-on-the-side-of-developers.mp3) · [Video](https://www.youtube.com/watch?v=VSUNXJT0cYc)

## Show notes

Before taking the plunge into information security leadership, Dustin Lehr spent over a decade as a software engineer and architect in a variety of industries, including retail, DoD, and even video games. This diverse background has helped him forge close partnerships with development teams, engineering leaders, and software security advocates while pursuing the organizational culture shift of building good security habits into daily work. Dustin joins us to talk about the challenges developers face with security and so much more. We hope you enjoy this conversation with... This diverse background helped him forge close partnerships with development teams, engineering leaders, and software security advocates while pursuing the organizational culture shift of building good security habits into daily work.

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

About Security Journey  
Before taking the plunge into information security leadership, Dustin Lehr spent over a decade as a software engineer and architect in a variety of industries, including retail, DoD, and even video games.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Dustin Lehr:  
→ [OWASP](https://owasp.org/)  
→ [Alyssa Miller](https://twitter.com/AlyssaM_InfoSec)

Mentioned in this episode:  
→ [OWASP](https://owasp.org/)  
→ [Alyssa Miller](https://twitter.com/AlyssaM_InfoSec)  
→ [Aaron Rinehart (opensource.com)](https://opensource.com/users/aaronrinehart)

Chapters:  
00:00 Meet Dustin Lehr: Advocating and being on the side of developers  
01:49 Yeah, and specifically Engaging the mind of the developer. I just  
04:03 Architect, what— I'm curious now, what from an architecture perspective, like  
06:54 Many questions come out of just what you said there. When  
09:13 Actually, I want to make a statement. I can definitely identify  
12:59 Some more about developers, but I want to ask a follow-up  
14:55 Okay. So I'm going to offer kind of another opinion about  
18:16 Totally agree that we don't want to put up any barriers  
20:50 Because nobody knows. I mean, I've been in the security business  
24:37 Yeah. I mean, imagine a day where we worked ourselves out  
27:04 Yeah, I was doing an interview for the episode right before  
31:05 A couple of things that I can think of that I've  
34:19 I plead the Fifth, right, to not incriminate myself in a

## Transcript

*6,288 words · assemblyai*

**0:00 Chris Romeo:** Before taking the plunge into information security leadership, Dustin Lehr spent over a decade as a software engineer and architect in a variety of industries, including retail, DoD, and even video games. This diverse background helped him forge close partnerships with development teams, engineering leaders, and software security advocates while pursuing the organizational culture shift of building good security habits into daily work. Dustin joins us to talk about the challenges developers face with security and so much more. We hope you enjoy this conversation with Dustin Lehr. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I am joined by Robert Hurlbut. Hey Robert, how's it going today?

**1:39 Robert Hurlbut:** Hey Chris, good. Yeah, it's Robert Hurlbut, Threat Modeling Architect, and really glad to be here again to talk about one of our favorite topics, application security.

**1:48 Chris Romeo:** Yeah, and specifically Engaging the mind of the developer. I just came up with that on the fly, but that's a lot about what we want to talk about. But we're joined today by Dustin Lair. And Dustin, we always throw this question immediately to our guests. We don't even give them time to take a breath, as our audience already knows, and they're sitting on the edges of their seat. What is your security origin story, or how did you get into this crazy world of application security?

**2:15 Dustin Lehr:** Absolutely. So first of all, thank you very much for having me today. My security origin story, I would say, would start with me studying computer science in school, right? So right out of school, becoming a developer, working for over a decade as a developer, and then getting into sort of more of the architecture side, right? Designing systems, architecting systems, et cetera. You know, when you start to get into the architecture side of the house, you're thinking about things beyond just what a developer would think about, right? Developers typically typically think about, let's make this work, right? Let's get this functionality out the door. Let's make the business happy. Let's do the right thing. When you're an architect, you think about other things. You think about how to make this system maintainable. You think about quality, right? You start to think about security. So for me, that's how I naturally just got into it even more. I always kind of had a security mindset when I was a developer, But when I became an architect, it was like, hey, this is one of those extra things that I can help with, help the developers with. So from there, it was just kind of a natural flow into becoming a security architect, which I was for a total of about 4 months before I got the opportunity to lead an AppSec team. And that was essentially standing up an AppSec team from scratch, right? So there was a little bit of a capability, but mainly it was, hey, You know, we, we have to roll this out at scale. How are we going to do that? Um, so that's how I got into it. I've been doing that for about 3 years now.

**4:02 Robert Hurlbut:** Very cool.

**4:02 Dustin Lehr:** Wow.

**4:03 Chris Romeo:** So architect, what— I'm curious now, what from an architecture perspective, like making that transition from developer to architect, first of all, why did you make that transition? Or what drew you to say, hey, I don't— I'm not going to stop coding and I'm going to start drawing pictures of systems?

**4:21 Dustin Lehr:** So first of all, never stopped coding. I actually still code today. Okay. Even though I lead a team, I still code. And that's because I love it, right? I love being— I like, I really love making things work at the end of the day, right? So, but to go back to your question, why get into the architecture side? I think for me, it's always been about quality, right? helping not only the dev teams, but the developers themselves build quality systems, right? So, I was always thinking a little bit bigger. Every developer kind of has their piece of the pie. They're being asked to implement something specific, but I was always thinking a little bit bigger, like, what is this? How is this going to impact the whole system? How is this going to impact other components of the system and of other systems, et cetera? Started getting into reading about microservices and containers and all these cool things that really helped me understand the bigger picture. And that's why I just kind of naturally got into it. Plus, I like to help people, to be honest. Part of the draw to architecture for me was, you know, here's a lot of developers, how can I help them be better, right? How can I mentor them? How can I sort of improve, you know, the way that they code? And then I also got into more of the, I would say, project management side as well. Like, I've always been, been one to try to figure out, is there a way to improve our processes as well, right? So, things like tech debt. One of the big things that I did as an architect was, frankly, trying to document and capture the tech debt that we had for particular systems and start to pick those off, even so far as working with the business to try to allocate some time every single sprint to actually work on the technical debt. And that's something I've always been passionate about as well is, hey, we have to do more than just focus on business features, right? If we want our systems to truly be robust, we have to be focusing on the technical-only work, right? patching, upgrades, re-architecting, right? All of that stuff. So anyway, so that was a long answer, but that's the stuff that I really care about as an architect as well.

**6:54 Chris Romeo:** So many questions come out of just what you said there. When I hear quality, it's one of those old— it seems like it was like a decade ago where everybody was like, security is quality and you can't have security without quality. You can't have quality without security. And it seems like it's kind of It's gone by the wayside. I still firmly believe that it's true, but I want to ask about tech debt. I just wanted to make a general statement about quality. Talk about tech debt. When you think about tech debt in the context of security, does an AppSec team have tech debt themselves? Are they contributing to the tech debt of another team? Are they watching the tech debt of another team because they don't have any of it, or how does tech debt influence the AppSec team?

**7:42 Dustin Lehr:** That's such a great question. You know, I think it depends on your AppSec team, but in my experience, what we've done is we have brought people on who are developers themselves. So the AppSec team, in order to better relate to our customers, right, the developers of the company, we felt it was necessary to have those development skills.

**8:08 Chris Romeo:** Right?

**8:09 Dustin Lehr:** You know, to have the fruitful conversations, right? So developers develop. So there's no way that we can get away as an AppSec team without developing something. So we have built certain systems that have helped us, you know, better support our customers. And the second you start building a system, the second you— we all know this, right?

**8:32 Robert Hurlbut:** Yeah.

**8:33 Dustin Lehr:** you create tech debt almost immediately because you're like, hey, this works, but I don't like this. I'm going to come back and fix it, I swear. Right? And you put a to-do or something. So, you know, do AppSec teams typically have tech debt? I think if they're active in trying to automate things, if they're being creative with the way that they're designing solutions for the rest of the organization, absolutely, they're going to have tech debt. just like everybody else.

**9:00 Chris Romeo:** I'm going to let Robert ask a question now because I'm known for asking many, many questions almost nonstop. But Robert, I'll let you have a turn to ask Dustin a question.

**9:12 Robert Hurlbut:** Well, actually, I want to make a statement. I can definitely identify and resonate with the architect as a developer. I remember that switch for myself, and it was sort of back then we would say the difference between a a hands-on architect versus the ivory tower architect. But anyway, that's just an interesting aside. And then you may have already implied this, but just by some of the things that you're working on and things that you're doing and still developing and so forth, but what makes you such an advocate for developers with your background and everything?

**9:51 Dustin Lehr:** Yeah, great question. So I think it goes back to, I am one still, right?

**9:58 Robert Hurlbut:** Mm-hmm.

**9:59 Dustin Lehr:** And I've been one for quite a while. I think that's very valuable in terms of an AppSec function at a company is to be able to relate to the developers. So there's one particular story though that sort of stands out in my mind. why do I care so much? Why do I care so much about developers and trying to get it right for the developers? I think it's mainly because they have a lot of things that they take care of. They're responsible for a lot of things, right? And I'm not sure everybody recognizes that. And the story that I have is I was working for a particular company. I'm not going to name the company, but very highly competitive environment in terms of, you know, the stuff we were working on was appealing to a lot of developers. So the problem was that the company knew that, right? So they weren't necessarily treating the developers well because they always knew that, look, if this guy quits, we could just go get the next one in line, right? So So basically, the developers were working, you know, very, very hard, lots of hours, lots of pressure, you know, to deliver. And eventually, you just saw them burning out. You know, they would only last for a certain amount of time, and then they would leave. And that always struck me as just the wrong approach, because we all know, as developers, it takes a while to understand the systems that you're supporting. And especially in this case, they had a complicated system.

**11:39 Chris Romeo:** Yeah.

**11:42 Dustin Lehr:** Right? So, it took a while, it took months, many months to understand, you know, all of the ins and outs and all the stuff that was going on. And, you know, that was knowledge and skills for their systems that were just walking out the door because they were burning out. And I just remember thinking, that's not the way to do it. Like, you got to keep the people who have invested all of that time around. Otherwise, the next guy that walks in the door, he's going to have to learn everything all over again, right? So, I always just thought, look, developers are important, and especially in this case, it was a very software-centric business. So, it just struck me like, look, if your business depends on your software and you're not treating the people who are maintaining your software very well, you know, that just doesn't seem like the right approach, right? So ever since then, I've always been very developer-friendly, you know, advocate for developers, because I think we need to very much respect what they do. And the fact that most businesses these days, you know, depend on software and therefore depend on their developers. Right.

**12:58 Chris Romeo:** And I want to talk some more about developers, but I want to ask a follow-up question about kind of, as I'm pondering your history and how you got to security and the emphasis that you put on development. It's been a bit of a— I don't want to say a controversy, that seems so strong, but this idea that some people have come out and said, hey, you know what? If you're going to be in security, if you're going to be in AppSec, software security, something like that, you have to code. You must code. It's mandatory. I'm curious what your take is on that. And also what you would say, because I think I know, I think I know how you're going to land. I'm going to listen to how you're going to land first before I ask my next question, just to keep myself out of trouble.

**13:41 Dustin Lehr:** Is it completely necessary for AppSec people to know how to code?

**13:45 Robert Hurlbut:** Yes.

**13:46 Dustin Lehr:** I would say surprisingly, maybe no. I think there are other skills that you could go into an AppSec program with, you know, as an AppSec person that are also valuable. One of the big ones in my mind is application pen testing, right? And the reason for that, you know, let's say you haven't coded anything, you know, besides maybe a couple of bash scripts or something that you've had to whip out, you haven't really coded an application, but you know how to attack it. You know how to be creative with finding loopholes, or maybe you even come from a general testing background. So you're used to poking at applications. I would say that's also a perfect background, right? Because now you're able to help developers understand that other side of how to look at it, right? There's the engineering side, I'm going to make this work. Then there's the, how do I break this mentality? And I think that's also very valuable for AppSec people to have.

**14:54 Chris Romeo:** Okay. So I'm going to offer kind of another opinion about the application pen test that you just described. I mean, my conclusion— so I've met a lot of those people. I am not one of those people, just cards on the table, right? Like, I don't have the whatever, the patience to tear things apart in really tiny little pieces that they do. And I respect all of their abilities, but the best application pen testers I've ever met are good because they know how to code. Like, they understand what's happening behind the scenes in the application. It's not just a front that they're just looking at and seeing, hey, I know there's a web interface here, I know how— they know what languages are running behind the scenes, and that helps them to inform them to know what might I find on the other side if I was able to get past that. So I'm, I'm, I mean, I'm somebody who's not like, I'm not I'm not going to take a hard and fast stance and say if, you know, some people are out there going around saying, you know, like, you know, you have to— if you're in security, you have to code. I think it's valuable. I think it's being able to walk with a developer through a code review. Like, there's nothing— and you can, you can probably tell, you probably have stories about this, Dustin, too, and even Robert too, from your experience— where you sit there and do a code review with the developer in a language that you know enough about even just to be dangerous, and it's their main language, and you're like, well, hey, what about this? You know, that line right there, what's that? What does that function doing right there? I've seen that command before used, it's been kind of dangerous. That developer's face is gonna light up, 'cause it's not just somebody who's like, oh, somebody who doesn't know what I do. This is someone who knows at least enough about the language, they care enough about me to have learned the language they're trying to influence that I'm doing. So, any additional thoughts kind of from that perspective? I wanna make sure I give you— this isn't a debate, by the way, it's just— this is a friendly conversation. Yeah.

**16:45 Dustin Lehr:** If it was a debate, I wouldn't mind anyway. So I like the idea of sort of challenging our ideas here. So, you know, I agree with you, you know, in terms of the value of having those development skills when you have those kinds of conversations. What I was saying before is not that, you know, the pen testing background is ideal. I think ideally you would have hardcore development experience because Exactly like you said, you can have those, you know, very detailed conversations with developers, right? You can point to, point to a line and they get excited because they're like, cool, I'm talking to someone who knows this stuff as well, right?

**17:26 Robert Hurlbut:** Yeah.

**17:26 Dustin Lehr:** But one thing I want to clarify is that coming into AppSec, I wouldn't necessarily put a barrier up and say, if you don't have coding skills, you can't be part of the team. Because we find a lot of value in, you know, really a lot of sort of diverse skills on our AppSec team to begin with. So someone who has more pen testing skills, great. You know, you can help teach the rest of the team who may be more fluent with, with, you know, coding, you know, and vice versa.

**17:58 Chris Romeo:** Yeah, I think—

**18:00 Dustin Lehr:** yeah, totally. After a few years— sorry, after a few years, ideally we'd want to have everybody have some level of pen testing skills and coding skills as well, because I think that's the kind of maximum benefit that we can provide the org.

**18:16 Chris Romeo:** Totally agree that we don't want to put up any barriers. Like, listen, as an industry, we put up enough barriers against everything to prevent people from doing— like, so yeah, so I'm with you wholeheartedly there. Like, putting up a barrier that say you have to know how to code to join an AppSec team doesn't seem fair. Now, if I'm hiring somebody who's new to AppSec that's coming in, part of their 1-year plan is going to be, Hey, let's get some experience with coding. And listen, I mean, I've been in AppSec for 10+ years at this point. I am not a superstar coder. Like, I can code. I'm dangerous behind the keyboard. That's what I am. I make stuff work, but then some of my senior development friends will look at it and go, oh, why didn't you just do this one? Why'd you do 12 lines? Why don't you just do this one line? I'm like, I didn't know that one line existed. But my 12 lines, you know, one of my favorite pieces of code that I wrote, I wrote a snippet of code that I would be embarrassed to show to parse JSON. It was a set of 3 loops that had loops inside of them that was parsing JSON. So my stuff works. But all that to say, like, I don't wanna see us put any more barriers up. Like, we need more people in our industry and let's break down barriers and say, hey, let's bring people to the table, get them on the team, and then give them a path to that one year. I love the idea of my AppSec team having knowledge in how to code, knowledge, some knowledge in how to break stuff, but they don't have to have it on day one.

**19:39 Dustin Lehr:** Exactly. Completely agree. And there was something that was said earlier about the ivory tower mentality.

**19:45 Robert Hurlbut:** Right.

**19:46 Dustin Lehr:** I think having people on your team who are learning is actually a good thing when it comes to showing that we're like human almost. And, you know, when we partner with others, I'd like to go into that a little bit as well. Like, you know, it's important to create a partnership, right, between your AppSec team and your development teams. Part of how to do that is creating, you know, kind of a mutual trust going both ways. Having an ivory tower mentality like, hey, we know everything, you should just kind of follow everything that we're saying, it doesn't work as well as, hey, you know, we're here, we have a certain set of skills, we know you have a certain set of skills, let's work together, you know, to find a solution. And that's kind of where, again, I wouldn't expect, you know, AppSec people to come in the door knowing absolutely everything about AppSec. You know, there's learning opportunities, for them, there's learning opportunities for the developers. Let's work together and get there together.

**20:44 Chris Romeo:** Let's be honest too. If somebody tells me they know everything about AppSec, I'm just not going to talk to them anymore.

**20:49 Dustin Lehr:** Exactly.

**20:50 Chris Romeo:** Because nobody knows. I mean, I've been in the security business for almost 25 years, and all that I learn every year is how much I don't know about all of the things that make up here. But I'm a lifelong learner. I'm reading, I'm learning about things, and people are challenging me through this podcast where we had an episode with— Robert will remember— with Alyssa Miller a couple couple of months or so ago talking about DevOps, and we got on this discussion of people, process, tools, and Alyssa said, I always add governance to that. And I was like, what? Governance? Like, who? Like, I, I don't like that word.

**21:24 Dustin Lehr:** They've always been against me.

**21:26 Chris Romeo:** And she's— and then she started explaining it, and I'm like, I got to the end and I was like, yeah, people, process, tools, and governance. And so that's, that's, that's part of like, none of us are experts. We're all learning every day. Let's transition into some of these challenges. So I'm curious, and I'm going to go to both of you with this question because I know Robert's got a lot of development experience and a lot of security experience as well, just like you do, Dustin. So I'm curious on both of your takes from this perspective, but what are the challenges that developers face with security? Let's start with Dustin, and then Robert, we'll come to you for an answer. I'm going to turn the microphone around on you here and actually ask a question.

**22:03 Dustin Lehr:** So developers are very busy. I think that's where I would want to focus and kind of index on a little bit here. I think the biggest challenges come from the fact that they have business features to get out the door, right? There's a lot of pressure on them to do that consistently. Not only that, we talked about some of the other stuff. tech debt, right? They have to think about maintaining their systems, patching, maintainability of the code, you know, performance of their code. There's all these things that they're constantly thinking about. So, you know, for us security folks to come in and say, here's one more thing, you know, you should be thinking about security. To them, I mean, that could be the straw that broke the camel's back, right? They're like, I just, I can't do that. Right. I have a million other things to think about. This cannot be part of that. So I think the biggest challenges really lie in that. And that's where I think it's very important for us as security people to work very hard for our customers when it comes to providing them solutions. The solution cannot be, hey, everybody, we need you to work harder to, you know, to take security into account on top of everything else. I think our jobs, because frankly, the ultimate goal here, right, is security is everybody's responsibility. The ultimate goal is really to have the developers, architects, everybody thinking security as they're doing their day jobs every single day, every time they hit the keyboard, right? So where does that leave a security team? Like, if we have the— if we have everybody doing that, what is it exactly that the security team does then? Right. And I think what's important to note here is that the security team is still very valuable in that situation because they are providing the tools, the guidance, the standards, you know, all of that sort of direction and capabilities for the organization to, to do security, you know, to take security into account easier. Right.

**24:16 Chris Romeo:** Yeah.

**24:17 Dustin Lehr:** So, so that's what I would say. So, so I would say, yeah, Biggest challenge is time, and it's up to security to really be putting ourselves in the shoes of the developers and really any of our customers to try to design solutions that work for them and that are going to not be huge time consumers for them.

**24:37 Chris Romeo:** Yeah. I mean, imagine a day where we worked ourselves out of a job. Imagine how great the world— I mean, we'd be so happy to put our data in a database somewhere. Like, ah, it's going to be fine. We've got this whole AppSec thing figured out. I think we're all going to be gainfully employed as long as we want to. So, I'm not planning my retirement anytime soon based on kind of what I see, but that certainly can be a goal of ours. We should always be thinking about how am I putting myself out of this job, whether that is by building tools and processes and things to empower, just like Dustin, you're saying, empower the developers, empower the architects, empower the testers, whoever, whoever's on your team, you're empowering them to do security and to embrace that themselves. But I still don't think we're going to work ourselves out of a job, and I don't think either of you are concerned about that as well. Robert, when you're thinking about challenges from a developer perspective with security, what are some of the things that come to your mind?

**25:34 Robert Hurlbut:** Well, yeah, certainly time crunches and things like that, as Dustin mentioned. But another thing I was thinking about is I remember as a developer when I would build or try to build code related to use cases, and in thinking about security as well, is what are the failures? And sometimes, certainly those who are new to development, or even after a few years, they may think of the positive cases, but they don't necessarily think of the negative cases. And so sometimes they need help with that. And, you know, help me understand what are the negative cases so I can build the right test cases in place, and that can relate to security as well. So, it's one thing to say, here's a bunch of standards that you need to build into the code. Okay, but what is in there that helps me understand the failure modes that are also related to security? I log in and it fails, what do I do? And so on and so on. So, those kinds of things in terms of testing, in terms of writing, the term we keep throwing around these days, resilient code.

**26:45 Chris Romeo:** Yeah.

**26:46 Robert Hurlbut:** But building in those kinds of things sometimes can be a challenge for developers if they're thinking of the happy path and not always the sad path, or trying to figure out what are the sad paths, if you will, throughout the code that might relate to security.

**27:03 Chris Romeo:** Yeah, I was doing an interview for the episode right before this one with Aaron Reinhardt, and he made a comment about resilient code and said it's really not resilient code, it's resilience engineering. It's not the code, it's the engineering process, and that just caught me when I was listening to that. Oh yeah, absolutely. All right, so now I'm going to flip the question, and I'm going to say, okay, you got a chance to share the challenge with the audience. We can't just be a podcast that's known for our problems. We have to be a podcast that's also known for our solutions. So Dustin, to kind of your— when you're thinking about all the different priorities and things that face security or face developers as they're trying to measure security and tech debt and performance and quality and all of the other things that get dropped on top of them. What's the solution from your perspective? How do you help them to get past that challenge?

**27:56 Dustin Lehr:** Yeah, great question. I think automation is key, but I also think culture shift, sort of mindset shift is also part of the solution, right? So let's think about it in terms of the SDLC for a minute, right? I think one of the best places to start, frankly, and if you're going to start an AppSec program, I think this is a perfect place to start. Start on the right side. Start by measuring yourself. Start by running scans, right? Start by automating the scans that you run, whether it's SAST or IAST, et cetera. Really just to capture what are we looking at? What's the landscape? What is the maturity of the organization? And then you sort of, what you do when you do that as well is you have a measuring stick, right? This is where we started. And then you can shift left, right? You can start to, I have this saying called start right or shift left means to start right. Right? We don't say start left. We say shift left, which means start right in my head. And that's kind of what I'm explaining right now. So, you know, if you start on the right side, you start measuring yourself, and then you put things into the SDLC, the process to, you know, to move left, right, over time. New habits, you know, new things to eventually prevent those issues that you know, that you, that you found. And as you do that, you can measure success because you have those metrics in place, right? So you do, you do another annual pen test. You know, if the issues are less than you saw last year, you know, you can, you can say part of that is likely because of some of these other habits that we put into place. So let's talk about those as well. And I could go on about this for hours, just so you know.

**29:52 Chris Romeo:** We all could.

**29:52 Dustin Lehr:** But we all could.

**29:54 Chris Romeo:** And I love the—

**29:56 Dustin Lehr:** that's a Sorry.

**29:57 Chris Romeo:** That's a good— that's a good— I, I— that's why I love doing this podcast, because I've never thought about it like that. I've never thought about it as metrics first, and I don't think I ever would have thought metrics first. But it's brilliant, because if you start with metrics right off the bat, even if it's some simple scans and, and just collecting that data, now we can say, hey, 2 quarters out And now that we're looking back, look where we are now. We started here, we were at 1%. Now we're at 22% of something. We've got some progress. So yeah, that's really making me think, and that's why we do this. But I want to get Robert's answer to his challenge. And we were going to talk about AppSec programs too, but we'll have to save that for another episode, which we will do relatively soon to dive into that whole issue, because I think we've got a whole other episode just to talk about AppSec programs and building those, something that all 3 of us are passionate about. But Robert, I wanted to get your take on your solution on what your example was.

**31:04 Robert Hurlbut:** Well, a couple of things that I can think of that I've seen work and have done myself that have worked is one, when you're trying to figure out those failure cases, sometimes the reason why we think of the happy path is because it all works on my machine. What Dustin mentioned about the automation can really help is to test with different automated tests of those failure cases and then learn from them. If I'm not sure what are the failure cases, if I already have some good tools that build in those kinds of failure cases, and that's where a security person can establish some of those or other business folks who can think about what those are and build those in to test. And then developers learn what those are. They see it not running on their machine because, of course, it runs perfectly. But they see it in another environment with automated testing, with automated verifications that, hey, in other situations, this fails. Oh, why did it fail? Oh, I see. I didn't even think about that. That didn't even occur to me that that might be a potential issue. related to security or otherwise. And so now they start to build those into their own tests. So we catch those much earlier if they happen as they run unit tests and so forth. And so those are some of my thoughts and things I've seen that work well in terms of— again, it's a partnership, right? I can't expect to know everything as a developer, but there are others who do know a few more things about how the system is working or should work. And together, working together with tools that, that help me do what I'm doing and help them understand what I'm doing as a developer, I think together we can build a better, more secure product. Yeah.

**33:00 Dustin Lehr:** And that reminds me of something. So one of the best starting places that I've found to sort of start people down the rabbit hole of learning about AppSec frankly, is to run a scan on their application, their piece of code. Because, you know, everyone thinks their baby's beautiful, right? But when you say, here's your scan results, yeah, your baby's not as beautiful as you thought. It's an eye-opening experience for them. They're like, oh, like you said, Robert, I've never thought of that.

**33:33 Chris Romeo:** Right.

**33:33 Dustin Lehr:** I never thought of it that way. And you can sort of teach them from there, right? You can say, hey, you know, here's what— here's the world of cross-site scripting and here's OWASP. And there you go. They're off to the races, you know, learning about AppSec. So, yeah.

**33:49 Robert Hurlbut:** And there's something about what you just said. There's something about reading about it, watching a demo of it, or actually seeing your own code have it built in something you thought worked great, but Oh, I have a cross-site scripting vulnerability I didn't even think about in my own code. Oh, geez. Oh, but now I know how it works. Now I understand how to protect against it.

**34:13 Chris Romeo:** So you guys have vulnerabilities in your code?

**34:15 Dustin Lehr:** Hmm, none.

**34:19 Chris Romeo:** I plead the Fifth, right, to not incriminate myself in a court of law, Your Honor. Well, Dustin, we got to, uh, kind of land the plane here for the audience. And so we like to ask as our final question, what is the key takeaway or perhaps a call to action that you would leave with our audience, something you want them to do? What would it be?

**34:41 Dustin Lehr:** Yeah, so I, you know, I think we touched on this a lot today, but I do want to kind of drive it home. You know, as security people, especially AppSec people, we need to work very hard to make, you know, to be an advocate for our developers, right? So do whatever you can to evaluate, find the right tools, find the tools that are going to save them time, whatever it is to make it easier for them, we need to tackle because frankly, you know, that's why we're there, right? So I would say that, let's, you know, call to action would be work hard, make sure that you are being an advocate for your developers and you're evaluating tools, you know, that are going to work best for them. Awesome.

**35:30 Chris Romeo:** Dustin, thanks for taking the time to share with our audience your passion for helping developers learn more about security, get more into security. It was awesome to hear your, your path, how you got into the world of security and how that's influenced your thinking in everything that you're doing. And we'll definitely have to do another episode very soon to talk about AppSec programs. something that was on the agenda, but we didn't even get to because we were having so much fun talking about what we talked about. So, Dustin, once again, thanks, and I look forward to talking again soon.

**35:58 Dustin Lehr:** Thanks a lot, Chris and Robert. Appreciate it.

**36:02 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/dustin-lehr-advocating-and-being-on-the-side-of-developers/