OWASP Application Security Verification Standard (ASVS)

Best Practice: OWASP Application Security Verification Standard (ASVS)

The OWASP Application Security Verification Standard (ASVS) is an open list of security requirements for web applications and services. It turns vague goals like "build it securely" into specific, testable controls organized by topic, such as authentication, session management, access control, and input validation. ASVS defines three verification levels, from Level 1 (basic, mostly automated checks) to Level 3 (advanced, for high-value applications). It matters because it gives teams a shared, measurable definition of "secure enough" that both engineers and auditors can agree on. For a new developer, ASVS reads as a concrete to-do list; for an executive, it provides a defensible answer to "how do we know our software is secure?" The trade-off is effort: higher levels demand more manual review, so the chosen level should track real risk rather than ambition. In practice, teams treat the standard as a backlog source: each applicable requirement becomes a ticket with an owner, a test, and recorded evidence, so security work is planned and measured rather than improvised. This also makes onboarding easier, because a new engineer can read the relevant chapter and immediately understand what "done" means for security on that feature.

Step-by-Step Implementation Guidance

1. Choose a target ASVS level (1, 2, or 3) based on the data sensitivity and risk of the application.
2. Map the relevant ASVS requirement chapters to your application's components and architecture.
3. Convert applicable requirements into tracked acceptance criteria or test cases in your backlog.
4. Automate the checks you can (for example input validation and security headers) in CI.
5. Schedule manual verification for requirements automation cannot cover, such as access control logic.
6. Record evidence for each verified requirement so audits and re-tests are repeatable.
7. Re-verify after each significant change and update the level as the application's risk profile grows.

Common Mistakes Teams Make When Ignoring This Practice

• Treating security as a single penetration test at the end instead of continuous, requirement-driven verification.
• Picking Level 3 for every system, creating unsustainable overhead and abandoned controls.
• Verifying requirements once and never re-testing after code changes.
• Failing to record evidence, so the same checks must be redone from scratch each audit.
• Skipping access control and business logic requirements because they cannot be fully automated.
• Treating ASVS as documentation to file away rather than living acceptance criteria the team tests against.

Tools and Techniques That Support This Practice

• OWASP ZAP and Burp Suite for dynamic testing against ASVS requirements.
• Semgrep, SonarQube, and CodeQL for static checks mapped to ASVS controls.
• OWASP Dependency-Check and dependency scanners for component risks.
• Threat modeling (for example STRIDE) to prioritize which requirements matter most.
• Issue trackers and test frameworks to turn requirements into verifiable acceptance criteria.
• Coverage dashboards that show which ASVS requirements are verified, partially met, or untested.

How This Practice Applies to Different Migration Types

• Cloud Migration: Re-verify authentication, session, and access control requirements once components move behind new gateways and identity providers.
• Database Migration: Apply data protection and input validation requirements to new connection paths, query layers, and encryption settings.
• SaaS Migration: Use ASVS as a checklist when assessing a vendor's security posture and integration points.
• Codebase Migration: Re-run static and dynamic verification on rewritten modules to confirm controls survived the port.

Checklist

• Selected an ASVS level appropriate to application risk
• Mapped relevant ASVS chapters to application components
• Converted requirements into tracked, testable acceptance criteria
• Automated verifiable checks in CI
• Scheduled manual verification for non-automatable controls
• Stored verification evidence for audit
• Defined a re-verification trigger for significant changes