About two and a half years since the last release, the latest version of the Application Security Verification Standard (ASVS), version 4.0, was officially released on March 1.

The ASVS project always tries to draw lessons from the feedback of its community and industry and to include this in the standard. In particular, it is important to the heads of the ASVS project that the standard can be used for various use cases in the development of secure software.

In order to be useful not only for testing, but also as effective as possible in the development and design of software,some of the knowledge and ideas of the OWASP Proactive Controls were integrated into the ASVS. The Proactive Controls are basic high-level strategies that can help write secure software. Taking development of the ASVS in this direction is certainly a good idea, since the idea of pushing left, i.e. considering security earlier in the development cycle, is becoming more and more widespread.

Providing additional resources to support this is certainly valuable. The easier it is to produce secure software, the more software developers are supported in doing so, the more secure and higher quality the software becomes. However, this also means that the supporting resources must not only be correct but also understandable.

Therefore, it was also a goal of the ASVS v4 to minimize overlaps or inconsistencies with other standards by either aligning the ASVS closely with them (NIST SP 800-63) or being a strict superset. For example, the ASVS covers everything that is included in the OWASP Top 10 2017 and more, so that the ASVS simply does not compete with the top 10. Compliance costs and effort should be reduced and no time wasted because unnecessary differences must be accepted as risks, thanks to this approach.

Structural rework and simplifications

The ASVS has grown since the original release in 2008 and was therefore not always as clear and straightforward as it could be. With version 4.0, the opportunity was taken to streamline the ASVS a bit.

This included restructuring the levels of the ASVS somewhat. There is no more Level 0, L1 now covers the absolute minimum and focuses even more on the OWASP Top 10 than before. In addition, L1 is almost completely covered by a blackbox penetration test, without access to source code or documentation. However, this is strongly discouraged in the ASVS, since this only serves to lower the quality of the results. I strongly agree with this recommendation, especially since there are actually requirements, even on L1, which can only be verified with access to documentation or interviews with developers.

Additionally, L1 is only sufficient to protect against opportunistic attackers. As soon as the threat model includes targeted attacks against the application, one should consider applying L2.

Reordering and renumbering

In the previous version of the ASVS, the chapters were not numbered consistently, as individual chapters had been removed from the ASVS. Since the numbering in Chapter 2 had to be revised anyway, in order to align the ASVS more closely with NIST SP 800-63, this was taken as an opportunity to renumber the complete ASVS.

The gaps in the numbering were closed and the chapters divided into smaller subchapters. Likewise, entries were split up and separated more cleanly. Entries which were related specifically to a single programming language were removed, as were overlapping entries or entries which represented little danger.

In this way, 19 chapters with around 180 entries became 14 chapters, 69 subchapters and 286 individual items. The subchapters are designed to help users of the ASVS pick the items that are relevant to them. For example, Chapter 13 covers APIs and Web Services: 13.1 covers generic requirements, 13.2 focuses on RESTful Web services, 13.3 SOAP-based, and 13.4 on GraphQL and other data layers. So if you do not use GraphQL, you can ignore 13.4 instead of having to hunt down the GraphQL requirements spread over several chapters and mark them as Not Applicable.

Next steps

The ASVS project has not yet reached some sort of “end”, where the ASVS merely needs to be adapted to new technologies occasionally. Next steps have already been planned and, in part, even been tackled.

Additional mappings will be created to combine the ASVS more effectively with other documents. In particular, a reference to the OWASP Testing Guide v4 is to be established, so that the ASVS is even better suited to serve as the basis for tests and reviews. It is also being discussed whether a Common Weakness Scoring System (CWSS) rating is to be created for each entry in the ASVS, which would help prioritize and classify the individual entries in an even more granular fashion.

About the Author

Mark Zeman has a Master of Science in Engineering with focus on Information and Communication Technologies at the FHNW. He was able to transform his passion of information security to his focus since 2017. During his bachelor studies he worked for an email security company. (ORCID 0000-0003-0085-2097)

Links

• https://cwe.mitre.org/cwss/
• https://pages.nist.gov/800-63-3/
• https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_2017_Project
• https://www.owasp.org/index.php/OWASP_Proactive_Controls