OWASP Rewrote Its Top 10 for the First Time Since 2021. Your Dependencies Are Now the Bigger Risk.
October 16, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
The OWASP Top 10 changed for the first time since 2021, and the biggest move wasn't a new injection technique. It was software supply chain failures jumping straight to third place. If your application security program still ranks findings the way it did four years ago, you're likely underweighting the exact risk category now driving the most damaging production incidents.
What Actually Changed in the OWASP Top 10 for 2025?
The OWASP Foundation released its eighth edition of the Top 10 Web Application Security Risks, the first substantive revision since 2021, with the final version out in January 2026 after a release candidate presented at Global AppSec DC in November 2025. According to Qualys's breakdown of the update, the list was built on analysis of more than 175,000 CVE records and 589 Common Weakness Enumerations, a far larger evidence base than prior editions leaned on.
Two entirely new categories entered the list this cycle. As Fastly's analysis of the changes lays out, the 2025 list added Software Supply Chain Failures and Mishandling of Exceptional Conditions, while Server-Side Request Forgery, its own category in 2021, got folded into Broken Access Control. Security Misconfiguration also climbed to second place, and Broken Access Control kept the top spot it has held since the previous edition.
None of that is cosmetic reshuffling. It reflects where real breaches are originating now, not where they originated in 2021, and it changes what a defensible AppSec triage list looks like in a code review, a pentest report, or a CSSLP exam scenario.
Why Did Software Supply Chain Failures Jump to Number Three?
Because the trust boundary of a modern application no longer sits at the edge of your own codebase. Most software today runs on layers of open-source libraries, CI/CD tooling, container images, and SaaS integrations that a team pulls in once and rarely revisits. Endor Labs's analysis of the category's addition notes that the inclusion of supply chain failures at third place marks a real shift in how the security community ranks application risk, expanding well beyond the old "vulnerable and outdated components" framing from 2021.
The failure mode isn't usually a zero-day in a popular package. It's inherited trust that never gets re-examined. OWASP's own description of the category is direct about this: organizations run into trouble when they lack a change management process or tracking of changes within their supply chain, including tracking of IDEs and extensions, repository changes, and whether patched libraries were ever tested for compatibility before being pushed to production.
That maps directly to what shows up in incident postmortems. A patch sits unapplied for a quarter because it's tied to a change-control cycle. A build pipeline pulls a compromised dependency because nobody validated its checksum. A sandbox environment quietly diverges from production until an update breaks something nobody tested. None of this requires an attacker to write new exploit code. It just requires them to find the gap between what a team assumes about its dependencies and what's actually true.
What Is Mishandling of Exceptional Conditions, and Why Does It Matter Now?
It's the new category covering what happens when software fails to anticipate, detect, or gracefully respond to unusual input and unexpected system states. Landing at the bottom of the 2025 list doesn't mean it's a minor concern. It means OWASP is formally recognizing a failure pattern that used to get buried inside vaguer categories like insecure design or security logging failures.
In practice, this covers crashes that leak stack traces with internal paths, error handlers that fail open instead of closed, and retry logic that silently drops security checks under load. These are the kinds of defects that rarely show up in a straightforward penetration test scoped to normal application behavior, which is exactly why the category earned its own line item. A tester deliberately pushing malformed input, timeouts, and resource exhaustion is testing something different than a tester walking the happy path, and that distinction matters for anyone writing rules of engagement for a pentest++ engagement or scoping a bug bounty program.
How Does This Connect to the Federal Push on Software Attestation?
It connects because regulators are now asking software vendors to prove the exact practices this update is elevating. Since 2022, federal agencies have required software producers selling to the government to complete the CISA Secure Software Development Attestation Form, which requires producers to attest that they follow secure development practices covering component integrity, dependency management, and provenance tracking across the build pipeline.
That requirement was written before OWASP formalized supply chain failures as its own top-three risk category, but the two documents describe the same problem from different angles. One is a compliance form asking "can you prove your build pipeline is trustworthy." The other is a risk ranking saying "most teams currently can't." Read together, they tell you where budget and audit attention are heading over the next few certification cycles, regardless of whether your organization sells directly to the federal government.
What This Means for Your AppSec Program
The practical shift is in triage, not tooling. Static analysis and dependency scanners were already common. What changes is how much weight a finding in your software bill of materials gets relative to a classic injection bug, and whether your team has a defined owner for revalidating dependencies after a patch, not just applying it.
| 2025 Rank | Category | What Changed |
|---|---|---|
| A01 | Broken Access Control | Stays #1, now absorbs SSRF |
| A02 | Security Misconfiguration | Climbs to #2 |
| A03 | Software Supply Chain Failures | New category |
| A10 | Mishandling of Exceptional Conditions | New category |
A few concrete steps move a program from aware of this change to actually acting on it:
- Assign explicit ownership for revalidating a dependency after every patch, not just tracking whether the patch was applied.
- Extend fuzz and negative testing to cover exception paths and malformed input, not only the documented happy path.
- Treat your software bill of materials as an audit artifact reviewed on a schedule, not a one-time inventory exercise.
If your team is building or refreshing an AppSec curriculum around this, the ISC2 CSSLP certification is built specifically around secure software lifecycle practices, including the supply chain and third-party component controls this update is now weighting more heavily. It's also worth checking the curriculum overview and FAQ in the resources section if you're deciding whether CSSLP or a broader security certification fits your current role better. For teams that want a structured way to close this gap rather than absorbing it piecemeal, you can start training around the updated OWASP categories now rather than waiting for the next audit cycle to force the issue.
The Bottom Line for Reviewers and Testers
A code reviewer, a pentester, or a CSSLP-credentialed architect who still treats supply chain findings as a lower-priority cleanup item is working from an outdated risk model. OWASP's own data, built on nearly six hundred CWEs and well over 100,000 CVEs, says otherwise. The organizations that adjust their review checklists, their pentest scoping, and their patch-validation habits to match this update will catch the failures that actually cause incidents. The ones that don't will keep finding SQL injection bugs while a compromised build step ships something worse.