The Role of Penetration Testing
In version 4.0, we decided to make L1 completely penetration testable without access to source code,
documentation, or developers. Two logging items, which are required to comply with OWASP Top 10 2017
A10, will require interviews, screenshots or other evidence collection, just as they do in the OWASP Top 10
2017. However, testing without access to necessary information is not an ideal method of security verification,
as it misses out on the possibility of reviewing the source, identifying threats and missing controls, and
performing a far more thorough test in a shorter timeframe.
Where possible, access to developers, documentation, code, and access to a test application with non-
production data, is required when performing a L2 or L3 Assessment. Penetration testing done at these levels
requires this level of access, which we call "hybrid reviews" or "hybrid penetration tests".
Other uses for the ASVS
Aside from being used to assess the security of an application, we have identified a number of other potential
uses for the ASVS.
As Detailed Security Architecture Guidance
One of the more common uses for the Application Security Verification Standard is as a resource for security
architects. The Sherwood Applied Business Security Architecture (SABSA) is missing a great deal of information
that is necessary to complete a thorough application security architecture review. ASVS can be used to fill in
those gaps by allowing security architects to choose better controls for common problems, such as data
protection patterns and input validation strategies.
As a Replacement for Off-the-shelf Secure Coding Checklists
Many organizations can benefit from adopting the ASVS, by choosing one of the three levels, or by forking
ASVS and changing what is required for each application risk level in a domain specific way. We encourage this
type of forking as long as traceability is maintained, so that if an app has passed requirement 4.1, this means
the same thing for forked copies as the standard as it evolves.
As a Guide for Automated Unit and Integration Tests
The ASVS is designed to be highly testable, with the sole exception of architectural and malicious code
requirements. By building unit and integration tests that test for specific and relevant fuzz and abuse cases,
the application becomes nearly self-verifying with each and every build. For example, additional tests can be
crafted for the test suite for a login controller, testing the username parameter for common default
usernames, account enumeration, brute forcing, LDAP and SQL injection, and XSS. Similarly, a test on the
password parameter should include common passwords, password length, null byte injection, removing the
parameter, XSS, and more.
For Secure Development Training
ASVS can also be used to define characteristics of secure software. Many “secure coding” courses are simply
ethical hacking courses with a light smear of coding tips. This may not necessarily help developers to write
more secure code. Instead, secure development courses can use the ASVS with a strong focus on the proactive
controls found in the ASVS, rather than the Top 10 negative things not to do.
As a Driver for Agile Application Security
ASVS can be used in an agile development process as a framework to define specific tasks that need to be
implemented by the team to have a secure product. One approach might be: Starting with Level 1, verify the
specific application or system according to ASVS requirements for the specified level, find what controls are
missing and raise specific tickets/tasks in the backlog. This helps with prioritization of specific tasks (or
grooming), and makes security visible in the agile process. This can also be used to prioritize auditing and
reviewing tasks in the organization, where a specific ASVS requirement can be a driver for review, refactor or
auditing for a specific team member and visible as "debt" in the backlog that needs to be eventually done.
As a Framework for Guiding the Procurement of Secure Software
ASVS is a great framework to help with secure software procurement or procurement of custom development
services. The buyer can simply set a requirement that the software they wish to procure must be developed at