The board's next question just changed
Your board's last question was "are we secure?" The OWASP Top 10:2025 just changed what a good answer looks like. It is the biggest rewrite of the list in years: two new categories, four significant re-rankings, three renames, and one absorbed into an existing entry. Over 175,000 CVEs and 589 CWEs went into building it. Three of the ten shifts should reshape the next security budget conversation, because none of them are primarily about code.
The three shifts, in one view
None of the three moves that matter most in OWASP Top 10:2025 are about a coding flaw. All three are about whether you can prove control over systems you assemble, configure and depend on.
| Category | The signal | Do this |
|---|---|---|
| A03 Software Supply Chain Failures | Highest impact score, lowest CVE count: rare, catastrophic | SBOM as a procurement requirement; sign every artefact in CI/CD |
| A02 Security Misconfiguration | Moved from #5 to #2: the highest-probability risk is now infrastructure, not code | CSPM mandatory for multi-cloud; CIS Benchmarks as deployment gates, not quarterly findings |
| A10 Mishandling of Exceptional Conditions | New category: fail-open logic, cascading failures, unhandled exceptions | Audit fail-open patterns on critical paths; fund the chaos-engineering work that tests the failure before production does |
- Are we secure?
- Have we patched known CVEs?
- Is the code reviewed?
- Can we prove our supply chain?
- Is our cloud configuration enforced, not just reviewed?
- What happens when a dependency fails open?
A03: supply chain has its own category now
Vulnerable and Outdated Components has become Software Supply Chain Failures, and it moved to third place. The scope widened on purpose: it is no longer only about known vulnerabilities in components you chose. It now covers unknown vulnerabilities introduced by third parties you did not choose and often cannot see. The category carries the highest impact score on the list and one of the lowest CVE counts, exactly the risk profile that breaks a probability-based patching programme: rare events, catastrophic blast radius.
SolarWinds is still the reference case. Attackers compromised a build pipeline, not a product, and the trojanised update reached roughly 18,000 of the 33,000 organisations running the software. No vulnerability scanner would have caught that, because nothing in the shipped code was vulnerable. The build process was. Two changes follow directly. A software bill of materials moves from best practice to procurement requirement, something asked of every vendor before the contract, not after the incident. And artefact signing goes into the CI/CD pipeline itself, because if you cannot verify where a build came from, you cannot claim you control what you run.
A02: misconfiguration outranks injection
Security Misconfiguration moved from fifth place in 2021 to second in 2025. Broken Access Control still tops the list, but the category climbing fastest underneath it is not a coding flaw at all. It is infrastructure your own teams configure, and misconfigure, at cloud scale, every day. The 2021 Microsoft Power Apps exposure is still the clearest illustration: researchers found more than a thousand Power Apps portals with their data API left open to anonymous access, and thirty-eight million records across dozens of organisations, government agencies and private companies among them, were reachable to anyone who found the URL. It was not a zero-day. It was a default nobody had reason to go looking for.
Not a zero-day. A checkbox.
The response has to run ahead of the audit cycle, not behind it: cloud security posture management for anything running multi-cloud, because the attack surface grows faster than a person can review it by hand, and CIS Benchmarks enforced as deployment gates rather than findings written up in next quarter's report.
A10: operational resilience enters AppSec
The genuinely new entry is Mishandling of Exceptional Conditions, two dozen CWEs covering fail-open logic, cascading failures and unhandled exceptions, the things that only happen when a system meets an input nobody planned for. In an industry survey behind the list, this ranked as the top emerging concern. 2025 gave a public demonstration of why: a large part of the internet went dark when an uncaught exception in a core proxy stopped it serving traffic at all, an outage that reached a meaningful share of one major provider's global load in under half an hour. The fix was not a missing feature. It was an error path nobody had exercised.
This is now an application security finding, not only a site-reliability one. Audit fail-open patterns across the applications that matter most, because that failure mode tends to be systemic across an estate rather than a one-off, and fund the chaos-engineering work that tests the failure path deliberately, before production tests it for you.
Where this changes the next budget conversation
All three moves point the same direction: away from finding flaws in code you wrote, toward proving control over systems you assemble, configure and depend on. A benchmark exercise that only re-scans your own code for known vulnerabilities is still answering a 2021 question. The board's next question is different: can you prove what is in your supply chain, can you show your cloud configuration is enforced rather than reviewed, and do you know what your systems do when something fails. Pick one production application and answer honestly against just those three categories. The gaps are where the next conversation with the board should start.
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands a post first published by the author on LinkedIn.
