gonin - stock.adobe.com
Is it time to rethink the OWASP Top 10?
The OWASP Top 10 serves as a key reference point for developers and security professionals, but with a new iteration on the horizon, we need to confront a hard truth: has it lost its effectiveness, or have we failed to implement it meaningfully?
The Open Worldwide Application Security Project (OWASP) has earned a reputation as a trusted authority in application security. Its most widely recognised contribution, the OWASP Top 10, serves as a key reference point for developers and security professionals, outlining the most prevalent web application risks. Since its debut, it has been championed as a foundational resource for secure software development. But with a new iteration on the horizon, we need to confront a hard truth: has the OWASP Top 10 lost its effectiveness, or have we failed to implement it meaningfully?
There’s no denying that the OWASP Top 10 plays a valuable role in raising awareness. However, the persistent presence of the same vulnerabilities over multiple editions, such as injection attacks, cross-site scripting (XSS), authentication weaknesses, and misconfigurations raises concerns. Despite being widely known, these issues continue to plague software development. The growing number of vulnerabilities recorded each year in the CVE database underscores this worrying trend. Instead of seeing improvement, we’ve normalised many of these flaws. So, why does meaningful progress remain elusive?
What is holding back the OWASP Top 10?
In my view, three core issues are preventing the OWASP Top 10 from driving real change: developers often lack environmental context, security education is diminishing, and the list itself isn’t easily actionable.
1. Developers don’t have the right context
Today’s developers typically work within defined user stories and are primarily assessed based on feature delivery rather than security considerations. Frequently, they lack insight into how their code will function in real-world scenarios. Is it part of a financial service? A public-facing app? Or something more sensitive, like a healthcare platform? Context is easy to have when software is created only for specific products, or for use within the four walls of a company.
But when context goes missing developers are left to make assumptions that can inadvertently introduce risk. The problem is compounded by how the industry treats developer roles: assuming uniform knowledge levels by job title, when in reality, training and experience vary significantly. This is especially problematic in an era where AI-generated code is on the rise. If that code is informed by insecure patterns, or if developers aren’t equipped to spot potential dangers, the risks multiply.
Think about this: when code is reused across SDKs, APIs, or open-source packages, or after a company acquisition, the original developer’s awareness of how the code will be used often disappears. The further removed a developer is from the end-use, the harder it is to factor in the appropriate security measures.
2. Security education is declining
Awareness doesn’t equal understanding. And understanding doesn’t happen without proper education.
According to the latest Building Security in Maturity Model (BSIMM) Report, now in its 15th edition, security awareness training in organisations has dropped by nearly 50% since 2008. This is particularly alarming given the expanding attack surface, rising threat sophistication, and tightening regulatory requirements.
One-off security presentations or circulating documents aren’t sufficient. Developers need continuous, practical training that aligns with the environments and technologies they work in. Without it, the OWASP Top 10 risks becoming a check-the-box exercise rather than a catalyst for secure development.
3. A list without action
Raising awareness is only one part of the solution. Without the tools and processes to act on that knowledge, the OWASP Top 10 remains passive. It outlines risks but lacks built-in remediation advice, prioritisation frameworks, or mechanisms for accountability. As a result, both developers and security teams may regard it as someone else’s responsibility. Static lists don’t inspire dynamic change unless there’s an ecosystem in place to operationalise them.
Software security goes beyond web apps
Another key limitation of the OWASP Top 10 is its narrow focus on web applications. In today’s digital landscape, applications span far more than the web; they include mobile platforms, APIs, embedded systems, and cloud-native architectures.
To gain a broader and more relevant perspective, it’s worth turning to resources like MITRE’s CWE Top 25, which highlights platform-independent software weaknesses based on how frequently they’re exploited and the severity of their impact.
Here’s a telling stat: 40% of the vulnerabilities in the 2024 CWE Top 25 aren’t reflected in the OWASP Top 10 at all. One of the most frequently exploited issues, CWE-787, an out-of-bounds write, is completely absent. That’s because OWASP focuses on web vulnerabilities, while CWE considers the full software ecosystem. This disconnect fosters a piecemeal view of security and can leave significant blind spots.
The age of accountability has arrived
Where application security once emphasised raising awareness, regulatory forces are now ushering in a new era of enforcement. For example, the EU’s Digital Operational Resilience Act (DORA), effective from January 2025, imposes rigorous standards for financial institutions, including mandates for incident response and third-party risk assessments. Compliance is no longer a choice.
Looking ahead, the Cyber Resilience Act (CRA), scheduled for enforcement in 2027, will introduce mandatory security obligations for all connected hardware and software sold in the EU. The penalties for non-compliance are substantial enough to capture board-level attention.
These regulations represent a clear evolution from recommendation to obligation. Companies that fail to build proactive security programs will lose market trust and ultimately, relevance.
Read more about secure software development
- DevOps Institute, Practical DevSecOps, EXIN and EC-Council are among the organisations that offer DevSecOps certifications and trainings for cyber security professionals.
- DevSecOps tools integrate security throughout development. These 12 options enhance workflows from coding to deployment without slowing teams down.
- Security as code helps organizations achieve DevSecOps and shift-left security. Learn about SaC's benefits, challenges and implementation best practices.
Taking action: What should happen now
If your security strategy relies solely on the OWASP Top 10, it’s time to expand your approach. Use it as a launchpad, not a destination. Pair it with more comprehensive resources like the CWE Top 25 to capture a fuller picture of modern threats.
Equip developers with both authority and tools. Integrate secure development into CI/CD pipelines. Provide immediate security feedback during development, not just post-deployment. Make security integral to product completion, not an afterthought.
Training also needs to evolve. Developers require contextual education tailored to their environments, tech stacks, and business risks. Generalised courses won’t cut it.
Additionally, measure your program against real-world data. Resources like the BSIMM Report reveal what successful organisations are doing. Use these insights to benchmark and continuously improve your practices.
Finally, create clear lines of accountability. Make security metrics part of regular reviews. Link them to incentives. Because when security becomes part of the core business process, sustainable change becomes possible.
In conclusion
We’ve been confronting the same vulnerabilities in the OWASP Top 10 for over 15 years. During that time, we’ve seen enormous innovation, from cloud computing to artificial intelligence, yet we’re still undermined by familiar flaws like injection bugs and broken authentication.
So perhaps the issue isn’t whether the OWASP Top 10 has failed. The real question is: why haven’t we taken greater action based on what we already know?
Tim Mackey is head of software supply chain risk at Black Duck.
