The release candidate of ASVS 5.0 was announced on April 9, 2025. You have a limited opportunity to influence what becomes the benchmark for application security verification. Elar Lang will present the final version at OWASP Global AppSec EU Barcelona, so your feedback window is closing soon.
Many security engineers view standards as unchangeable, but engaging with ASVS now can shape how you write security requirements, how auditors test your applications, and how you justify security investments. If a requirement in 5.0 is ambiguous or impractical, you'll be dealing with its consequences for years.
This checklist provides a structured approach to reviewing ASVS 5.0 RC1 and submitting feedback that can improve the standard.
Purpose of This Checklist
Use this checklist to:
- Determine if ASVS 5.0 requirements align with your current security controls
- Identify gaps or ambiguities before they are finalized
- Prepare actionable feedback for OWASP
- Develop internal documentation to align your program with the updated standard
This is not a casual read-through. Allocate 4-6 hours for a thorough review, and involve at least one developer and one security tester from your team.
Prerequisites
Before starting:
- Download the ASVS 5.0 RC1 document from the OWASP GitHub repository
- Access your current application security testing procedures
- Gather documentation of your existing security controls (authentication flows, session management, API security policies)
- Set up a GitHub account if you plan to submit formal feedback
- Schedule time with a senior developer familiar with your authentication and authorization implementation
The Review Checklist
Phase 1: Mapping Exercise (90 minutes)
For each ASVS category you currently test against:
- List the 4.0.3 requirements you currently verify
- Find the equivalent 5.0 requirement (note: numbering has changed)
- Document any requirements that were split, merged, or removed
- Flag requirements where the verification guidance changed significantly
Red flags to watch for:
- Requirements that assume tooling you don't have
- Verification steps requiring source code access (problematic for third-party app assessments)
- Language open to multiple interpretations ("should" vs "must", "sensitive" without definition)
Phase 2: Implementation Reality Check (120 minutes)
Select three categories most relevant to your applications. For each requirement in those categories:
- Can you verify this with your current testing tools?
- If no: What would you need? (Tool, access, expertise)
- Is the requirement testable as written, or does it require judgment calls?
- Does the requirement conflict with your development framework's default behavior?
- Would meeting this requirement break existing functionality?
Document specific scenarios where requirements don't work:
Example: "Requirement X.Y.Z requires session tokens to rotate on privilege escalation. Our mobile app maintains a single session across role changes to prevent user disruption. The requirement should specify web applications or provide mobile-specific guidance."
Phase 3: Language Audit (60 minutes)
Security standards fail when they're ambiguous. Review requirements for:
- Undefined terms (What counts as "sensitive data" in your context?)
- Passive voice that obscures responsibility ("must be validated" by whom—client or server?)
- Absolute requirements that don't account for risk-based decisions
- Requirements that describe what NOT to do without explaining the correct approach
- Verification guidance that doesn't match the requirement's intent
Mark each issue with:
- Requirement number
- Problematic phrase
- Your suggested replacement
- Why it matters (include a real scenario if possible)
Phase 4: Gap Analysis (90 minutes)
- What threats from your threat model aren't covered?
- Are there new attack patterns (supply chain, AI/ML security) that need requirements?
- Do the requirements address modern architectures? (Serverless, containers, service mesh)
- Are there requirements that no longer reflect current threats?
Consider your last three security incidents or penetration test findings. Would ASVS 5.0 have caught them?
Customizing This Checklist
If you're in a regulated industry: Add a compliance mapping phase. For each ASVS requirement, note which regulatory control it satisfies (e.g., PCI DSS v4.0.1 Requirement 6.4.3, SOC 2 Type II CC6.1). This creates reusable documentation.
If you primarily assess third-party applications: Focus your Phase 2 review on requirements needing vendor attestation vs. independent verification. Flag requirements that vendors can't realistically demonstrate without exposing intellectual property.
If you're building a new security program: Use Phase 1 to identify which ASVS levels (L1, L2, L3) map to your application risk tiers. Document your rationale for explaining to developers why different apps have different requirements.
If you manage a security testing team: Add a tooling assessment: For each requirement, list which tools in your stack can verify it. Identify gaps where you'd need new capabilities.
Submitting Effective Feedback
File issues on the OWASP ASVS GitHub repository. Structure each issue as:
Title: [Category X.Y] Brief description of the problem
Body:
- Current requirement text (quote exactly)
- The problem (be specific about why it doesn't work)
- Suggested fix (provide exact replacement language)
- Impact (who this affects and how)
Example of weak feedback: "Requirement 2.3.1 is confusing."
Example of strong feedback: "Requirement 2.3.1 states 'Verify that passwords are stored using an approved hash function.' The term 'approved' is undefined. Suggest: 'Verify that passwords are hashed using Argon2id, scrypt, bcrypt, or PBKDF2 with parameters meeting current OWASP guidance.' This removes ambiguity for auditors and developers."
Validation Steps
After completing your review:
- You've identified at least 5 specific requirements that need clarification for your use case
- You've documented how ASVS 5.0 changes affect your current security testing process
- You've submitted feedback on GitHub or documented why you chose not to
- You've briefed your team on changes that will impact upcoming development sprints
- You've created a transition plan showing when you'll adopt 5.0 requirements
The final version of ASVS 5.0 will define application security verification for the next several years. The gap between "theoretically secure" and "practically implementable" only closes when practitioners like you push back on requirements that don't work in real environments.
Your feedback now prevents your team from fighting unclear requirements later.
