If you've ever received security findings report and felt like it arrived from a different planet, written in a language that doesn't map to your sprint, your backlog, or your actual codebase, this is for me trying to understand why that keeps happening from the other side of the fence.
I want to be careful with this one because I have a lot of respect for the work that goes into OWASP standards. The people who maintain ASVS and SAMM are doing genuinely important work. This isn't a criticism of the standards themselves.
It's a criticism of the gap between what these standards are and how they land inside real engineering organisations.
ASVS 5.0 is comprehensive. It covers authentication, session management, access control, cryptography, error handling, data protection — essentially every dimension of application security that matters. If you built software that genuinely satisfied every applicable ASVS requirement, you'd have something worth being confident in.
But here's what I've watched happen repeatedly.
An AppSec team — often one or two people covering multiple product teams — decides to adopt ASVS as their verification standard. They map requirements to their tech stack. They build a spreadsheet or use one of the available tooling integrations. They present it to engineering leadership. Leadership nods. An engineer is designated as the point of contact.
And then nothing changes about how software gets built.
The requirements live in a document. Tickets don't reference them. Pull requests don't mention them. Sprint planning doesn't include them. The ASVS spreadsheet gets updated periodically, usually before an audit or a customer security questionnaire, by someone who wasn't in the room when the code was written.
This isn't a failure of intention. The engineers I've worked with are not cavalier about security. The problem is structural. ASVS is a verification framework — it tells you what properties your software should have. It doesn't tell you how to build those properties into a team's daily workflow in a way that competes with feature pressure, sprint velocity, and the twelve other priorities an engineering team is managing.
SAMM has the same problem from a different angle. It's an excellent maturity model for understanding where an organisation sits across security practices. But maturity models describe states, not transitions. Getting from SAMM level 1 to level 2 in secure build practices isn't a matter of understanding what level 2 looks like — it's a matter of changing how dozens of engineers make decisions under pressure, every day, without a dedicated security person in the room.
The dirty secret of AppSec programme work is that the standards are the easy part. The hard part is the last mile — the distance between a well-designed framework and the moment an engineer decides whether to add input validation before pushing to main.
I've been thinking about where that last mile actually breaks down. Whether it's a tooling problem, a process problem, a communication problem, or something else entirely. I don't think I have it figured out.
If you've worked on AppSec programme adoption — from either the security side or the engineering side — I'd genuinely like to hear where you've seen it work and where it falls apart. The comments are open.
Photo by Andrew Bright on Unsplash
Top comments (0)