Well beyond the OWASP Top 10: the OWASP Application Security Verification Standard
Reasons why the Top 10 does not suffice to verify applications' security and to adopt ASVS instead.
If I had to tell what the #1 tool is that I have most frequently recommended to people and companies dealing with software security, OWASP ASVS would be that one. It is as easy as effective in producing results and changing the perspective through which the security of applications is verified.
The OWASP Application Security Verification Standard is, as the name says, a framework that enables the thorough verification of the security of an application. Still too often (indeed very often), security verifications are reduced to launching at test time (or directly in production environments) some kind of scanning tool and looking for vulnerabilities that may open the door to attacks in the OWASP Top 10, taking also advantage of the fact that many tools directly map their alerts on the Top 10. While being better than nothing, this approach is not the one OWASP has thought while providing the Top 10. The OWASP Top 10 serves as a foundational guide for developers in understanding web application security. It consolidates the collective insights on the most pressing security threats to web applications. Implementing the recommendations from the OWASP Top 10 can be a very good first move, paving the way for an organizational shift that emphasizes the creation of safer software. However, limitations of this approach will arise soon since the OWASP Top 10 doesn't provide any methodology to address systematically the problems.
The ASVS provides such a methodology and enables the set of security standards for an application. Standards which can be verified and ensured during all the stages of an application lifecycle. Let’s then go through the limitations of the Top 10 and thereinafter dive into ASVS.
Why is the OWASP Top 10 not enough?
Before entering into details of ASVS, let's for a while dive into reasons why the OWASP Top 10, being still a valuable starting point for understanding the most common and impactful security risks to web applications, can't be adopted as a verification standard.
First, the OWASP Top 10 is not exhaustive. Being (partially) built on data organizations of different kinds have collected about web application vulnerabilities found in various processes, it focuses on the most common and critical risks, without covering all possible vulnerabilities. Other threats and risks that are not listed in the Top 10 may be relevant to a particular application or environment.
A second issue is that the Top 10 is a generalized list. Similarly to the previous point, the OWASP Top 10 provides a broad overview of risks. Each application's specific context, architecture, and use case can introduce unique vulnerabilities not covered by the list. As a side effect of this, relying solely on the Top 10 might lead organizations to focus too much on these ten risks, potentially neglecting other critical security aspects. As an example, the Top 10 primarily focuses on coding vulnerabilities and may not thoroughly address insecure configurations, which are in many cases a source of security issues.
Third, the OWASP Top 10 is an awareness document. Thus, whilst it sheds light on issues we should particularly take care of, it doesn't provide a comprehensive security standard, framework, or methodology based on which we can set up KPIs and measurements for securing web applications. As an additional remark, it doesn't even specifically guide organizations on integrating security throughout the software development lifecycle.
Finally, to look at things from the right perspective let's not forget that the Top 10 is updated approximately every four years, and that is also based on statistical data collected during the years before. Thus, the current version of the Top 10 was published in 2021 and is based on data collected at least four years ago.
How is the ASVS standard organized?
OWASP ASVS is a framework that provides a basis for testing web application technical security controls, as well as any technical security controls in web services, APIs, and web applications. It consists of a total of 279 requirements covering, in total 117 different CWEs. Similarly to the Software Component Verification Standard which I talked about here, ASVS is organized in two different directions: Levels and Families.
The three Levels foreseen by the standard progressively extend the number of requirements and bring an increased level of security. Thus, Level 1 (consisting of 127 requirements) is recommended for any application (even the simple ones), and contains the bare minimum sets of verifications. It might suit the scenario if the application is not handling any kind of sensitive data, and ensures protection against basic-level attack attempts. Level 2 significantly extends the number of requirements, since it includes 267 verifications in total (more than 95% of those foreseen by the framework). OWASP recommends it to ensure protection against highly motivated attackers who target applications serving business-critical transactions or handling sensitive information in the context of business-to-business transactions.
Level 3 adds twelve additional requirements that ensure protection against malicious code in the source code or third-party libraries (5 requirements), set data protection requirements (regular backups shall be executed and safely stored, 2 requirements), verify the robustness of the cryptographic functions (2 controls), and the robustness of the business logic flows, the logging of the TLS connection failures, the integrity of the build pipelines with 1 requirement each.
The direction of the Chapters, groups the controls in 14 different categories. Each chapter provides a group of controls responsible for verifying a particular area of an application (e.g. V2 focuses on Authentication, V3 on Session Management, V4 on Access control, etc.) and can be further divided into sub-groups named sections. Each requirement is identified by a chapter, section, and requirement ID, and is also provided with a chapter name and a description. Chapter “V1 - Architecture, Design and Threat Modeling” requirements are included in levels 2 and 3 only.
Besides the specification of the level to which it applies, an indication of the CWE to which it is associated is provided. Multiple requirements could be present in the framework for the same CWE.
The table below here provides the list of CWEs for which more than one requirement is included (drop me a message if you would like to receive the CSV with the whole list). For instance, for CWE 116 (Improper Encoding or Escaping of Output) five different requirements are included in the framework.
The standard is also aligned with the NIST 800-63-3 Digital Identity Guidelines for the authentication part. Thus, for requirements within the Authentication chapter, a direct map to the corresponding NIST guideline is provided.
A nice fact about the standard is that Level 1 controls can be black-box checked, either automatically by tools or simply manually without access to source code.
Who is the OWASP ASVS standard designed for?
One of the best ways to use the Application Security Verification Standard is to use it as a blueprint to create a Secure Coding Checklist specific to your application, platform, or organization. Tailoring the ASVS to your use cases will increase the focus on the security requirements that are most important to your projects and environments. The framework is largely modular, and this significantly facilitates the adoption of security practices in the development lifecycle.
Among all the possible scenarios, I identify below the Development, Verification, and Procurement processes as some of the most relevant ones where the standard can be applied, providing some practical examples of how it can be used.
Development
Definition of Security Requirements. The ASVS can be used to establish a security baseline or set of requirements for application development. Developers can use it as a reference to understand what security controls they should be implementing at various levels of assurance.
Guided Development. With the detailed controls and checks provided by ASVS, developers have a clearer roadmap of what security measures to incorporate as they build applications.
Training. ASVS can serve as a training guide for developers, helping them understand the importance of various security controls and how to implement them.
Verification
Security Testing. The ASVS provides a comprehensive list of security controls, which can guide penetration testers and security professionals in verifying the security posture of an application.
Consistency. By adopting ASVS, organizations can ensure a consistent approach to security verification across multiple applications and teams.
Benchmarking. Organizations can use ASVS to benchmark their applications' security against a recognized standard, helping to identify gaps and areas for improvement.
Reporting. ASVS can be used as a basis for security assessment reports, providing stakeholders with a clear understanding of how an application fares against a recognized set of criteria.
Procurement
Vendor Assessment. When procuring third-party applications or services, organizations can use ASVS as a criteria list to assess the security of vendor solutions.
Setting Expectations. Organizations can provide vendors with the ASVS to set clear security expectations before procurement.
Contractual Agreements. ASVS can be referenced in contracts to ensure that vendors adhere to specific security standards, with levels of verification (e.g., Level 1, Level 2, Level 3) tailored to the risk and criticality of the application.
Third-party Verification. Organizations can request third-party vendors to provide ASVS-based verification reports, ensuring that the solutions they're procuring meet desired security standards.
Conclusions
In this post, I illustrated the OWASP Application Security Verification Standard.
ASVS consists of up to 279 security requirements which can be adopted by the development team, during ex-post verification, or even as requirements in a procurement process. Its requirements are organized in 14 different chapters and grouped in three different levels, ensuring a high degree of flexibility during the implementation of the standard.
I also illustrated some of the basic reasons why the OWASP Top 10, one of the OWASP flagship projects, is not suitable to support either the implementation of a secure software development lifecycle or an in-depth verification of applications. The ASVS standard has been instead designed to cover, among the others, these two scenarios.
References
OWASP Application Security Verification Standard - https://owasp.org/www-project-application-security-verification-standard/
OWASP Top 10 - https://owasp.org/www-project-top-ten/