After working with over 300 companies on their application security programs the most common question I receive is “what’s next?”. They want to know how to mature their programs, and when they look at the maturity models available, they find them intimidating and so far beyond their current maturity level that they feel impossible. In this talk I will take you through 3 common AppSec program maturity levels I have encountered over the years, with practical and actionable next steps you could take immediately to improve your security posture.
Outline:
• Intro to myself, the format of this talk, and how I conducted this research (by working with over 300 companies over 5 years of working with IANs research. Meeting with 1-5 companies per week). All of the companies are considered enterprise, so this talk will focus on enterprise, not SMB.
• Explain to the audience, gently, that the current maturity models available (OWASP SAMM, BSIMM and NIST) scare the pants off of most clients, and seem utterly impossible. It’s not that the maturity frameworks are bad, it’s that they are too “pie in the sky” compared to where more organizations currently are. I *WISH* our industry could be at that level. We are not.
• Model 1: we just PenTest the important app(s) once a year, little to no governance
This is, unfortunately, extremely common. Even in 2024 I am working with enterprises that have ZERO AppSec programs, starting from scratch. That said, we all need to start somewhere, and if they are meeting with me (or another AppSec consultant) then they are serious!
Often no formal SDLC at all
Often very mixed tech stack
Often code is located in several places, everyone doing their own thing Why this model is bad: it’s quite expensive for what you are getting
(pentesting as your only AppSec is $$$$), terrible coverage, developers do not feel supported, there’s no opportunity for them to learn, etc.
How to mature this model, *realistic* next steps:
Secure Coding training, followed up with quarterly lunch and learn style events to teach them about whatever the most pressing issue is for the AppSec team (lesson on a common vulnerability, incident issues, whatever)
If little-to-no-budget:
use a free tool like Zap or Burp for DAST (in a sandbox), and Semgrep OSS
try to identify one or more devs who might be willing to do some security work, and assign the tools to them
Get a secure coding guideline and try to get the developers to follow it, even a super basic one
Create a list of security requirements for all new web app and API projects, try to get projects to use it
Try to get all your code into the same place, set SAST against your code repo, try not to cry after your first scan
Talk to head of developers about plans for IT modernization, you all want a real SDLC, you all want project management, you all want centralization
and standardization.
Threat model your super important app(s) then socialize the results with
the developers. So they understand the threats to your org and your mission. This will raise awareness a lot.
Share information on past incidents, if appropriate, so the devs understand where you are coming from
Scan your codebase for secrets, rotate them and start checking them in somewhere that is not your code base
Put a WAF in front of any app that is *terrible*
You still PenTest the important apps, but now sometimes you pass the tests.
If budget, add this:
hire a full time AppSec person as #1 step - best possible spend
buy a paid second generation SAST (no one will tolerate tons of false
positives at this point), still use free/almost-free DAST
• Model 2: SAST + DAST and perhaps one other tool, some governance
This is the most common AppSec program I see at Enterprises.
They pay a lot of money for 2-3 tools, and have partially rolled them out. They send lots of bug reports, few things get fixed. “Why won’t the developers just fix things?”
Little-to-no documentation, little-to-no interaction with developer teams, may have done a failed champs program
There is an AppSec program with 1 or 2 people, but it’s not consistent or well directed, always responding to fires
Why this model is bad: coverage is bad. Not much is fixed. We’re not here to find lots of vulns and make reports, we are here to reduce organizational risk, and these programs usually make only a tiny dent. They also tend to cause friction.
How to mature this model, *realistic* next steps:
Do all the stuff from the previous Maturity model.
You will likely need additional AppSec resources for this, ensure they are
not all just PenTesters who used to be sysadmins, you need to have at least one resource with lots of coding experience in their background that understands the developer brain and processes
Assess whether your tools are working for you and your devs. If you’ve had your SAST and DAST for 2+ years and they are not adopted or completely rolled out, WHY NOT? Likely you have the wrong toolset. Time to upgrade/modernize
Ideally you would have tooling that looks at your running apps (and APIs), your written code, and third party code. This can be anywhere from 2 tools to 5, depending on how thorough you want to be. Focus on getting as many true positives as possible, and try to add as much auto-triage as you can, so you show developers the lowest possible number of things to fix. Examples: validate your secret findings, only show reachable third party code vulns, use AI to tr
