Sustainable Security with OWASP ASVS

"Start securely—without upsetting people."
That’s the essence of Josh Grossman's talk at NDC Security, where he outlined how to turn the massive OWASP Application Security Verification Standard (ASVS) into a practical, repeatable, and developer-friendly security requirements engine.

In a world where "shift left" and "secure by design" are buzzwords, Grossman’s session brought something developers and AppSec teams actually need: a way to operationalise ASVS in the earliest phases of software development without overwhelming everyone involved.

Drive Enforcement Throughout the SDLC

Here’s how to integrate your custom ASVS into the dev lifecycle:

SDLC Phase	ASVS Mapping Strategy
Requirements	Feature-level mapping to ASVS controls via questionnaire
Design	Run contextual threat modeling against mapped controls
Development	Provide “how to” guidance for each ASVS requirement (e.g., password hashing libraries, header settings)
Testing	Use ASVS numbers to build checklists, static/dynamic test cases
Deployment	Add final checks for deferred items in the Security Backlog
Post-release	Track compliance and improvement using the ASVS mapping as baselineThe Problem: Checklists, Chaos, and Burnout

A large organization attempted to roll out a 50-page secure development lifecycle (SDLC) policy—complete with a monstrous checklist—for every product team.

Predictably, no one used it.

The effort failed not because developers didn’t care about security, but because:

The security requirements were not contextual to their features.
Too much was expected too early, and
There was no sustainable process for updating or maintaining the effort.

Solution: Four Key Strategies to Make ASVS Work

1. Information Overload: Customise the ASVS

ASVS has around 300 requirements. Expecting teams to apply all of them to every feature is unrealistic.

Instead:

Fork the ASVS and tailor it to your organisation.
Remove irrelevant sections (e.g., skip GraphQL items if you're not using it).
Build a lightweight questionnaire: Developers answer a few yes/no questions about a new feature, and the system returns only the applicable ASVS requirements.

Tip: Always document why a requirement is dropped—don’t silently trim.

2. Security as an External Force → Contextualise Security

Security is often seen as a team that “drops in,” runs some scans, throws out some advice, and disappears.

Treat security as a quality attribute, just like functionality, performance, reliability, or usability.

Use threat modelling to ask:

“What could go wrong here?”
“What would make our business sad?”

It is a structured process to identify, assess, and address potential security threats to a system before they become real issues. It helps you understand:

What could go wrong (threats)
Where it could happen (attack surfaces)
How an attacker might exploit vulnerabilities
What to do to mitigate or prevent those risks

This aligns security with business risk, not just compliance.

3. If Everything Is Important, Nothing Is Important → Prioritise Thoughtfully

Once you know which ASVS controls are relevant, you still need to prioritize.

Use these filters:

Business impact: What risk does this feature introduce?
Effort vs. value: Is this a quick win or a long-term investment?
Developer fatigue: Balance tougher controls with easier ones to maintain morale.

Maintain a Security Backlog to track deferred items—set timelines (e.g., "next release" or "in 6 months") to avoid “infinite backlog syndrome.”

4. Point-in-Time Solutions Don't Scale → Operationalise and Reuse

The final pillar: make security requirements and solutions reusable.

Create a centralised repository where developers can:

Look up how your org stores passwords
Find the right output encoding for HTML/JS
Know what HTTP headers to include
Understand how to securely use an external auth provider (e.g., Auth0)

Each requirement from ASVS should link to how your team solves it in your environment. Think: curated playbooks, not just static policies.

Developers vastly outnumber AppSec pros. Scaling knowledge means documenting solutions.

Summary: Make ASVS Actionable, Contextual, and Sustainable

Problem	Solution
ASVS is too big	Customize and reduce scope
Security feels like a burden	Integrate it as a quality attribute
Too many priorities	Use threat modeling to focus
Inconsistent fixes	Centralize and reuse implementation guidance

Final Thoughts

The OWASP ASVS is a powerful tool—but only if used strategically. Josh Grossman’s approach turns it from an academic list into a living system for secure development.

Start small. Ask the right questions. Link requirements to business risk. And above all, give developers what they need to build secure systems without friction.

Security should not be the enemy of velocity. With the right system, it can be a multiplier.

Building Sustainable Security Requirements with OWASP ASVS