---
title: "Season 5 Finale — A cross section of #AppSec"
url: https://appsecpodcast.com/season-5-finale-a-cross-section-of-appsec/
date: 2019-10-26
duration_seconds: 2269
topics: ["Threat Modeling", "OWASP Projects", "Software Supply Chain", "Careers in AppSec"]
audio: https://www.buzzsprout.com/1730684/episodes/8122625-season-5-finale-a-cross-section-of-appsec.mp3
transcript: true
---

# Season 5 Finale — A cross section of #AppSec

*October 26, 2019 · 38 min*

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Careers in AppSec](https://appsecpodcast.com/topics/careers/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122625-season-5-finale-a-cross-section-of-appsec.mp3)

## Show notes

Season 5 covered application security from tools and threat models to mentoring, self-care, coaching, dependency risk, and program design. Chris and Robert revisit the guests whose explanations best captured that range. Simon Bennetts introduces the ZAP Heads Up Display, Izar Tarandach explains pytm, Tanya Janca and Nancy Gariché discuss mentoring, Björn Kimminich presents Juice Shop, Caroline Wong addresses self-care, Adam Shostack examines the human layer of threat modeling, Matt McGrath defines security coaching, Steve Springett explains Dependency-Track, and Ronnie Flathers describes building sustainable programs. Organized as guest-level chapters, the finale works as a guide to the season and a reminder that effective AppSec combines technical capability with community, learning, and organizational change.

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 Chris Romeo and Robert Hurlbut:  
→ [Chris Romeo on LinkedIn](https://www.linkedin.com/in/chrisromeo-appsec)  
→ [Robert Hurlbut on LinkedIn](https://www.linkedin.com/in/roberthurlbut)

Mentioned in this episode:  
→ [OWASP ZAP](https://www.zaproxy.org/)  
→ [ZAP Heads Up Display (HUD)](https://www.zaproxy.org/docs/desktop/addons/hud/)  
→ [pytm](https://github.com/OWASP/pytm)  
→ [OWASP Juice Shop](https://owasp-juice.shop/)  
→ [Dependency-Track](https://dependencytrack.org/)  
→ [Sonatype OSS Index](https://ossindex.sonatype.org/)  
→ [SPDX](https://spdx.dev/)  
→ [#CyberMentoringMonday](https://www.linkedin.com/pulse/mentoringmonday-tanya-janca)  
→ [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/)

Chapters:  
00:00 Season 5 highlights  
02:46 Simon Bennetts on the ZAP HUD  
04:50 Izar Tarandach on pytm  
07:32 Tanya Janca and Nancy Gariché on mentoring  
11:29 Björn Kimminich on OWASP Juice Shop  
15:43 Caroline Wong on self-care in security  
18:00 Adam Shostack on threat modeling’s human layer  
20:54 Matt McGrath on security coaching  
24:06 Steve Springett on Dependency-Track  
28:22 Brook Schoenfield on security architecture  
31:12 Ronnie Flathers on building AppSec programs  
35:28 Closing Season 5

## Transcript

*6,080 words · assemblyai*

**0:00 Chris Romeo:** Hey folks, this is Chris Romeo, co-host of the Application Security Podcast and CEO of Security Journey. And we've reached the end of season 5. And so this is our episode where we provide some of the highlights, some of the things that really stuck with us. And so we hope you enjoy this walkthrough of the various highlights from season 5. 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. We don't do lectures. 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. The Application Security Podcast. Here we go. Our first clip comes from season 5, episode 1, where Robert at CodeMash asks Georgia Weidman, what are some of the biggest security risks in the world of mobile today?

**1:47 Robert Hurlbut:** I think the biggest thing is probably phishing. And that's surprising, I think, maybe to hear me say that because I guess I have a long history of saying that phishing is like what hackers who can't hack do. Like you can't write a buffer overflow, so you'll phish somebody. But, you know, as I've matured the industry has matured around me, it's— that's the way even the people with the zero days, you know, it's very rare that you don't have some sort of phishing component of just getting someone to open a link even or download an application. So there's definitely a phishing component, and we certainly haven't solved the phishing on email, and there's all these different new ways that people can be phished. You know, you can have them scan a QR code, text message, Social media, I mean, all those social medias have messenger functions where they can put links in them. So there's so many different ways that people can be attacked via phishing, and I think that's going to continue to be a really, really big one.

**2:46 Chris Romeo:** The next clip comes from episode 3, where Simon Bennetts from the OWASP ZAP team explains to us this new idea of a heads-up display in ZAP. Sometimes security professionals focus on their security tool too much. And they don't spend enough time actually in the application. And I think that's important because some of the most interesting application vulnerabilities are when you abuse the application functionality, when you get under the skin of the application, really understand it and work out how to do bad things with it. And some of those things, tools will never help you with. You need that human brain to work these things out. So I was worried that people were spending too much time either in ZAP or in other security tools and not enough time in the application itself and seeing what they can do with it. So what we just— we talked about this in the team and we decided to come up with this thing which is the heads-up display. And, you know, for something like a fighter pilot, the heads-up display is taking all the essential controls and projecting them on the screen of the fighter plane so they can just see— so they can focus on the environment but see this information and react to it as needed. And when you're dealing with a web application, the— your field of view is the browser. So basically taking information from ZAP and then making it available in the browser. So what the HUD is, basically we inject the HUD into the browser. And so you don't need any browser add-ons and the idea will be on by default within ZAP. But you will be able to turn it off if you don't want it. And we basically add information around the left-hand side, the right-hand side, and the bottom. And that gives you information about types of vulnerabilities ZAP has found. When it's making requests, you'll see counts go up. You can see whether there are hidden fields. And you can also interact with the application via the HUD as well. Interact with the application and ZAP itself. Next clip is Izhar Terendok. from episode 4 talking about PyTM.

**4:50 Robert Hurlbut:** PyTM is first of all the, the fruit of the collaboration of, uh, 4 people, not only me. There's also, uh, Matthew Coles, Nicholas Moore, and Rohit Chandhoni. So the 4 of us started talking about how we could make that something more accessible and something more extensible, and we got to this idea that ended up being PyTM, which is basically a library written in Python that gives out elements and produces some form of output based on the attributes of those elements, of those objects. So the whole philosophy of the thing is to have a small tool that does a couple of small things well done. But at the same time permits you to keep all the information that you need to describe your threat model close to the code so that developers will be able to do it. And the input is itself code so that a developer doesn't have to get out of their comfort zone to develop that input that eventually will generate the threat model. So the capabilities that we have today with PyTM you write your Python description of the system, and by that you import a couple of basic elements that we provide: server, an actor, or data flow, and a couple more. And then you set attributes on those elements, and at the end you call the library, you call an entry point in the library, and depending on what you put on the command line for that script that you just wrote, you're going to get different kinds of output. So today we can generate data flow diagrams that get interpreted by Graphviz via DOT and give you a flow diagram, or the same input can generate a sequential diagram if you are just modeling a protocol, and then you're able to look at it that way with exactly the same In episode 5, we hear from Omer about how to properly and securely store secrets with Kubernetes. And Komoot is an open source I built at Celuto, which basically lets you do the same thing as Travis encrypted secrets. It lets you encrypt the secrets for a specific application on Kubernetes, and only this application can decrypt it. So if you go back to the super devs, the way Komoot works is that anyone can encrypt the secret But once the secret is encrypted, no one can decrypt it.

**7:32 Chris Romeo:** In episode 8, we get into mentoring with Tanya and Nancy.

**7:37 Robert Hurlbut:** Well, since I started in InfoSec, I started with a professional mentor, and then eventually I kind of graduated his mentorship and then moved on to— that's part of how I met Nicole and why we started the project, is she's taught me so much. And as I've continued to progress my career, I keep having more and more mentors that, quite frankly, like just all of them astound me that they would give me the time of day. And then I've been mentoring other people. And as I've started getting more followers on Twitter and such, I had people ask me if I would be their mentor. But I already mentor some people and I realized if I took on more, I wouldn't have any time for them and I would be an even more absentee mentor than I already feel like I am. And that would not work.

**8:25 Chris Romeo:** Yeah.

**8:26 Robert Hurlbut:** So I still wanted to help them though. Um, so I started this hashtag, #MentoringMonday. So as you might imagine, it happens on Mondays. Every Monday I just, I just tweet, you know, it's Mentoring Monday. Are you looking for a mentor? Are you willing to share the information that you have and, you know, teach someone and help them blossom? Just respond, use the hashtag and say if you're offering or asking or both and what topics. Most people for some reason forget to use the hashtag. And although I get that if they're responding to my tweet, that I get why they might forget to use it, but people are searching the hashtag each month, each week, and responding to the people directly because not everyone wants to, you know, offer publicly. Because some people have told me when they say, oh, I'm willing to offer in this, they get 20 responses and they're overwhelmed. So instead what they're doing is like, answering people really directly who have requested a specific thing and they think they'll be a good fit. So using the hashtag is really important. And then, yeah, people have been naturally pairing themselves up. It's been so magical. People have been telling me all sorts of wonderful little stories of like, now I have 2 mentors, or, you know, this person introduced me to someone really important and then I ended up getting a job because of it, or I'm reading all these books thanks to the people you introduced me to. But really, it's the community coming forward, right? A lot of people feel like they might not know enough to mentor someone. I just— person after person tells me like, oh, I, you know, I don't have enough experience. I'm like, how long have you worked in, you know, a SOC or whatever it is you're doing? And they'll say 10 years. I'm like, trust me, you know a ton. There are so many people that wish they knew, you know, 1/10 of what you know. I feel that if you have been doing your job for 2 years or more, that you likely know enough that you could mentor someone else. And people that are more senior in our community, in my opinion, should— I would like it if they would consider mentoring someone. How about that? We won't have any new senior people if there's never any junior people, right? Or we won't having to go from junior to intermediate without a mentor, it takes so much longer. Like, I feel I've done so well in InfoSec specifically because I've had these amazing people advocating for me, teaching me, helping me, making really key introductions for me. And, you know, without these people kind of pushing me forward, I wouldn't be where I am today. So if we want to have more senior people, which we do, I feel like a lot of us need to pitch in. And so far, the community has been really wonderful. I really encourage people on Mondays or whenever, just search the hashtag #MentoringMonday and respond to people, even if it's just to suggest, like, this is the best book I've ever read on this topic.

**11:29 Chris Romeo:** In episode 9, we had a visit from Bjorn Kimmenich, who is the project lead for OWASP Juice Shop. And he answers for us Why should someone care about OWASP Juice Shop and what is it?

**11:41 Robert Hurlbut:** The Juice Shop is, well, its catchline is, or catchphrase is, it's probably the most modern and sophisticated insecure web application. It's an OWASP flagship project which was created out of desperation by myself some years ago because I needed something to use for developer security trainings. So the main problem I had using old applications like the budget store or the, the Altoro Mutual Bank page and all that stuff that didn't really work any longer because there was so much new technology, especially in the front end and this whole REST API-based applications that wasn't just— that just wasn't covered anymore. So I decided to create my own vulnerable application for my company-driven security trainings. And I initially started that as a private open source project and then sometime later made an OWASP project out of it. So as a developer, you actually, you actually want the Juice Shop because you can— I think you can learn almost every existing known security vulnerability in web applications from it and not in a boring way, but by just trying out attacks and practicing. It's very strong in gamification by offering a scoreboard which keeps track of your solved hacking attempts or your successful hacking attempts. We call those challenges and the Juice Shop at the moment has 87 different challenges. There's tons of cross-site scripting, SQL injection, and the usual stuff, but also many many vulnerabilities in business logic and functional flaws and design problems, missing or lacking validation and all kinds of things. So it's full of interesting stuff. Yeah, so developers actually should take a look at it because I think it's the most sophisticated way to learn web application security. It's also interesting for management trainings. If you want to raise the awareness of your IT management, then you can also use the Juice Shop more in a demonstration way. You can also tune it to run capture the flags with. That's a little side project that allows you to quickly set up a CTF server in 5 minutes with the Juice Shop challenges with no manual data entry. Just a simple import feature. Yeah, you can also customize the juice shop look and feel to make it look like an application of your own company. So that's not necessarily useful for developers because they can also relate to an application which— or to a webshop that sells juice and related products even if they don't work in that business. But management sometimes can't. So for managers, it's I think quite helpful if the application they see and they get vulnerabilities demonstrated and actually see something that they know from their own world, from their own context. You can basically completely change the entire look and feel of the application with some nice configuration mechanism. That's basically the core stuff. Personally, I'm using the Juice Shop also in university lectures. So, to actually bring across the important topics from OWASP Top 10 and everything beyond right away to new developers so that they don't make the same mistakes like today's developers might make.

**15:43 Chris Romeo:** In episode 10, we talk with Caroline Wong about what is self-care and how does it apply to the world of Application and information security.

**15:52 Robert Hurlbut:** Self-care is the acknowledgement that security teams are made out of people and people are human. And there are things about us as human that affect the way that we behave and that affect our work. And I'm so interested in figuring out how to get security teams to work as top performers and how people can be most effective. And I believe I've come to discover myself personally that I actually perform my best at work when I'm taking care of myself as a person. And I think that, you know, there are some things that because of our biology as human beings are common. You know, I think that we certainly tend to be healthier and therefore think better and feel better when we're getting, for example, enough sleep, when we're getting, for example, proper nutrition. You know, those are some of the baseline things. And then beyond that, I think it depends on the specific individual You know, whether we're introverted, whether we're extroverted, you know, what other sorts of things we need to feel whole and to feel full, full of energy that we can then put into our work and into whatever areas of our lives we choose. You know, for me, I get a lot of energy from spending time with my family and with our pets.

**17:36 Chris Romeo:** Mm-hmm.

**17:38 Robert Hurlbut:** You know, for other folks, it might be hiking, it might be music, it might be, you know, whatever it is that you do, you know, not only with your time, but more importantly, I think, with your mind, in order to make yourself happy. I think that, I think that that's really sort of the antidote, if you will.

**18:00 Chris Romeo:** This clip is from episode 12, where we're joined by Adam Szostak. And we asked him, when you say threat modeling layer 8, what do you mean?

**18:10 Robert Hurlbut:** So historically, when I talk about threat modeling, I talk about 4 questions. What are we working on? What can go wrong?

**18:20 Chris Romeo:** What are we gonna do about it? Did we do a good job? And within what can go wrong, we like to talk about things like STRIDE. So spoofing, tampering, repudiation, that sort of problem.

**18:36 Robert Hurlbut:** Okay.

**18:37 Chris Romeo:** As technology underpins more and more of the world, what we're working on starts to have social aspects.

**18:47 Robert Hurlbut:** It starts to have user-generated content aspects.

**18:53 Chris Romeo:** And we've seen this, you know, flame wars going back to the days of Usenet.

**19:01 Robert Hurlbut:** And there's a There's a woman by the name of Wendy Grossman who's an author and historian. And in her Net Wars book, she documented how design choices that America Online— remember them—

**19:19 Chris Romeo:** made when they created a Usenet gateway. Remember Usenet?

**19:23 Robert Hurlbut:** And specific ways in which America Online represented Usenet to its customers generated flame wars inevitably, that the design of the technology either creates problems or it alleviates problems.

**19:50 Chris Romeo:** Sometimes those are problems that are created by the platform, Twitter's use, and I'm mentioning these things as examples.

**19:57 Robert Hurlbut:** I don't mean to throw shade on anyone here. But Twitter's decision to put all of your @mentions into a tab that you can look at necessitated the creation of block and mute functions. Yelp, when a restaurant is in the news, puts up an interstitial and says, hey, we know that you're upset about this restaurant for something other than the service and the food that it delivers to you. Maybe you shouldn't write reviews. These are technical choices which involve threats that are related to, but different from, the threats that we have traditionally threat modeled for. And so I've been exploring how do we take the same 4 questions and start to produce answers around what can go wrong and what are we gonna do about it?

**20:54 Chris Romeo:** In episode 15, Matt McGrath answers the question for us. What is a security coach and how are they used?

**21:01 Robert Hurlbut:** So really what we tried to do with this concept of security coach, I mean, when you think of coaches, you think of, at least for me, I think of like sports coaches and wellness coaching and even life coaching. And a lot of those things have common is that they're trying to help not even just win. I mean, yeah, if you think of a sports team, you're thinking, how do I win? But really How do you help the individual, you know, really get forward themselves and not just do it for them? But how do you help them want to get better, want to do things? So you think of a wellness coach, you know, how do they want to— that, you know, they have to want to be better at wellness. Because if you tell them that you have to do it, they may or may not do it. Same thing with security here, right? You can sit there and tell And I know this because I've done it, you know, you can tell them what they have to do, but if they don't understand why they're doing it and the value that it adds, it's not really going to stick, you know. And that's one of the things I always thought is good coaches really help the individual come up with their own solution because they know it. It's just how do you get it out of them? And that's really what we wanted to do here with security coaching. We hand these developers requirements, the security requirements, and we hand them all of these things. You have to build this secure. Our number one vulnerability is input SQL injection, so fix it, right? Well, they'll fix it, but why do they need to fix it? What's the ramifications if they don't? Well, what if they hurry up and shortcut? Because you know what? They're getting bombarded with requirements, and the product owners are, we need to get the next deliverable out, and you want them to be able to remove these security blocks not just quickly but with high quality so that that application is as secure as it can be. Because it just takes one slip for a hacker to find a way in, and there goes your brand, there goes your identity, there goes, you know, your reputation, the trust. And so what we try to do with the security coaches is really build that Hey, we're not just going to hand you things and tell you to go fix it. We're here for you. We want to help guide the developers. We want to help them build things securely. We want— we know they have it in them. I mean, I was a developer. I know, you know, I don't build a code base and just want to whip some code and throw it out there and say I'm done. You know, that has my name on it. That has my reputation on it. And I want to build it good. I want to build it secure. And I got all these external factors pushing me to hurry up and do it fast.

**23:39 Chris Romeo:** Right.

**23:40 Robert Hurlbut:** You know, that's why we have coaches here. We'll help you. We'll guide you. We'll, you know, we'll lead you to where you need to be. Just engage us. And that's really what the concept here for coaching is. It's nice because it's like internally here, it's really a comforting word for them to say, you know, I need some help. Here's a coach that can guide me, that can lead me, not just tell me what to do and walk away. They're going to take the time so I understand it.

**24:06 Chris Romeo:** Episode 17, Steve Springett joins us to talk about Dependency Track and how it works, and also a buyer's guide to software composition analysis. So Dependency Track is a flagship OWASP open source project that helps organizations identify and reduce risk from the use of third-party and open source components. It would be classified as an SCA product by the market research firms, but Dependency Track identifies more as a software supply chain component analysis platform. And what does that mean? It means that we're— we don't necessarily care about the— what the components are. If they're software, we can analyze them. If those components are hardware or operating systems, we can also analyze those. So it's really about identifying and reducing the risk from the use of third-party and open-source components across your entire enterprise. If you have tens of thousands of applications in your environment and you are producing software bill of materials in a CI/CD pipeline, DependencyTrack can automatically ingest, automatically analyze, and automatically alert you of any kind of vulnerability or other types of risk. You can also, with DependencyTrack, identify those assets that are at risk in your environment. So if the new Heartbleed, if the new you know, new CVE with a flashy marketing website comes up next month, you can quickly identify what assets in your environment are potentially affected. DependencyTrack really is an API-first thing, so it's really designed to be embedded in a CI/CD pipeline where you are constantly feeding it software bill of materials. You can also obviously, you know, get software bill of materials from vendors and that sort of thing as well and, you know, upload those to Dependency Track where they can be processed. But it's really about analyzing all these components constantly in your environment. The platform itself integrates with multiple sources of vulnerability intelligence. Out of the box, it supports the National Vulnerability Database. It supports Sonatype OSS Index. It supports the npm advisories. It supports VulnDB from Risk-Based Security, and there's more sources of vulnerability intelligence that will be supported in the near future. It also identifies whether or not your components are out of date. So it integrates with Maven, it integrates with npm and Ruby and Python and all these other ecosystems to determine whether or not your components are out of date. And of course, it supports SPDX licenses. So it normalizes and identifies what your components components are licensed as and tries to evaluate the risk based on your license as well. At the end of the day, having all this intelligence is great, but you need to do something about it. And that's where the REST APIs, that's where the webhooks really come into play here. Being able to have webhooks, being able to receive webhooks when those new vulnerabilities come out, when new audit decisions are made, maybe a component is, is now exploitable and it wasn't previously. Having all of this dynamic intelligence delivered to you from Dependency Track is really a game changer. So identifying what those risks are, what those components are, identifying the risk, and trying to get organizations to actually do something because of the API integration that it facilitates. In episode 19, we're joined by Brooke to talk about his experiences building programs more from an architecture perspective?

**28:22 Robert Hurlbut:** Okay, you can't mandate a security architecture or AppSec, that is application security or software security, however you want to talk about it in different organizations, you know, focus slightly differently. You can't just start it by, by having some exec saying, now we're going to have secure software and writing a bunch of policies and handing them to everybody and saying, see, now we're secure. That is the biggest mistake that I see over and over again. People think that they can just policy their way into this problem. I'll bet both of you have seen that problem as well. The policy underlies things. It's not that it isn't important, but nobody does something, especially smart engineers, just because it's written somewhere. And maybe they got it in once a year in their, in their, you know, did you read the policies test and then forget about it in terms of their work completely. That's the one thing I see a lot of times is that— or, and the other thing is you can't test your way out of this problem. Not that testing isn't also important, but it's not— you can't just turn on one tool And I've seen this. Oh my, have I seen this. You turn on one tool and don't we have the problem covered? In fact, that is actually a quote from a very brilliant CTO who looked at my boss, not me, but my boss, and said, we have static analysis. Why do we need a program? I love it. Yeah. And it just doesn't work that way because it's so multilayered and multivariate. and multidimensional, and a lot of it has to do with culture and mindset and willingness and humans. Automation too, but humans. And so that's the mistake there, is the 2 big mistakes that I see. Then we can talk about how you'd really do it and be successful. And just to put a little flesh on those bones, I've worked for 4 different organizations where I've built software security programs, um, I've been the technical lead for a software security program, um, and so, you know, I've made lots of mistakes which, uh, then we, you know, have dealt with, hopefully, and, and built, and every one of them has been successful over time. Um, so it's a long journey, it's a long journey thing. You're not going to get it in in 6 months. You gotta take a few years. And when you take a few-year view, it really shifts the way you look at the problem.

**31:12 Chris Romeo:** Our final clip comes from episode 20, where Ronnie Flathers joins us to talk about building application security programs, large and small. I mean, if you read some of the descriptions, it's like what's necessary now to run an effective application security program is we need someone who's basically fluent as a developer, is familiar with all the latest JavaScript frameworks or latest DevOps tools and DevOps technology, Oh, and on top of that, we also need you to be a security expert. And those are the types of unicorns that I think all the companies are trying to compete to hire on right now. And it's extremely difficult to find. And I don't think that that's a sustainable model. No, I don't either. And that's— yeah, I mean, a number of friends of mine, I'm sure like friends of yours are, by the time you learn that somebody is unhappy, they're already at a new job. And all you do is you see like, oh, look, they got a new job. They were unhappy on Thursday and on Monday morning they started their new job because it's that crazy of an industry. That definitely does play into the current state of software security, the fact that security is lagging behind where some of these, some of these development resources and development frameworks and things are at. So what else? What other reasons do you think, or state of software security? Yeah, I think kind of building on that training, it needs to kind of be a little more updated as well. I think what, what we just talked about, that model of hiring is kind of looking at it backwards. I think a lot of companies are trying to find security professionals and then expecting them to drop in and then learn the development practices, the coding, the DevOps materials, and fit in with a development team coming from a security background. And as we know, that's going to be very hard to fill because there's a talent shortage of security professionals. So I think the inverse is what's going to become more and more popular, and I've seen it work very successfully both here and at other organizations, is hiring from development and teaching them security. And I've seen a lot of, of great security training programs be put into place and a lot of great success stories where if you have a very good or experienced developer who has an interest in security, I feel personally it's easier to teach security to a developer like that than it is to take a very talented security person who may not know how to code or, or develop with latest languages and frameworks and teach them that aspect. Yeah, I, I have seen the same thing, and, and I agree with the kind of the, the inverse that you're describing here. I guess the thing that I've seen in My experience is a little different than what you said, is that taking that developer, you have to find the developer that has the passion.

**33:39 Robert Hurlbut:** Yep.

**33:40 Chris Romeo:** I've seen too many times where, you know, I mean, if I hear the word voluntold one more time, like, I'm gonna flip out because I just, I can't, I hate that as a term. Like, nobody should ever be voluntold because what does that mean? How much effort are you gonna put in if your exec says, oh yeah, you're our security champion now? You're gonna be like, this sucks. I want to do whatever I have to do to make these people leave me alone. There's no passion in that. And so like when I've run security advocate programs in the past, I want the people that live, eat, breathe security and just happen to develop during the day, you know, as their day job. But they really love this security thing and they've got that passion because it's like, it's like throwing gasoline on a fire. When somebody's got that passion, it's a big— it's a poof, right? Because all you got to do is throw a little bit more on that fire and it just explodes and gets a lot bigger. Yeah, exactly. It's one of those intangibles that's so important. It's hard to quantify. It can be hard to identify, but when you have it, don't let it go. You got to fuel that passion. And yeah, the same with our Security Champion program here, or working at previous companies. I know that I can recognize those developers because they're the ones who are coming to me in their free time and picking my brain, or coming up with a vulnerable app like OWASP Juice Shop open on their machine saying, hey, I'm trying to get this cross-site scripting vulnerability. I'm trying to understand it. Can you show me how work this. Those are the developers that we got to be targeting because those are going to be the next generation of the security professionals. Yeah, yeah. And it's funny. So what Security Journey, what my company does now, is we actually do training things like what I did at Cisco with the Cisco Security Ninja. And people, our customers, always ask us, well, you know, how do we find our security champions? How do we find them in this big organization? Like, I can tell you some— I can give you a list of people that you should go talk to. And they're like, how can you do that? You're not inside our company. I just go and look and see who's gone through the training at a super high rate of speed.

**35:28 Robert Hurlbut:** Yeah.

**35:29 Chris Romeo:** Like, if somebody's gone from, you know, we have 3 kind of primary levels of learning, white, yellow, and green in our system of security belts. And if somebody's gone through those 3 belts, which is like 40 hours of investment time in like 3 months, that's somebody you want as a security champion because nobody told them they had to do that. They decided in their nights and weekends that, oh, this security thing is pretty cool. I want to go spend some time actually getting involved and learning more about it on my own because I see a future here. Yeah, and I think to, to even make it easier to identify that type of talent, you know, you may have that organic talent within your organization that's just chomping at the bit to become a security professional or an application security specialist. It kind of leads to the next point I was going to make about the trends I've seen in software security, which is security needs to collaborate a lot more and more closely with the development side of the house. And the security programs that I've witnessed over my career that I'll say are the least successful are the ones that have built walls and silos around themselves and don't know what's going on on the development side of the house. It's kind of just chucking findings over the wall and expecting the developers to deal with it, or the security professionals who have their heads down in tools and are just scanning code after the fact and then throwing Jira tickets back to the developers. You don't get that collaborative atmosphere in which you can learn from the developers and the developers can learn from security. And when you have that collaboration going on, you're actually hosting joint sessions or learning sessions together And you're identifying the developers that have that passion in security, it's going to help you grow your security team more, and you're going to build more trust between your security team and the development teams, which benefits everyone in the long run. 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/season-5-finale-a-cross-section-of-appsec/