Use OWASP ASVS requirement IDs as testable software acceptance criteria

Bottom line: convert “the application must be secure” into a reviewed set of versioned, testable requirements. OWASP ASVS can supply a common requirement vocabulary, but the application owner still must choose scope, rigor, evidence, exceptions, and release consequences.

Source fact: what OWASP ASVS provides

The OWASP Application Security Verification Standard project describes ASVS as a basis for testing web-application technical security controls and a list of secure-development requirements. OWASP identifies three uses: a metric for application owners and developers, guidance for control developers, and a basis for specifying verification requirements in procurement.

On the August 25, 2026 review date, the project page identified ASVS 5.0.0 as the latest stable version. OWASP advises including the ASVS version with a requirement identifier because identifiers can change between versions.

What the source does not establish

ASVS does not certify an application automatically and does not guarantee the absence of vulnerabilities. Selecting every requirement without architecture and risk analysis can produce irrelevant work while missing system-specific abuse cases. A tool’s “ASVS coverage” label does not prove correct testing or complete coverage.

The standard focuses on application technical controls. Hosting, cloud configuration, identity providers, endpoints, networks, operations, privacy, business logic, supplier services, and incident readiness can require additional evidence.

Applicability questions

• Which exact ASVS version and application release are in scope?
• What architecture, data, users, administrative functions, trust boundaries, and consequences determine the required rigor?
• Which requirements apply, which do not, and who approves that decision?
• What manual, automated, code, configuration, or runtime method will verify each selected requirement?
• What result blocks acceptance, who may approve a bounded exception, and when will it be retested?

DSE recommendation: create a versioned verification matrix

The following steps are DSE recommendations based on the cited source.

1. Record the ASVS version, application version, architecture, scope, intended uses, data classes, roles, trust boundaries, and risk rationale.
2. Select applicable requirements with their full versioned identifiers. Preserve the source list and record additions, exclusions, interpretations, and owner approval.
3. Assign one or more verification methods, required depth, test environment, evidence artifact, responsible tester, and acceptance threshold to each requirement.
4. Tie findings to the requirement, vulnerable component and version, proof, risk decision, remediation owner, due date, and retest result.
5. Write procurement language that requests specific versioned requirements and evidence. Avoid an undefined “ASVS compliant” statement.
6. Review the mapping after application, framework, identity, hosting, integration, or ASVS version changes.

Verification and evidence

Sample selected requirements across different ASVS areas and reproduce the conclusion using retained test steps, configuration or code reference, output, environment, identity, and application version. Confirm that exclusions and exceptions have current rationale and accountable approval.

Official references

• OWASP Application Security Verification Standard project — OWASP Foundation; living project page and stable-version register
• OWASP ASVS releases and machine-readable requirements — official OWASP project repository