Shouldn’t that be what’s new with the OWASP Top 10? Not in this blog. I am excited to be rejoining Security Innovation after having worked here from 2011-2014. One of the first things I am looking at is the new 2021 OWASP Top 10, and it’s like déjà vu all over again. After four years since the last OWASP Top 10, there are only three new ones, and one of those is related to one from 2017, leaving only two whole new categories. Here’s how they map:

OWASP Top 10: 2021 vs 2017

Even worse, if you went back to the original list in 2003, you will find mostly familiar vulnerabilities:

  • A1:2003 Unvalidated Input – Leads to A03:2021 Injections
  • A2:2003 Missing Functional Level Access Control – Same as A01:2021
  • A3:2003 Broken Authentication and Session Management – A07:2021
  • A4:2003 XSS – Directly on 2017 list as A07, Part of A03 on 2021 list
  • A5:2003 Buffer Overflows – This one has disappeared from the list – but still happens
  • A6:2003 Injection – A03:2021
  • A7:2003 Information Leakage in Improper Error Handling – Another one off the list
  • A8:2003 Sensitive Data Exposure – A02:2021
  • A9:2003 Remote Administration Flaws – This is gone, but certainly related to A05:2021
  • A10:2003 Security Misconfiguration – A05:2021

In 18 years, we knocked two off the list and have plenty of new fodder.

Before I start this next part, I want to emphasize that Security Innovation and I are supporters of OWASP and the OWASP Top 10 list. What I am about to discuss is a symptom of a larger problem, not a criticism of the list or its existence.

Why, after 18 years, do we need an OWASP Top 10? We should be past that mindset. Top 10 lists allow for focus on the most serious problems but can also be limiting. If I lose my bank balance to a hacker that exploits the eleventh most serious web application flaw, is that OK? I can imagine how that chat would go:

[Me, in a panic] My balance is gone!
[Bank] Yes, we know, we were hacked. But, the hacker used a technique not in the top 10.
[Me] Oh, OK, so I am out of luck. I understand. Too bad.

Well, maybe it would not go exactly that way.

There must be more done for us to get off this treadmill of regularly updated OWASP lists while still facing ever-worsening security breaches. The idea of the OWASP Top 10 is that it’s a start, not that it’s the list of what you must do or even a minimum. We need an entire change in attitude in software development (all parts, not just coding). What if every project had tickets that looked like this (if appropriate for the project)?

P1 – Must be in MVP

User Story: As a Hacker, I want to steal the organization’s sensitive data to make money on the dark web.

Result: Action is prevented.

Acceptance Criteria:

  • All checked in code peer-reviewed by certified security engineer, level 2 or above
  • All checked in code meets parameters established in the Threat Model
  • The application passes all QA xAST scans with no severity 1 vulnerabilities
  • Application passes unannounced, unlimited penetration test with no severity 1 vulnerabilities

Similar user stories could be written around bitcoin miners, ransomware, etc. Then bugs that hold up this ticket are part of the flow, not some separate thing pasted on. Security is not about checking against a minimum list; it’s about making the application secure from key threats. It’s about the dev team having it built into their mindset.

So how do we achieve this? Stay tuned for Part 2 of this blog.

About Fred Pinkett, Senior Director Product Management
Fred Pinkett is the Senior Director of Product Management for Security Innovation. Prior to this role, he was at Absorb, Security Innovation's learning management system partner. In his second stint with the company, he is the first product manager for Security Innovation's computer-based training. Fred has deep experience in security and cloud storage, including time at RSA, Nasuni, Core Security, and several other startups. He holds an MBA from Boston College and a BS in Computer Science from MIT. Working at both Security Innovation and Absorb, Fred clearly can't stay away from the intersection between application security and learning. Connect with him on LinkedIn.