The Application Security Podcast is a practitioner-led show for anyone building or securing modern software—and now AI-powered applications. Hosts Chris Romeo and Robert Hurlbut talk with the people shaping application security about AI and LLM security, threat modeling, secure development, OWASP, cloud, DevSecOps, security champions, and building programs that help engineering teams move faster and safer. With more than 300 episodes, the show turns real-world experience into practical guidance for developers, architects, AppSec professionals, and security leaders.
Farshad Abasi -- Three Models for Deploying AppSec Resources
•Chris Romeo
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
0:00
|
9:18
Application security teams rarely have enough specialists to embed one expert with every development team. Farshad Abasi joins Chris for a focused comparison of three staffing models he used while building enterprise AppSec programs: expert-led support, a federated risk-based model, and a security champion or deputy model. Farshad explains why dedicated experts struggle to scale, how application tiering concentrates attention on the systems that matter most, and how champions can take ownership of routine security work with coaching and escalation from AppSec. The episode offers a practical progression for organizations trying to expand coverage without pretending scarce specialists can attend every stand-up and review every user story.
The Application Security Podcast is brought to you by Security Journey.
About Security Journey Security Journey provides application security education for developers and everyone in the software development lifecycle. → Learn more about Security Journey
Chapters: 00:00 Three models for deploying AppSec resources 01:21 Farshad Abasi’s path from development to security 03:28 The expert-led AppSec model 05:45 A federated, risk-based model 07:31 The security champion or deputy model 08:41 Choosing a model that can scale
This episode is different than our typical interview approach to application security. I've been creating the Threat Modeling Podcast using a narrative, storytelling technique, and this episode is the result of a piece of a conversation that didn't precisely fit with threat modeling, but was too good not to publish. In discussing developer or software focused threat modeling with Farshad Abazi, he described three models for deploying application security teams: expert led, federated, and champion deputy. Enjoy an excerpt from our conversation where Farshad describes each model deeply.
Pillar Ad
Coding more securely from the start saves your organization time and money while protecting your and your customer's data. Security journey provides hands-on secure coding training in an application sandbox that allows developers to identify, break and fix common security vulnerabilities. Give your developers the opportunity to recognize and prevent common and emerging security issues before they become a problem. Visit security journey.com to try our training today.
you can just, tell me your name and then just gimme a bio, kind of walk me through your, history.
Farshad Abasi
Hey, Farshad Abasi, hailing from Vancouver, British Columbia up here in Canada. Um, I started as a software engineer. Um, you know, went, did the ComSci thing, went built software, started building, you know, web applications back in the.com era. You know, it was literally full stack. I ended up working for Motorola where it's just like you're writing, you're truly just an engineer writing a piece of code. And then, you know, went to, did a startup in the dot-com era. We had our own company building, what today would've been Netflix, um, you know, learned about distributive systems. In fact, that was my first foray into threat modeling. We're like, Hey, we're we should get someone to do a security audit. You know, I've never, this was a new thing to me. So we hired these guys from, from the states. And they, they did design reviews and threat modeling. So that was my first introduction to that type of a thing. And it was kind of neat as a developer. I sat on the, you know, we had a bunch of workshops with them. They asked us questions. I was completely like oblivious to what was going on. Funny enough, 20 years later, that's what I do now. I go to developers, Hey, show me your design document. Show me the architecture list, thra model this together. I find the attack pathways. Now it all starting to make sense. So when I think back, I think of the developers that are in my shoes. The startup didn't work, you know, dotcom blew up and, you know, I ended up, uh, going back to the corporate, worked at Intel for a while, wrote. Drivers there, again, as a software engineer, worked on a bunch of security related things. So again, learn, learned a lot about looking things at from a security perspective and building security into products. And then, you know, fast forward to 2008. So buddies having lunch with me said, Hey, you're a developer, but you know, you know security. And at that point I'd been teaching network security at local college, you know, just on the side. And he said, have you ever considered come and work for HSBC? They were pretty forward thinking that they decided that software security was really important and they would create an AppSec team within the software development organization, although they already had risk, they already had IT security that this team would be special. This team would work directly with developers and help integrate security at all the different stages of security development lifecycle. Um, applied for the job, got the job and you know, it was one of the original people that formed that team. So we ended up forming a global AppSec team. And, you know, the program was fantastic. It was really ahead of his time.
When approaching application security in a large organization, there are multiple models that we see organizations use. The first one is the dedicated AppSec person model.
Farshad Abasi
They had too many projects and they were trying to assign an AppSec person to work with each of these teams. And at the time, these were waterfall teams, right? So we said, decided let's take the flag teams that are building flagship applications and let's work with their developers. And one of my first tasks was that hey, you know, divide and conquer. Each of you, there's like, you know, 20 teams. So we ended up trying to figure out what is the best way, uh, to, to have developers do that threat modeling, right? So they signed each of us to a number of dev teams and they're like, Hey, Go and work with them closely do it so that they learn. But you know, of course they don't wanna learn. They're like, oh, you're here. You do it for us. You're the security guy. Right? So it was this challenge of like, how do you, some teams I saw after about a year, I saw that that change, they were like, they were coming to me, they were identifying the issues. They were able to actually look at it from that perspective. Um, you know, and then of course the world changed from waterfall to Agile that it was like, oh, now we have a new challenge. Because before thread modeling was a bit easier. You would get the full design finished and you had the whole architecture document complete, and you could thread model that. But then when we went to Agile, they're like, oh, now you're getting bits and pieces of the information you have to do, you know, threat modeling for agile teams. So then they, you know, they took me and a couple of people that said, Hey, Faria, you go figure this out. Like you, you know, we don't know how to do this. No one's done this yet. So we were all security professionals. The, the developers had no idea how to do so. Initially we were doing it for them. So the how it worked is that, Engagement management. We would receive a new project. They're like, Hey, here's a new team building this project. They don't know anything. They're building it. We would do the threat modeling. We would come up with the threat scenarios. We would give it to them. As we went into that agile and DevOps world, then they wanted us to attend their standups and be a part of the team. So then they were like, okay, you know what? Before you were just, you know, you were part of the develop the waterfall model, it was a bit better. Like you weren't an outsider. At least you're part of the developments team. But you come in at a certain phase, you do the work, you are, you produce the output. But then that doesn't scale because you know, we have so many projects and you know, we can't be, like, the conclusion we came to was like, we can't be doing that for every project. Plus it's not very agile. So as they went into Agile, it was like, well, what do we do there? You know, at first they were like, well, You know, you guys gotta cover every team. We're like, well, there's hundreds of teams. We, you know, I have a small amount of security professionals, so what do we do?
second approach to AppSec in larger organizations is to rate all the applications and then focus on the ones with the highest security criticality. Sometimes called the federated model. AppSec team members work on the highest priority applications and lower tier applications. Run through an automated pipeline without any personal attention.
Farshad Abasi
We can tier our applications into like tier one, two, and three. So the really important ones, that's the ones we assigned the AppSec consultants. For the ones that are like not so important, we just scan them. We don't do much for those. And for the middle ones, we decide based on a case by case basis. Even then we didn't have enough AppSec consultants, even for the tier ones. We had, you know, I think in total in North America we had about 20 globally. We had a bunch of AppSec people in the low cost centers, but they weren't able to do that design review that, that, that types of AppSec. That requires a higher level of expertise. So then what we did is, We said, we, we said, you know, it's not necessary for, you know, one, one of my team members to go to every standup every morning to go to all the sprint planning sessions and really be a part of the team. Why don't we scale it back instead of a sec? Uh, my security AppSec consultant going in. They'll go in every day. Instead, they'll go once a week. So we would have a security weekly standup, and then instead of going to the sprint planning and being there for four hours, why don't they give us a list of backlogs in that, the user stories in the backlog, and then we can run through, we create created a checklist. So you know, that would determine. Very quickly, if any of those user stories had anything that could be security sensitive or matter from a security perspective. So by using that filter, we would reduce the number of user stories we had to look at. So we reduced the amount of the allocation are required to about 10 to 20% of a of a, of a AppSec consultant. Right? But even that doesn't scale super well. Even if you reduce, you know, at one consultant can handle, let's say, Four, three to five clients at most. Three to five different teams.
third model is the champion or deputy model where the AppSec team deputizes developers to do the bulk of the application security work, and the AppSec team becomes a resource and escalation point for more complex problems.
Farshad Abasi
We just took each DevOps team, they pointed a security champion, and then we had these working group forums where the champions would come in, um, and then we would assign an AppSec person to run that working group with all the champions to. Disseminate the knowledge to support them so that the champion could be there on the ground, deal with the day-to-day issues, that they come up from the security team and do that threat modeling and be there, and then we, you know, train them. And then we would also set up these weekly sessions where we would work at a mentorship capacity, where they would bring that filtered list of user stories, not all of them. And then we would. Initially we would threat model it, but the expectation that they're gonna learn. And then we would turn the tables around. Usually after three to six months, they'd be like, okay, now we're gonna stop doing it. Now we're gonna watch you do it. And with some of the teams, we would see them doing it really well. You know, they just jump in there, they're identifying the threat scenarios and I would just have a big smile on my face. It's like, this is actually working. Some teams it took longer and they were, you know, more difficult to turn the tables around and get them to have that conversation.
case, the expert led, federated and deputy approaches were a progression. He started with expert led and progressed to a fully-deputized, champion-driven approach to AppSec over several years. No matter where you are on your application security journey, find the suitable model that works for your organization. My conclusion is the fully deputized model is the only path to scalability.
