---
title: "Brenna Leath -- Product Security Leads: A different way of approaching Security Champions"
url: https://appsecpodcast.com/brenna-leath-product-security-leads-a-different-way-of-approaching-security-champions/
date: 2022-03-09
duration_seconds: 1991
guests: ["Brenna Leath"]
topics: ["Building an AppSec Program", "Security Culture"]
audio: https://www.buzzsprout.com/1730684/episodes/10217598-brenna-leath-product-security-leads-a-different-way-of-approaching-security-champions.mp3
video: https://www.youtube.com/watch?v=rwS6PMwr9MQ
transcript: true
---

# Brenna Leath -- Product Security Leads: A different way of approaching Security Champions

*March 9, 2022 · 33 min*

with [Brenna Leath](https://appsecpodcast.com/guests/brenna-leath/)

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

[Audio](https://www.buzzsprout.com/1730684/episodes/10217598-brenna-leath-product-security-leads-a-different-way-of-approaching-security-champions.mp3) · [Video](https://www.youtube.com/watch?v=rwS6PMwr9MQ)

## Show notes

Brenna Leath is currently the Head of Product Security for a data analytics company where she sets the application security strategy for R&D and leads a team of security architects. Brenna originally joined us to talk about EO 14028 and the implications for private sector programs, BUT, we were chatting about security champions and product security leads, and we changed our focus to cover these topics instead. We hope you enjoy this conversation with... Brenna originally joined us to talk about Executive Order 14028 and the implications for private sector programs. But as we were chatting about security champions and product security leads in the preamble to the interview, we decided to change our focus and cover these topics instead.

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

About Security Journey  
Brenna Leath is currently the head of product security for a data analytics company where she sets the application security strategy for research and development and leads a team of security architects.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Brenna Leath:  
→ [Executive Order 14028](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)  
→ [BSIMM](https://www.blackduck.com/services/security-program/bsimm-maturity-model.html)

Mentioned in this episode:  
→ [Executive Order 14028](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)  
→ [BSIMM](https://www.blackduck.com/services/security-program/bsimm-maturity-model.html)  
→ [OWASP Cornucopia](https://cornucopia.owasp.org/)  
→ [Burp Suite](https://portswigger.net/burp)  
→ [Log4j](https://logging.apache.org/log4j/2.x/)  
→ [OWASP Cornucopia](https://owasp.org/www-project-cornucopia/)

Chapters:  
00:00 Meet Brenna Leath: Product Security Leads: A different way of approaching Security Champions  
04:02 Film studies and English is a fascinating combination for me. And  
16:14 Yeah. So you may— you use the word federated in regards  
19:35 Yeah, there has to be some, some action that they can  
25:49 We don't believe in scaring people with it. So, so I've

## Transcript

*5,068 words · assemblyai*

**0:00 Chris Romeo:** Brenna Leath is currently the head of product security for a data analytics company where she sets the application security strategy for research and development and leads a team of security architects. Brenna originally joined us to talk about Executive Order 14028 and the implications for private sector programs. But as we were chatting about security champions and product security leads in the preamble to the interview, we decided to change our focus and cover these topics instead. Product security leads, a different way of approaching security champions. We hope you enjoy this conversation with Brenna Leath.

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

**0:47 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. My My name's Chris Romeo. I'm the CEO of Security Journey. I'm also joined by Robert, my good friend and co-host of the Application Security Podcast. Hey, Robert. Hey, Chris. Yeah, Robert Hurlbut, and glad to be here. I'm a threat modeling architect, and I'm really looking forward to our talk today, trying this again. A couple times we tried, and looking forward to it. Technology is a wonderful thing when everything works as planned, but, you know, as good security professionals, we always, you know, are happy when the security policies take effect and prevent us from doing something. But no, we don't. We're just as annoyed as everyone else on earth when that happens. But we were going to originally talk about the NIST executive order, but then in the preamble to this conversation with Brenna Leath, we started talking about security champions and off we went. So, Brenna, we always like to start with our guests' security origin story. So, tell us how you got into this crazy world of security.

**1:49 Brenna Leath:** Sure. I was, I was trying to give you a new and different topic instead of just talking about security champions all the time, but you know, when you love something, you love it. So I respect that. My name is Brenna Leath. I am the head of product security at an analytics software company. I have a small team of security architects, and I also have, uh, Matrix— we'll call them Matrix Reports product security leads, which is what you guys got very excited about as soon as I mentioned that. So, uh, my journey into into software security. I have a master's degree in film studies and a bachelor's in English, which a lot of people would think doesn't equate to working in technology and are surprised when they find out what I actually do. So I started right out of grad school at the North Carolina State University Library. I was running a digital media lab with a lot of student workers, so that's audio editing and video editing. And then I started working in a somewhat technical writing facility as a developmental editor, which turned out to be mainly project management. So I transitioned into project management and I joined research and development as a localization project manager. And then after doing that for a while, I noticed that our security project manager was getting overloaded with a lot of work and projects and I had sort of automated a lot of my responsibilities that had largely been taking up my time previously. So I asked to start helping with that. And I ended up running one of our product security compliance processes that had to be driven throughout R&D. And we have a large R&D. It's about 5,000 people, 2,500-ish developers. So after I'd been doing that, the security team asked me to join full-time as a security compliance engineer. And after I'd been doing that for a while, it sort of morphed into more of a Renaissance security engineer position. And fast forward, now I lead the team.

**4:02 Chris Romeo:** So film studies and English is a fascinating combination for me. And I, I love to hear stories about how people have come into security from other disciplines and studied other things. And so I'm curious, what can you draw from your experience studying film and studying English And how do you apply those things into your job in security?

**4:25 Brenna Leath:** So I watched a panel a little while ago with a bunch of application security professionals. It was Netflix and Spotify and a couple other people. And the topics were what was overrated and what was underrated in application security. And one of the top underrated skills was communication skills. And I find that to be so true. I have very strong communication skills because I studied English and also film studies, which is a lot of writing. But what it really is, is a lot of listening, a lot of watching, a lot of analyzing, synthesizing information, and then drawing either conclusions or extrapolations or observations and bringing what may seem to be very disparate things into a clearer focus through analytic thought. So when you translate that to application security, I think especially when you're looking at the secure software development cycle as a whole, there are many different stakeholders, there are many different processes, many different tools. Weaving those together in a way that seems to make sense, or as I'm constantly saying, getting to a root cause analysis instead of attacking the symptoms, is a very analytic thought process. Being able to both communicate those observations and then persuade people to act on those observations and/or explain what it is they need to do ends up being a critical skill, especially the more people that you end up having to interface with in a large organization like I'm in.

**6:08 Chris Romeo:** Then if we kind of go into this topic of product security champions and leads and things like that, when we were chatting earlier, one of the things that really caught my attention is you described for us how you had products, you have product security leads, and they have security champions that report in, that work with them. And so, I've studied champions programs, I've run a few of them, I've helped other people launch them, and I've never had anybody attempt this. And so, you mentioned in your intro that you had these product security leads matrixed to you. So, let's start with that product security matrix.

**6:45 Brenna Leath:** It's like a human pyramid of security champions. It's amazing. So what I realized when I took on the head of product security role was we had a lot of very big challenges ahead of us and we did not have enough security people. There is a serious talent shortage in the industry and I don't see it getting any better anytime soon unless Either we're homegrowing talent or we're looking in unlikely places. And I might be slightly biased because I am one of those unlikely places/homegrown talent. I was a project manager plucked out of project management into security, and now I am a security leader in my organization. So while that might seem odd to people, I think what it really is is a testament to if you have intelligent people who are quick learners, who are curious, who are passionate, who are innovative, give them something they can care about and they will show you what they can do. So when I got into the head of product security position, my executive team asked me what I needed to be successful. in the role. And the first thing I said was, I need people, but I don't need to hire 8 people at once. What I need is every division that we have to either internally nominate or open up an internal position to devote one person full-time to product security and call them product security leads. And the way that I explained the role, I have a really cool PowerPoint slide that sort of shows the liaison role of product security leads being the connection between the central product security office and our 150 to 200 security champions that we have, because we do have a security champion in each product team. But we have about 150 products. throughout different divisions. So it's very difficult to have a strong link between what the product security office needs and what the security champions know and understand, because each of those products might have a slightly different workflow. They're using slightly different tools. They have some different flavor of Agile or DevOps or— So what seems to, be a universal software security lifecycle isn't really. There's a lot of different flavors of it being enacted in different areas, and people start to tune out if they think one thing isn't relevant to them. They stop listening. Or if you're having open forums all the time like we were and you're getting 30 to 40 people just listening, but you have about 150 people who need to hear what you have to say, there's no way to rope that in. So my solution to it was let's have people who are matrix or satellite, as another term might be, to a federated model of a central product security office where we strengthen our links from setting the software security strategy for the organization, setting the policies, setting the standards, setting the processes, Choosing and approving the tools, maybe trying to design security features that get adopted and have a feedback loop between what the product security office is coming up with and what's actually getting down into teams and vice versa. If teams are coming up with great solutions, if teams are coming up with reusable code, if teams are coming up with observations about what's actually happening at that level that we don't have visibility into, whether that be technological or process, we needed some way to have a regular link, a tier of people who are all understanding the same initiatives, understanding the same structure of what the product security office needs to achieve, even in areas that might not necessarily seem like they need a full-time security person. Like, one of the areas that was very interesting was documentation development. Asked, do we really need a product security lead? And I was like, yes. Why do you— a lot of people discount, again, communication skills, but also security documentation and how just having someone who is focused on understanding how security works within the company and what the public face of that should look like and what the customer workflow might be of people who are trying to use that information has ended up becoming useful in so many ways that we didn't imagine when we first came up with the role. And that's not to say that there aren't challenges with it, because there definitely are. Because these people don't report to me, even though it was sort of me and my team's effort to set up onboarding sessions for them to teach them about, one, software security at my organization, two, software security as a discipline, and then trying to build that knowledge and foster both the understanding of the why and the understanding of the how to do various things, whether that be threat modeling, secure design, the different tools that we use throughout the lifecycle, the different skills that they needed to be fostering, and the things that only human eyeballs can pay attention to in application security. It's been, I think, a really rewarding experience. Well, definitely for me, but from the feedback I'm getting from them, they feel like they came from just different disciplines, whether that be test or quality engineering, development. We had a database engineer, I think. We have someone who used to be a director and obviously a technical writer, technical editor, and how these people are embracing the security discipline and growing as professionals. Because like you asked at the beginning of the episode, it's interesting to find out how people get into this discipline because everybody brings a unique perspective to it and everyone has—

**13:35 Chris Romeo:** Yeah.

**13:36 Brenna Leath:** Different skills, which is also great to see how these— we currently have 8, so how these 8 people who all have the same role, they all have to do it slightly differently because they're all in different divisions. So they need to understand the big picture of what my group is putting out, and they need to understand all of the core security practices that we need to do. But then they need to adapt. They need to take what they learn from us, and they need to help their security under— champions understand how it works for them. And sometimes that means customization, tailoring. Like, what we say is a standard. If we say the what, they have to figure out the how. If that makes sense. So we say you have to do this, but maybe this looks different in 10 different product teams depending on what's the product they're working on, what's the language they're writing on, what's the architecture they're using. It's very different, and it's impossible for a small central team to be able to give everyone that kind of unique and deep-seated guidance when all of them have a lot of product knowledge specific to their product. I read something the other day that was interesting about product security engineer or architect's attitude, which was know how to work with engineers who know a lot more about their code than you do. I was like, well, obviously, but to hear it put that bluntly was very funny. And that's why it's been cool to have a product security lead in each area because they can get that sort of homegrown knowledge and expertise within their area and have that close connection with their security champions that I wouldn't have. So if I say, oh my gosh, we need all security champions to go update their package YAML file and add this piece of information, how am I ever gonna— oh, okay, I'll just ask the product security leads if they can help. Make sure that message gets through because we were trying to rely on product and project management and that just wasn't quite getting there. Like they needed their own, I'm gonna call it ringleader, but gang. They needed their own gang in each area.

**16:08 Chris Romeo:** Yeah.

**16:09 Brenna Leath:** It is kind of a circus and it's kind of a gang, but. Team, sure. That's a good one.

**16:14 Chris Romeo:** Yeah. So you may— you use the word federated in regards to application security and in regards to the collection of people. Can you give me a definition? Help me understand how you're using that word federated. I've heard, obviously, you know, federated authentication and, you know—

**16:36 Brenna Leath:** Yeah, it's actually an interesting term. picked it up from the BSIM and I really ended up liking it because if you liken it to the federal government, a federated centralized setting standards, policies, strategy, direction, and then out from there you are reaching into the different areas. So there is kind of— Government's a dirty word, but to have like a federal sort of centralized security office, and then you have one tier down, which I guess you could call state government, which would be product security leads, and then down to like county government, which I guess would be the security champions. If you think about it like that link, that the way that the BSIMM put it was phases of Software Security Initiative, SSI, maturity. So the first phase being security as a cost center, the second phase being security as compliance, the third phase being security as tools, trying to automate and get to speed, and then the fourth phase, which not a lot of people are there, but security as enablers of sales, of the actual software maturity, and a driver of appeal itself. So I don't think a lot of companies are there. I don't think we're there. But I do think it was a very big step for us to first of all, have the executive support and buy-in to say, yes, you can have these full-time people to do with what you will. And they don't report to me. They're not in my cost center. As a matter of fact, they all report to different divisional heads who are higher ranking than me, but they matrix report to me. So that means they look to me for guidance. They look to me for help about what they should be working on or help prioritizing or what— how they should be communicating some of these security initiatives to translate them to what that actually means for what their divisions and their teams should be focusing on. So it's almost like—

**19:16 Chris Romeo:** Mm-hmm.

**19:16 Brenna Leath:** A ripple effect and an amplifier for what it is we need everyone to know, because a lot of people will say security is everyone's job, but that doesn't actually mean anything unless you can translate that into, okay, but what do they actually have to do?

**19:34 Chris Romeo:** Yeah, there has to be some, some action that they can take. So I'm curious now, when I think about this, this product security lead, and you said you've got 8 of them, and so you've got some experience with maybe a broader view of what they, what they are, what they can do. What are the 3— if you had, if you could only give us 3, what are the 3 kind of tendencies or characteristics of a successful product security lead? Because I'm imagining that a lot of people listening to this are just fascinated as I am, because maybe they haven't, they haven't thought about this as a way of approaching champions, they may be sitting here thinking, this is a really cool idea. How am I going to find those people? What am I looking for in those people? And I'm just curious if you've seen some qualities of those people where you're like, oh yes, a successful product security lead is someone who is A, B, and C.

**20:30 Brenna Leath:** So the first thing that I did when I was describing what I wanted this role and what I wanted this program to look like was start by describing what it is not. So I made a very distinct role that was not a project manager, not a developer, not a security champion, not a tester. And because I knew that that was gonna be the first issue with this was that they were gonna try to turn that person into one of these roles or think, oh, well now project managers don't have to look after their backlog because—

**21:08 Chris Romeo:** Right.

**21:08 Brenna Leath:** the security lead's gonna do it. Throw it over the fence to them. Or, now we don't have to worry about automating our SCA scans and grooming those results. Our product security lead is just gonna do all that for all the teams, so don't worry about that. Go back to your regular job of development. Don't be a security champion anymore. I was like, no, that is not what these people are for. And I have Over the time that we've had them, which really hasn't been that long. I think they got in place— shoot, maybe it's been about 8 months now. But throughout that time, I've had to do some further role definitions, and it changes sometimes because, again, each one of them is different. What their division does is different. So what they might be spending more time on could be different than someone else. So that's the first thing to do, define what that role should be and what it is not. For me, a product security lead is operating at a strategic level. Lead is a key word. They need to be leaders. They need to be good communicators. They need to not mind just diving in somewhere where maybe there might not be a process defined, or maybe there might be a problem that crops up and they should be looking to us for guidance on how to solve it and what the best way forward is, but they also can't be afraid to be recommending things back to us. So what's a good example? I would say, so I actually just recently came back from maternity leave. I had a baby and while I was gone, Log4j happened and I had gotten the product security leads in place and gotten them largely onboarded. They understood their role. They understood the initiative. They understood what to do. And they killed it. They did an amazing job during Log4j. They impressed everyone. And I was a little scared when I came back because I came back— I knew that it was happening while I was gone, but, you know, I can't log in. So I came back about 3 weeks after it happened, and I was blown away at how great a job that they did. triaging, doing incident response, doing follow-up, being very on top of the ball. Like, they are listening to the feeds, they're finding out about things before they really even get in the news, or definitely before customers do. And so they're looking into things, they're being proactive, they're understanding the designs of their products. So I'd say don't be afraid to learn. You need a person who is curious and who doesn't mind— security is a constant brain activity. You need to be learning, you need to be looking ahead, you need to be proactive, you need to be organized. I think, well, I think maybe only one of them has a P. A PMP, a project management background, but it is important to know how to prioritize, how to figure out what it is you should be working on versus maybe what people are telling you to do. And then think a little bit more critically, like, okay, but I could spend a lot of time on that, but am I attacking the symptom? Or is this actually going to further my true purpose, which is, you know, that like looking at automation or looking at all of the false positives that are coming from a tool, like which one is really going to help you more? You could be grooming false positives forever and ever and ever, or you could be working on tuning the queries, and which one is gonna net you like a better return, you know? So Having people who are able to do that sort of critical thought and having people who are not afraid to reach out into areas where maybe they don't know a lot or maybe they're not comfortable. Like, threat modeling is scary. It doesn't need to be, but a lot of people are scared of it. And so you need to have somebody who's like—

**25:40 Chris Romeo:** I mean, it has threat. I know it has threat in the title. You should be scared. like, this is a threat. We don't believe in that.

**25:48 Brenna Leath:** Scary.

**25:49 Chris Romeo:** We don't believe in scaring people with it. So, so I've got another question, Brenna, about the product security leads. And what I'm curious is, how much guidance do you give the product security leads about who the champions are that they go after? Or is— are you, are you kind of focusing on capturing who the entire security champion body is and declaring who that is and then handing those people to the leads? Or are they out there recruiting their own people and really running their own kind of mini programs?

**26:18 Brenna Leath:** The answer is all of the above. So we started with a list of security champions that we really weren't sure how accurate it was. Some people had probably left, some people had kind of been assigned amongst their teams. We had a static page that wasn't getting updated. So even though we try to keep it as data-driven as we can and try to keep that sort of information close to the source of the code, that's not necessarily reliable either if people aren't updating it because people always have to update it. So that was sort of step one when I asked the product security leads to come on board was, okay, do your inventory. Like, tell us who the champions are in your area. Are there— are you shorthanded? Do you need to recruit more? Do you you feel like the ones you have have a solid understanding and a grasp. Or is one person doing all the security work for a group of like 50 people, which ended up— that happened in a few places and it has become difficult. Like, you don't want a single point of failure anywhere, but definitely not somebody doing the security work on your team, because if they get a job somewhere else, all that stuff just drops, and then you have to figure out how to get somebody else up and running. So multiple people need to be doing security processes, whether that's reviewing findings or whether that's helping track remediations or whether that's, uh, doing some secure design work. Like, somebody said something interesting in one of the groups that the goal was to quote unquote kill security champions altogether. And then the lead who told me that was shocked. And I was like, actually, it's not really that shocking when you think about it. Because in the next era of security, it's like security is everyone's job. We'll all be security champions. Like, it won't be such a— in DevSecOps, it's not such a defined role.

**28:30 Chris Romeo:** Right.

**28:32 Brenna Leath:** you all sort of know what is going on. You're all interacting with the security of the product. You're all trained to do those basic threat modeling question sets of, what are we making? How can it go wrong? Did we do a good enough job? Like, you all know that. So there doesn't necessarily have to be a special set of people who are security people, which I think is a good goal to aspire to, but there's always going to have to be people whether it's the central team and product security leads who, it turned out they turned their entire organizations into security champions. Wow. But right now it is kind of like a little mini club for per division. They all— And I don't go, I can't go. I can't even have one-on-ones with all of them. I'd be doing nothing but having one-on-ones. So the way that I've tried to work it out is Okay, I set up all these onboarding sessions for them. It was about an hour a week, every week. And then I also have what I call open forum lunch when it's just come and pepper me with questions. So I just come show up and they ask me whatever they want. And so now that's kind of morphing and evolving into, all right, everyone, if you have something you want to demo or something you want to share with the group, let's do that. And then instead of having our onboarding sessions every week. Now we've transitioned to onboarding/presentation learn biweekly, but then the other biweekly is secure design board where everyone brings their secure design reviews or their threat models and we talk about that. I had— and then I'll just do ad hoc things sometimes just for team building. Like a couple of weeks ago I did A Fun Friday where I got the OWASP Cornucopia cards, and there's an online beta version of the game. So we all played the online beta version of the game, and somebody brought a recent data flow diagram that they were working on. And so we sort of learned about the game and poked some holes in that. So that was interesting. And I said, try this out with your security champions when you're trying to look for stuff to do. You know, maybe have lunches or kind of coffee meeting with them where you talk shop about what's interesting, what's working, what's not working, and just have that regular touchpoint with them. Because I can't meet with all 150 Security Champions. And even if I did open up a meeting, because we do have open forums where it is just the product security office and we say, all right, like, come ask us anything. And so a lot of times it ends up being questions about, like tools or maybe vulnerabilities or different methods or something that people want to share. And sometimes it's just me talking trash.

**31:23 Chris Romeo:** That's— there's a lot of, a lot of really cool things you've done in this program. And, you know, I'm somebody, like I said, who— and Robert is as well— we kind of study these things and, you know, put them under the microscope sometimes. But You know, just all— you're doing a lot of really cool things to just build security culture at the end of the day.

**31:43 Brenna Leath:** That's, that's the goal, to build the security culture. Like, when— and we did a lot of that last year too. We had an R&D-wide bug bash that leadership said, all right, everyone participate and you're gonna learn about ethical hacking today. And we had everybody try to learn how to use Burp Suite, and that was crazy because it was like all whatever, 2,500 people who were supposed to be participating and did them all in teams and stuff, but they ended up doing a great job.

**32:13 Chris Romeo:** Yeah. Wow. Well, Brenna, thank you so much for sharing your expertise here and, and your experiences with us on this topic of product security leads and product security champions. And we'll have you come back to talk about—

**32:27 Brenna Leath:** I was gonna say, I prepared a whole topic that we didn't even get into today.

**32:31 Chris Romeo:** So we'll do that in a second. Oh yeah, we'll do a second episode to talk about that.

**32:36 Brenna Leath:** So, all right. Well, hey, I'm here. I'm here. You know where to find me.

**32:39** 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/brenna-leath-product-security-leads-a-different-way-of-approaching-security-champions/