Last Updated on April 8, 2020
Version 4.0 of the Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS) introduces many significant changes, including streamlining and restructuring the security verification levels.
In this post, I’ll quickly cover what’s new and different in the ASVS 4.0 as it regards to the levels specifically.
First of all, Level 0 has been eliminated. Level 1 is now the base testing level and covers the minimum controls for best-practice application security. Level 1 also now focuses even more on addressing the OWASP Top 10 vulnerabilities, which in previous versions were mostly covered by levels 0A (automated tool scan only) and 0B (basic penetration testing).
It is now possible to cover Level 1 almost completely with a black box penetration test, without needing to access the application’s documentation or source code and without interviewing developers. However, the new ASVS strongly states in its Preface that Level 1 is only sufficient to protect against opportunistic attacks:
Over the last 30+ years, black box testing has proven over and over again to miss critical security issues that led directly to ever more massive breaches. We strongly encourage the use of a wide range of security assurance and verification, including replacing penetration tests with source code led (hybrid) penetration tests at Level 1, with full access to developers and documentation throughout the development process.
For threat models that include targeted attacks or more sophisticated attackers, OWASP strongly recommends adopting Level 2 controls. Level 2 is now “the recommended level for most apps” or for any apps that “contain sensitive data.” In short, Level 2 is where the risk-based, best-practice methodology really begins with ASVS 4.0.
With these changes the ASVS is moving decisively away from retroactively probing for vulnerabilities and underscoring the need to proactively address security within the development process.
Even at Level 1, the ASVS provides significantly more validation as to the security of the application than does the OWASP Top 10 vulnerabilities.
“Level 2 controls are designed to thwart targeted, determined attacks…”
Leveraging the Top 10 remains good practice, but this doesn’t help developers create a secure application. Further, even addressing the current Top 10 vulnerabilities can leave an application very far from secure.
The ASVS 4.0 states: An application achieves ASVS Level 1 if it adequately defends against application security vulnerabilities that are easy to discover and included in the OWASP Top 10 and other similar checklists. Level 1 is the bare minimum that all applications should strive for.
If your organization is interested in “testing the waters” with the ASVS, Level 1 is still a great starting point. It can be cost-effectively leveraged and offers more protection and security insight than the OWASP Top 10 alone.
But to go beyond “the bare minimum” in terms of validation, you need to move to ASVS Level 2. The standard states: “An application achieves ASVS Level 2 (or Standard) if it adequately defends against most of the risks associated with software today.”
Level 2 controls are designed to thwart targeted, determined attacks—the kind that would almost certainly be mounted against any application that processes higher-value data like personally identifiable information (PII), healthcare records or financial data.