---
title: "David Kosorok — The Three Pillars of an AppSec Program: Prevent, Detect, and React"
url: https://appsecpodcast.com/david-kosorok-the-three-pillars-of-an-appsec-program-prevent-detect-and-react/
date: 2019-12-16
duration_seconds: 1830
guests: ["David Kosorok"]
topics: ["Building an AppSec Program", "Security Testing", "Vulnerabilities and Exploits", "Security Culture"]
audio: https://www.buzzsprout.com/1730684/episodes/8122621-david-kosorok-the-three-pillars-of-an-appsec-program-prevent-detect-and-react.mp3
transcript: true
---

# David Kosorok — The Three Pillars of an AppSec Program: Prevent, Detect, and React

*December 16, 2019 · 31 min*

with [David Kosorok](https://appsecpodcast.com/guests/david-kosorok/)

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

[Audio](https://www.buzzsprout.com/1730684/episodes/8122621-david-kosorok-the-three-pillars-of-an-appsec-program-prevent-detect-and-react.mp3)

## Show notes

Where should a small application security team begin when it cannot do everything? David Kosorok joins Chris and Robert with a practical framework: prevent, detect, and react. Drawing on his background in software testing, he maps the pillars to requirements and design, coding and testing, and deployment and feedback. These are parallel areas to develop, not three stages to finish in order. David explains how relationships with security champions make prevention possible, how testing expertise strengthens detection, and why external findings can make risk tangible for developers. The conversation also explores bug bounties, feedback loops, and meaningful recognition. His emphasis is on building a supportive security culture through partnerships and small, useful controls rather than overwhelming teams with a complete program at once.

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 David Kosorok:  
→ [LinkedIn](https://www.linkedin.com/in/kosorok/)

Mentioned in this episode:  
→ [OWASP Triangle](https://nest.owasp.org/chapters/triangle-nc)  
→ [SSL Labs Server Test](https://www.ssllabs.com/ssltest/)  
→ [Hacker101](https://www.hacker101.com/)  
→ [HackerOne](https://www.hackerone.com/)  
→ [Bugcrowd](https://www.bugcrowd.com/)

Chapters:  
00:00 Introduction  
02:33 From software testing to application security  
03:56 What testers bring to security  
07:07 Quality and security share a purpose  
08:39 Prevent, detect, and react  
09:56 Prevention through requirements and design  
12:46 Partnerships and security champions  
16:24 Detection during coding and testing  
18:59 Working with quality engineers  
20:36 Reacting to risk in deployed applications  
23:49 Making external findings useful feedback  
28:42 Recognition that encourages participation

## Transcript

*5,348 words · assemblyai*

**0:00 Chris Romeo:** David Kasserak is a code security expert, software tester, father of 9, and a self-described major nerd. David is the Director of AppSec at AlignTech and a fellow member of the Raleigh-Durham tech community. David joins us to speak about the 3 pillars of building an AppSec program: prevent, detect, and react. When we think program, we've never heard anyone relate a program this way and thought you needed to hear about a different approach to program building.

**0:27 Robert Hurlbut:** We hope you enjoy this conversation with David Kasserak.

**0:29 Chris Romeo:** I want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun.

**0:51 Robert Hurlbut:** We don't do lectures.

**0:52 Chris Romeo:** Instead, we let the experts talk about what's important. The modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

**1:22 Robert Hurlbut:** The Application Security Podcast. Here we go. Hey folks, welcome to this episode of the Application Security Podcast.

**1:47 Chris Romeo:** This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I'm joined today by Robert.

**1:54 Robert Hurlbut:** Hey Robert, how's it going?

**1:55 Chris Romeo:** Good, Chris.

**1:57 Robert Hurlbut:** And this is Robert Hurlbut, Threat Modeling Architect.

**1:59 David Kosorok:** Good to be here.

**2:00 Robert Hurlbut:** Our guest today is someone that moved to the Raleigh-Durham area where I happen to be based. And he reached out to me through the work that I was doing with the local OWASP Triangle chapter here in Raleigh and Durham, North Carolina.

**2:17 Chris Romeo:** And so I had a chance to invite him to come and speak to the chapter about his experiences.

**2:22 Robert Hurlbut:** And that's what brought us to this interview today.

**2:25 Chris Romeo:** And so we're joined today by David Kosarach.

**2:28 Robert Hurlbut:** And David, we always ask the same first question of everybody who joins us here on the podcast.

**2:33 Chris Romeo:** And that is, what is your security origin story?

**2:36 Robert Hurlbut:** How did you get into this?

**2:37 Chris Romeo:** Yeah.

**2:41 David Kosorok:** Great question. I agree, everyone in security has that origin story. Mine, I started 20-plus years ago in the software testing industry. At one point, I was very excited. We had just released a piece of software that was— I thought it was fantastic, really high quality. Within 12 hours, Some benevolent individual from MIT called us and said, hey, I just found a SQL injection on your application. It gives me— I was able to get shell-in-the-box. I just thought you might want to know. That changed my world. I said, what are we missing? We went through all of our test cases. We went through use cases. We stressed it out. We load tested. What's going on? We realized that we had missed some important components. We were not doing static analysis. I actually quit my job as the test manager and created a new group for application and code security and started testing at that point because that was something I was very passionate about. I had always added security to whatever I was testing, but I decided I am going to focus my career 100% on security. That's kind of where that flipped my whole career over 10 years ago.

**3:56 Robert Hurlbut:** So, 10 years ago is when you were in this role kind of as a tester then. Okay. And so, we haven't had a lot of people that have been on the podcast that have an origin story that brings them from the world of testing directly, meaning, you know, somebody who was doing testing from kind of the product perspective. And so, what do you think, what's kind of the unique perspective that somebody brings to security as a tester?

**4:22 David Kosorok:** Well, I think it brings the same mindset, what I call a destructive mindset, where you are able to look at something and instead of saying, how do I want to create something? You and I have talked about this before. How do you want to create something? You look at it and say, how do I want to take this apart and figure out how to break it so that our customers don't experience the same thing? My focus was very customer-focused. How do I make sure that the experience the customer has is pleasant, that it's good, that it has a good flow to it. And that's kind of where I brought that perspective. And I was an SDET for a number of years at Microsoft, and really we all focused on how do you get that customer experience to be better.

**5:03 Robert Hurlbut:** Yeah, and one of the things I experienced working with testers is at one of my past jobs, I had the opportunity to teach threat modeling across the engineering organization, which was many, many thousands of people. And so we started focusing in on the developers, but then quickly we realized that these testing folks had this kind of built-in mindset to say, how are we going to break this thing? And so, I really enjoyed teaching threat modeling to testers because you didn't have to teach them to want to break things. You just had to harness their knowledge. And it turns out, from my experience, testers have as much knowledge about the overall system, if not more, than kind of the classic developer because the tester is thinking about the system from a high level and then also at the low level. and everything in between, whereas a developer can sometimes get focused on just the portion that they're working on.

**5:55 David Kosorok:** That's right. That's been my experience as well. There's an additional component to that that I thought was kind of interesting that I found similar to almost every person that I've talked with in the cybersecurity industry, and that is you have that protective gene in you that says, I'm gonna protect the user. So, from a software quality or testing perspective, you want to protect the user from a bad user experience or poor quality or something that gives a negative impression. From a security perspective, you want to protect them from malicious intent. Those actually go hand in hand very well. I totally agree with you, Chris, on that. It's a great place. In fact, we often find that when we collaborate with engineers throughout the organization, our QA engineers are the ones that raise their hand and say, let us know how we can jump in and help. Let us know. We want to experiment. Or, when we come up with capture-the-flag games, CTF games, to kind of do some education through the Security Championship program, our QA engineers are typically the ones that will raise to the top very quickly early on in the game and say, hey, because they spend the time. They're curious. They want to know. They have that burning desire to learn.

**7:07 Robert Hurlbut:** Yeah, and you mentioned about quality, you know, coming at this problem from a quality perspective, whereas the tester is thinking about how do we protect the customer's experience, and then the security person is thinking about, hey, how do we protect from malicious intent?

**7:22 Chris Romeo:** I think that's a great way to think about it.

**7:24 Robert Hurlbut:** And the more I think about security and quality, the more I realize that these are, in fact, the same thing. They're serving the same purpose, and they have to be things that we're talking about in the same perspective. Because I come back to, hey, can you have a secure product that is a low level of quality? I don't know that you can, at least not in this day and age.

**7:46 David Kosorok:** Yeah, and in fact, there was a book written by or published by McAfee years ago that talked about how when you fix feature issues, functional issues, you will often not affect security, but when you fix security, you will always affect and beef up the quality of features, which I thought was kind of interesting. I kind of expected them both to balance, but reality is when you fix security issues, you typically also beef up the strength of the feature and harden the application, generally speaking, for the user, not just to protect them from malicious intent.

**8:19 Robert Hurlbut:** That was a great introductory conversation, and we almost could have gone off on a tangent there and talked about security and quality the whole rest of the episode. But, David, we did bring you here because you do have a lot of experience in building application security programs. That was actually the talk that I first heard you give. Here at the OWASP Triangle chapter.

**8:39 Chris Romeo:** And so I wanted to start this with kind of a high-level question for you about how do you break down an application security program and what are the categories that you use?

**8:49 Robert Hurlbut:** Because you had taken an approach that I hadn't seen anybody do before, and that's why I want to start here.

**8:53 David Kosorok:** Sure. I look at this at a larger view. I kind of stole this information from HP, and HP stole it from someone else 15 or 20 years ago, and this is using that the whole concept of prevent, detect, and react as major pillars of focus. Each of those also connects directly to the software development lifecycle. For example, prevent covers requirements and design. Detect covers coding and testing. React covers deployment and feedback. That's kind of, at a high level, where you want to focus an application security program. Each one of those also contains controls that you want to implement. in a predetermined order. You can determine— it just depends on how your company reacts to security. Are they pleasantly surprised and giving you budget money, or are they slightly resistive, or are they highly fearful? It just depends on how you want to approach, and this strategy allows you to mix and match depending on the security culture of the company.

**9:56 Robert Hurlbut:** Let's start with the first one because I'd love to get your perspective on each of these pillars and what are the things that go into it and what are the things that make make these pillars successful. So, if we start with prevent, where you mentioned requirements and design, give us a little more context about what you think of that exists in that pillar, as well as some of the controls that our listeners should be thinking about.

**10:19 David Kosorok:** Sure. In the prevention side, this is where typically before code is ever written. And so, prevent means, and that's also typically where it's least expensive to fix an issue. So, if there's a security vulnerability and you're, let's say you're Conducting threat modeling, you find it there, it's very inexpensive to fix it, whereas when you write code, you've already gone through time and effort and several programming hours to get to that point. There's also a component to prevent where you look at the overall security culture of the company. Some companies are raring to go, and so you can sometimes jump in with a high-powered tool and say, we're going to help you and help you focus on these security efforts. Other times you have to start a little softer and say, you know what, we're going to become your partner, which is what security needs to be nowadays anyway. But you start off in a way where you're more collaborative, you're explaining more basic principles of security, and you really use that to kind of invoke the blueberry muffin principle, which is the most important principle that you, in my opinion, that you can have in application security. That covers all 3 of these pillars where imagine that you love blueberry muffins. I think everyone I've ever met loves blueberry muffins unless they're allergic to blueberries, in which we don't let them in our house if that's the case. You want to bake these blueberry muffins and you have these fresh blueberries and you stir the dough and you bake the dough and it turns into these wonderful muffins and you pull them out and you realize, oh my goodness, I forgot to put the blueberries in. You take the blueberries and you smash them up. You smear them over the top, and you take a bite waiting for that delicious flavor to hit, and you realize, this is not working. It's a mess, and it tastes horrible. Whenever you try to smash the blueberries in, it just never works. You take the dough, and you gently fold the blueberries in, and you bake them all together. That way, the juices kind of flow in between, and you have this delicious blueberry muffin experience. That's where security must be to be effective. And so, the prevent, detect, react columns support that whole process of baking in security throughout the software development lifecycle.

**12:26 Robert Hurlbut:** That's a new illustration for me. I've been around this world for a number of years, and I've heard people describe it a number of different ways. And yeah, the blueberry muffin principle should be the name of your first book if you haven't written a book yet.

**12:44 David Kosorok:** I will consider that.

**12:45 Chris Romeo:** Thank you.

**12:46 Robert Hurlbut:** So when you're thinking— so you mentioned threat modeling, you mentioned culture. What's your take on requirements? How do you approach requirements?

**12:52 David Kosorok:** You first of all have to create partnerships with the development teams in order to really fully understand what's being required of them, what are the details they're being asked to do. And so part of this prevention process is beginning to create this benevolent society of security champions. These are individuals that are tied into the requirements and the design of the product they are going to build early on in that stage. Developing an organization that you can then have relationships with where you are training them, they can give you back and say, hey, these requirements are changing and updating, and you begin this great two-way collaboration that allows you to get deeper into the security minds and hearts of your developers. So the Security Champions Program is kind of the first thing you really have to do to create any kind of application security program, in my opinion. You need to create these partnerships, you know, especially when you're starting with an application security team from the ground up where you— it's a team of one and you have 1,100 developers to work with. There's no way you can train these individuals because typically you want to go to one team at a time and say, hey, in your case, this is how this works. In your case, this is how it works. And that's how you effectively get application security rolling. But when you have partnerships like this, you begin to have a group of 12, 24, 75 individuals that are all kind of on your side saying, we want to learn. Now, I don't pull the wool over anybody's eyes when we do this. We say, hey, this could likely take about 5%, maybe 10% of your time at the height of the season of application security. But at the same time, you give back to them and say, hey, we have some training coming up. We're going to talk about SQL injection. We found an issue here. We want to walk you through what it looks like, how to mitigate all those things. And so you begin this trade of time, and this valuable partnership begins to blossom and become something extremely valuable.

**14:54 Robert Hurlbut:** I consider myself a bit of a security sociologist in that I like to study culture and the way that people approach security. And you used a term here that I've never heard anybody You said a benevolent community of security champions. What do you mean when you say benevolent community?

**15:13 David Kosorok:** Oftentimes, in the old days, and I quote, the old days of security, security comes in there, we build a wall, we toss stuff, we just test, and we toss it over the wall, and we say to engineers, you need to fix this in 30 days or the entire company is going to collapse. You create this whole FUD principle, fear, uncertainty, and doubt. And so, you never develop a relationship that is beneficial to both parties. It is only beneficial to security, and eventually, your relationship weakens so much that you can't get stuff fixed. So, instead of using that principle, using this benevolent society, that means that we're all working together to create something that is much better than we could have done individually. There is no way I could implement security across 80 applications and 1,100 developers by myself. That doesn't even make sense. But when you get groups of individuals that even show interest in security and that you can teach them to develop a passionate desire to learn more by showing them that you're a partner, that they give a little, you give a little, and together you work together to create something that is much better than you could have ever done by yourself.

**16:24 Robert Hurlbut:** That's a great way to think of this, given the fact that historically, like you said, we have a lot of times been— it's been a one-way relationship between security and development, and you're calling for this kind of supportive relationship where it's not just all about what we need or what we get from the world of security. So, that's great to hear that. I love that as the security sociologist in me here. Let's talk about detect. So, code test, what's kind of fitting in your detect pillar, and what are some of the controls that are, you know, you're really driving from there.

**16:58 David Kosorok:** Chris, this is kind of where you begin to introduce the well-known tools that are out there. The tools allow you to do, for example, code review. That's one of the top things on my list where you want developers to be aware of what is existing in their codebase and what they're writing currently. Beginning with SAST, I think SAST, static application security testing, is one of the most important tools. I know a lot of application teams will start with dynamic application security testing because it's something they can do themselves. They can point to a URL, they put a username and password in, and it just crawls for days, and they get some answers. The problem with that is that you don't create partnerships with that tool very easily. You have to— because you come to developers and say, hey, I found this in the GUI, and they're like, well, where is that in the source code? Well, I'm not really sure, but this is what it looks like. Instead, when you work with developers and you scan their source code and you go through the effort of removing false positives and And so you're only feeding them true positives that you validated. They begin to understand that, first of all, you have skin in the game, and secondly, that's where you begin to develop that true partnership. SAST is where I start with on that. Other related tools to that, of course, are open-source scanning. One that I have worked with in the past and I want to bring in again at this new company that I'm at, Interactive Application Security Testing, or IAST. I actually think that's going to replace DAST, but that's a whole different conversation. Then the relationship that you've created with security champions, which includes development and our SQA friends, those together, all of a sudden, you have a group of individuals that can give you feedback. In the IaST world, for example, SDATs from the SQA world can give you automation, or they can run test cases in your test environment and feed the IaST tool valuable use cases that allow you to get really focused results very quickly.

**18:59 Robert Hurlbut:** David, you mentioned a couple of terms here that I wanna get a little better explanation for. So you used the term SQA, and you used the term SDET. Can you give us a little more background or context on when you use those terms, what do you mean?

**19:13 David Kosorok:** Sure. The SQA, or software quality analyst, is just a software tester. It's just another way of distinguishing from a development group. SDET is a software development engineer in test. So, this is basically a developer that's working for the test team. They often will be the ones that write the script or help define or configure the tools more specifically, write custom code to help really dig deep into what they're testing.

**19:40 Robert Hurlbut:** Is this something that's specific to the organization where you're working now, or is this an industry term/idea that I've just kind of missed along the way?

**19:49 David Kosorok:** Well, this mostly comes from Microsoft. Been part of my vocabulary for 20 years. That started with Microsoft and it branched out here and there. If someone hates Microsoft, they'll probably never use that term. But it's something that I've heard. I've heard it used at Align Technology where I work now. I don't think I started it there, but I've heard other testers that have a development background call themselves SDATs.

**20:18 Robert Hurlbut:** Okay, so we've got SAST, we've got dependency scanning, kind of open-source software scanning, IAST, kind of all fitting together here into your detect pillar. And then I guess the third pillar you have here is react, where you have deploy and feedback.

**20:36 Chris Romeo:** And so what are the pieces that fit into your react pillar?

**20:40 David Kosorok:** So, and just to clarify one thing, Chris, I'm going to kind of go back in time a little bit. Prevent, detect, and react are not implemented prevent first, then detect, then react. You typically want to try to implement a small portion of each of these 3 simultaneously. I just want to make sure that you just know that this is not a chronological evolution. It's something that you want to try to do, and then within each of these pillars, you can evolve each of those independently. On the react side, Again, David's opinion here. My opinion is that you want to create a control that allows you to look at any legacy code that's out in public-facing as quickly as possible and as inexpensively as possible. A bug bounty program— I've established this a number of times— bug bounty programs are a very inexpensive way, and they typically cost less than the cost of a great engineer per year, and yet you get hundreds, if not thousands, of resources that can attack your system and give you that specific data before any malicious individual can ever see that. Very, very valuable. The other valuable part to that is, in part of building this secure culture, is your developers also see that these very strong, clearly outlined true positives are coming from an external source that have no access and no knowledge of the system beyond what's pointing externally. So their level of interest is heightened dramatically as they see the ability to say, oh my goodness, this person found this issue that gives them the ability to dump this database, and I never told them how. They don't even have access. They are not a DBA. How did that happen? I am going to jump on that. We have seen through history, I would say 6 or 7 years of experience, where I have seen this particular case where developers are much more likely to understand and jump on this because they get the fact that this is a critical issue, now I know what that looks like, and the story is very, very clear for them. Bug bounty is probably the first part of that REACT that I like to implement. Now, there are other parts to this as well. Pen testing, red team activities, that is another great event where you actually pull in individuals. They may be from a DevOps team, they may be from the operations team, and they may be from the SecOps team, and you come together and create a virtual team where you say, we are going to attack these particular resources of the company, and they learn, they grow, they bond together, and they get to scare their executives to death with their wonderful reports. Other parts to REACT, typo squadding is a very simple and control to implement things like monitoring SSLlabs.com or some external component that looks at the quality configuration of your external-facing components. Those are all an important part of REACT. This is not even talking about the SecOps job of monitoring your network. This is simply looking at the application layer from an external perspective.

**23:49 Robert Hurlbut:** Then when you say feedback, how does the feedback process work in REACT?

**23:55 David Kosorok:** Let's say the— we'll just use the bug bounty program as an example. A security researcher finds an issue. They record it, and within that contract that you create with the bug bounty program— and I usually like to use one of the top 3, HackerOne, Bugcrowd are awesome. Cobalt.io has things in there. There are several, Synack. There are several that are really great out there. But part of that contract is they have to very clearly define exactly how they found that issue. When you do that, developers can then take that and they can go through step by step and see how it is done and then get and understand the exploit and understand the danger of that. That level of feedback from the security researcher to the developer is something that they have probably never experienced before. They can say, oh, This is how that person can get elevated privileges or whatever is happening there. And that really does heighten the awareness, shortens the time to fix, because they understand that this is a real and true issue that their users are potentially facing.

**25:01 Robert Hurlbut:** Yeah, and I'm remembering now back to the talk that you did here for our OWASP chapter, and it seems like we spent a good 30-plus minutes with people asking a lot of questions and you telling stories about the red teaming side of this. And so, we definitely need to bring you back for another episode in the future where we— I've already titled it in my notes here, Red Teaming with an AppSec Flair is the topic.

**25:28 Chris Romeo:** Yeah.

**25:28 Robert Hurlbut:** But I know based on what happened that evening, that's a whole other episode because there are a lot of good stories you have to share from that. So, just to kind of close out our thinking here, I'd love to hear your approach to how you start your security champion programs and how you tend to provide levels and I remember from our previous conversations you've done some pretty unique things there, so I'd love to share that with our audience.

**25:55 David Kosorok:** Yeah, one of the bases for a Security Champions program, I kind of mentioned this earlier, is an educational component. So you go to the developers or engineers, whether it's developers or in software testing, and you say, this is the program that I have. We need your help to identify requirements early on, design issues, be involved in threat modeling, help us drive fixes. And in turn, we're going to provide for you a level of education that will help increase the quality of your job. And part of that is having multiple levels. And so in our program at Align Technology, we have a bronze, silver, gold level. Each of those levels actually has requirements that you have to meet. Some are based on time. So you have to be a— for example, you need to be a security champion for X number of months before you can go to the silver level. So as a bronze, you have to operate as a bronze, and that may mean something as simple as, hey, I've implemented static analysis on my team and we're driving the fixes for the most critical issues so that we're fixing those issues in less than 30 days. Something that's measurable, something that's relatively straightforward, and something that is for the benefit of all parties. In other words, you don't want to just say, hey, we're going to fix critical, high, medium, low, all 3,000 issues because David says so. But instead you say, here's the value, we're protecting our customers, and we're going to go with the most exploitable issues and start with something that every engineer can understand and get their hands wrapped around. So having that, and we actually have a website, one of our brilliant IAM engineers actually developed an internal website that tracks all the engineers that are part of the Security Champion Program. and tracks. They can actually go in and check off and say, oh, yeah, I've taught a 15-minute security discussion to my team. David, here's the presentation we used. I check it off. They get that requirement. Then, when they get each award, we actually have mission coins or challenge coins that we give them. The intrinsic value almost doesn't matter. The fact is you're recognizing the fact that they are progressing through their security knowledge. steps at a time. And so over a couple of years, we hope to see silver and gold level security champions. And that means people that are dedicated, that have gone out on purpose to do additional security education beyond what we have provided. Maybe they've gone to different sites and pulled in free education on different— maybe they've gone to hacker101.com and learned how to be a bug bounty hunter, you know, or Any one of those things. And so they report back to us on how they're progressing. And so we just want to continuously reward them for those kind of efforts, even though it may not be worth millions of dollars. It does show that level of recognition.

**28:42 Robert Hurlbut:** Yeah, I— when you showed me those challenge coins, I thought, wow, those are, those are really— it's just a neat way to reward somebody with something that doesn't cost you, like you said, doesn't cost you a million bucks to, to have them made.

**28:56 Chris Romeo:** But it is something special, right?

**28:57 Robert Hurlbut:** It's not something that everybody's getting. It's not just— we're not just handing these out like trophies at a kids' sporting event, right? I mean, this is something that they had to actually work and achieve some goals to be able to receive that recognition. And so, yeah, I'm a big fan of recognizing our people, our burgeoning security people, and encouraging them to keep going. And sometimes it's just a little bit of recognition is a way to help them kind of move forward. Well, this has been great, David, once again for me to hear your perspective and for Robert and I both to hear your perspective on how you approach building programs and, you know, doing some, some unique things that I think will be very helpful for our audience to understand. And so we want to thank you for taking the time to share your expertise with us, and we will definitely have you on in season 7 to talk about that red teaming with an AppSec Flare.

**29:47 David Kosorok:** That would be awesome. Thank you, Chris. Thank you all.

**29:51 Chris Romeo:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/david-kosorok-the-three-pillars-of-an-appsec-program-prevent-detect-and-react/