Introduction
The application security field has been slowly shifting over the last decade – away from a focus on the traditional ‘black box’ approach to testing towards a more transparent ‘white box’ approach. This shift can be seen in the sheer amount of tooling and marketing around the implementation of secure code and secure coding practices. Cybersecurity products have now been highlighting the need for security to be part of the development cycle at the deeper code level, rather than as an afterthought on the final product a user interacts with.
The Open Worldwide Application Security Project (OWASP) has focused its efforts on educating and shaping the direction of application security since its inception in 2001. One of the latest developments that OWASP has made is the update to the Application Security Verification Standard (ASVS) with the release of version 5.0 in May 2025. Now that we’ve spent some time in the trenches with the latest version, we wanted to share our thoughts on the brand new changes and our testing focus over the months since implementing the update.
Figure 1: ASVS V5 Compliance Levels
What’s Changed?
The ASVS version 5.0 has updated most of the original requirements from ASVS version 4a major shift occurring in cybersecurity, with the emphasis now moving from basic ‘black box’ testing to a more granular and fine-tuned ‘white box’ style.
If you’re unfamiliar, these terms relate to the way a penetration test can occur. ‘Black box’ testing provides the tester with limited information about the application, leaving it up to the tester to enumerate the application for functionality to test. ‘White box’ testing, however, provides the tester with access to source code along with documentation and other resources regarding the functionality of the application.
The latest updates to the ASVS now call for testing to occur in the latter approach, with access to the source code now a requirement to successfully validate many of these controls. This shift to a more transparent approach to testing provides organisations with better assurance regarding the implementation of their security controls. It also assists the testers in better understanding the application that is being assessed and removes the guess work surrounding application functionality and potential vulnerabilities.
This shift can be clearly seen in the changes made to the ‘Levels’ system used in the ASVS version 5, where there has now been a change to lower the barrier to entry for Level 1 compliance. This change is intended to make it easier for organisations to take on the initial challenge of implementing ASVS version 5.0 requirements for the first time.
Furthermore, Level 1 in version 4.0 largely focused on controls that could be validated through black‑box testing. Version 5.0 breaks away from this model, decoupling those controls and refocusing on the requirements themselves.
The result is a clear shift in mindset for security practitioners and developers alike. Instead of assessing security from the outside, teams are now pushed to look ‘under the hood’ to examine how security is implemented in the application’s code. An example of this can be seen with the following security control:
Figure 2: ASVS V5 Control 13.3.1
This control requires inspection of the underlying code itself to determine how secrets are handled and stored.
Another major change that the ASVS has undergone is moving away from descriptive’ requirements. In previous versions, the ASVS would define the technical implementation of a security requirement. Instead, teams are now guided on the types of security considerations in application hardening and leaving it up to them to choose how they implement security measures in ways that fit their needs.
As an Offensive Security Specialist, I personally find this approach much easier to follow and to test for. During some assessments, I’ve found that clients can implement certain controls in a way that may not fit one-to-one with the requirements outlined in version 4.0. But in version 5.0, requirements have been redefined to focus heavily on mitigating security flaws rather than the mechanisms by which to achieve them.
The Division 5 Approach
As the ASVS format and emphasis has shifted, with industry standards and the ever-changing cybersecurity landscape. This shift for us has meant better integration of source code into our assurance services. This comes in two forms: source code review, and source-assisted testing. These two methods provide our clients with deeper analysis of their applications and greater assurance that tests performed focus not only on easily detectable vulnerabilities but also on defence-in-depth. Division 5 provides penetration testing services that seek to provide best practice recommendations and high value insights on the security of the applications that we test.
These two offerings have helped our clients gain a greater understanding about the security of their products. It has also assisted Division 5 in providing tailored advice around the vulnerabilities that are discovered, as we are able to interact with the source code and comment on the security implications. Furthermore, we have been able to discover ‘hard-to-find’ vulnerabilities with much higher technical impact because of the provided source code of the applications we are testing. Integrating the use of source-assisted testing has allowed us to spend less time gathering information about the application and more time testing the application, yielding better results for our clients.
Several examples of this include vulnerabilities such as SQL injection, privilege escalations, and account takeovers, which were all discovered using source code analysis and assisted testing. One example that can be shared is the discovery of the PasswordState authentication bypass that was found by Aidan Stansfield. This discovery, as outlined in the blog post, could not have been made without understanding the codebase.
Figure 3. Click the above to read more about the PasswordState authentication bypass
Another example occurred when one of our consultants, Sam Polichronis, discovered a vulnerability in an application which allowed the user to impersonate another user when a request header was specified in a request. Below is an example that demonstrates the logic of what was observed if the route could access the admin panel of an application (note that the code is only a representation for demonstration purposes and not the actual code observed during testing).
app.get('/api/admin', (req, res) => {
if (req.header['X-UserGrantedAccess'] == 'true') {
const user = header['X-UserGrantedAccess'].[0];
res.send(‘You’re acting on behalf of ${user}. Welcome to the admin panel.’);
}
else if (user.role != ‘Admin’) {
res.send(‘Role “Admin” is required to perform this function.’);
}
else {
res.send('Welcome to the admin panel');
}
});
As can be seen in the above example, when a request is made to the ‘/api/admin’ route, the application checks if the request has a custom header set. If it does, the application allows access to the admin panel. Using the source code, Sam was able to identify the vulnerable route without needing to enumerate the application or guess headers were used in the application source code.
The above two examples show how the philosophy behind the ASVS update is a welcome change to the industry, highlighting the latest shifts and trends over the last decade. These are not isolated incidents of success but indicative of what our consultants are discovering. Division 5 seeks to keep pace with such changes and deliver quality to our clients by following the ASVS as the de facto standard for all our application security assessments. Security starts before application deployment and must be a key consideration in the software development life cycle. Division 5 provides the assurance needed to deploy your application with security in mind.