Newcomers
Two new names have been added to the hall of fame: Software Supply Chain Failures and Mishandling of Exceptional Conditions.
One is a lot more interesting than the other, yet with the introduction of vibe coding and AI copypasta they have also created a spot for bugs and errors within the top 10.
The category of Software Supply Chain Failures takes over and expands on the old Vulnerable and Outdated Components category in a fun and interesting way.
With much the same old best practices of patching all your software, it has brought supply chain issues into the fold. Now it looks at security revolving around dependencies, build systems, and distributed pipelines.
Reading through the documentation, it brings up old principles that always ring true, such as “... the application of least privilege” and “No single person should be able to write code and promote it all the way to production without oversight from another human being” (two-person control).
Of note, the prevention steps are quite rigorous and would take serious consideration to implement. But from the list, “Deliberately choose which version of a dependency you use and upgrade only when there is need” had me thinking the most.
From the past, it was always seen that n or n-1 strategies for patching were ideal. But recalling how CrowdStrike turned off half the world in 2024, it makes sense that we should consider the implications of blindly updating to the latest patch, especially when it is not security related.
A more recent incident had numerous npm repositories hijacked with malicious code, which reinforces the idea of patch when necessary.
In the guidance from OWASP they mention steps to harden just about anything related to the build process: code repositories, developer workstations, build servers, CI/CD, and a few other developer-related areas. This has probably been a long time coming, as developers generally have had a bit more freedom when it comes to security.
Now to the consequence of AI vibe coding
Mishandling of Exceptional Conditions leads with a quote that sums it up: “... previously associated with poor code quality.”
It is the edge cases that cause bad error handling, “fail-open” logic, and related one-offs that can expose data or logic flaws at runtime.
In their prevention steps, they suggest scrutiny of the design phase with threat modelling and/or secure design review, and code review or static analysis.
Interestingly they also include stress, performance, and penetration testing of the final system, which are always worth a thought.
Categories that were shuffled
A rapid-fire view of categories that appeared in the previous iteration but changed positions:
- Security Misconfiguration - Jumps from #5 in 2021 to #2 in 2025. An example of how misconfigurations with modern environments come riddled with security flaws.
- Cryptographic Failures - Drops from #2 to #4. Still a highly active risk, yet prevalence in other categories knocks it down a peg.
- Injection - Slides from #3 to #5, possibly because frameworks and practices like parameterised queries have reduced classic injection.
- Insecure Design - Fell from #4 to #6, highlighting that more applications are created with proper design and threat modelling.
The tested
Amongst the other categories there was not any notable change except for the #1 spot: Broken Access Control now includes the previous #10 slot of Server-Side Request Forgery, making it all the harder to dethrone.
All in all, the updates highlight that familiar issues like broken access control, injection, and cryptographic failures remain relevant. The changes reflect how modern applications actually fail through misconfigurations, fragile supply chains, insecure design decisions, and poor handling of unexpected conditions.
Look forward to the next iteration in 2029.