A Brief History on OWASP Top 10:

OWASP Top 10 is one of the most popular community-based application security standards in the industry. The OWASP website describes OWASP top 10 as:

“The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications”

Since it is community-based, OWASP follows a data analysis plan from multiple sources; security vendors and consultancies, bug bounties, along with company/organizational contributions. Here is a quick overview of the changes of OWASP top 10 since inception.

This version was more data-driven than ever according to OWASP. Eight categories were chosen from contributed data and two categories from an industry survey at a high level.

The new OWASP Top 10 2021, which is still in RC1 at the time of writing this article, has changes that might have a lot of impact of how companies are aligning with OWASP Top 10:

1 - Moving from individual vulnerabilities to categories:

OWASP Top 10 was historically known for identifying the particular top 10 vulnerabilitiesrisks that are most prominent in today’s software security landscape. OWASP Top 10 usually calls out particular vulnerabilities rather than a category of vulnerabilities. For example, in the 2017 version, OWASP Top focused a lot on Insecure Deserialization and XML External Entity Injection. These two vulnerabilities that didn’t make an appearance again in the 2021 version.

There were a few cases were OWASP Top 10 called out vulnerability categories instead of individual vulnerabilities. For example, “Injection Flaws” was always called instead of example: SQL Injection, Command Injection, etc. This was necessary because all server-side injection flaws are equally bad so it is a waste of real estate to enumerate them one by one. “Using Components of Known Vulnerabilities.” Is another case where there is no particular/individual risk but more of a category that represents a set of other risks. Here is what CWE has to say about “Using Components with Known Vulnerabilities”

Looking at the 2021 RC1 version, there are a whole more categories than individual vulnerabilities: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components. Identification and Authentication Failures, Software and Data Integrity Failures and arguably Insufficient Logging and Monitoring Failures. Probably the only individual vulnerability is Server-Side Request Forgery.

This means that development teams have to consider a whole lot more individual flaws than before to be considered aligned with the OWASP Top 10 standard. In previous versions there was almost one to one mapping between each OWASP Top 10 and CWE (Common Weakness Enumeration), which makes it much easier to decide on what belong to OWASP Top 10 and what does not. It was also much easier to identify the risk while calculating the risk score using CVSS or DREAD. Software development teams can expect to see more issues with varying risk score based on that.

2 - Moving from risk to best practices

As I mentioned, the TOP 10 was more about individual vulnerabilities that seems to have both: frequency of discovery in the field as well as high impact if it got exploited. OWASP Top 10 was not about best practices, while it is obviously good to focus on best practices to avoid the vulnerabilities. This might be harder for companies to “align” with OWASP Top 10 as a standard.

This means that development teams have to adopt more and more best practices and can’t just rely on tools to be aligned with OWASP Top 10. Part of this is proving the best practices. This can also mean that development teams have to provide evidence that these best practices are being followed. For example: “A4 Insecure Design”, this is how the new Top 10 defines it:

So documenting the Threat Model, having it reviewed for correctness and coverage would be a requirement. Same thing for architecture diagrams and the usage of secure design patterns would be necessary to prove alignment with OWASP Top 10.

3 - Calling out outdated components

This particular category made its first appearance in the 2013 version, and it was hailed by most security experts since the risk of open source/dependencies/software supply chain was growing exponentially. However, the 2021 does not just call out the use of Component with Known Vulnerabilities, it calls out also any outdated components, even without any known vulnerabilities. Here is how OWASP Top 2021 describes this:

This means that development team have to upgrade 3rd party libraries/components regardless if there are any known-vulnerabilities in them. This is a big move from how this category was evaluated in the past. In the past, once the security team finds a component with know vulnerability, they have to prove that the vulnerability could be exploited or already have an exploit in the wild. Only then it would be considered a real vulnerability. With the new OWASP Top 10 update, that is not required anymore and a vulnerability could be cited by the mere usage of an outdated 3rd party library.

4 - Calling out software and integrity failures

This is not just a new category, it is quite broad as well. This can range from lack of integrity checks for OTA (over the air) updates, all the way to the lack integrity checks of 3rd party libraries being used by the application and everything in between. Here is how OWASP describes this category:

This means that security teams have to check for things like insecure deserialization which is considered by the new Top 10 as a lack of data integrity. In addition to software updates without signing, for example firmware updates without signing. This category also includes using 3rd party libraries in your CI without sufficient integrity checking.

Conclusion:

The new OWASP Top 10 2021 brings more shift left.