Broken access control still #1, misconfiguration jumps to #2, and software supply chain is now its own category.
The 2025 OWASP Top 10 reshuffled the risks that matter, and the reshuffle is honest about where real breaches now start. Broken Access Control stays at A01 and absorbs Server-Side Request Forgery into itself. Security Misconfiguration climbs from fifth to A02. And Software Supply Chain Failures debuts at A03 - the category with the fewest occurrences in the test data but the highest average exploit and impact scores. A list is only as useful as a team's ability to confirm and prioritize each item, so the question worth asking is not where a risk ranks but how you prove it is present.
Read the three movers together and a pattern falls out. The top of the list is access control you can only confirm at runtime, configuration that drifts faster than review keeps up with, and dependencies attacked at their source. None of these are caught by reading application source code alone, and none of them are caught by a scanner that reasons from heuristics instead of evidence.
The shifts are small in number and large in consequence. Folding SSRF into A01 is the most telling: an attacker who can make the server fetch a URL of their choosing is exercising the same failure as an attacker who reads another tenant's record - the application trusted a request it should have refused. Treating both as broken access control is the correct mental model, and it changes how you have to test for it.
| Rank | Category | What changed | How apPosture proves it |
|---|---|---|---|
| A01 | Broken Access Control | Stays #1; now folds SSRF into the category. | DAST differential and in-band evidence - the boundary is driven, not inferred. |
| A02 | Security Misconfiguration | Climbs from #5 to second. | IaC parsing surfaces misconfiguration and public exposure as file:line facts. |
| A03 | Software Supply Chain Failures | New category; fewest test-data occurrences, highest average exploit and impact. | SCA, secrets and malicious-package detection cover the dependency surface. |
Notice that the three categories at the top of the list are each proven by a different engine, looking at a different layer. That is not a coincidence of tooling; it is the structure of the problem. Access control is a runtime property, misconfiguration is a deployment property, and supply chain risk is a composition property. A single engine that claims to cover all three is usually guessing at two of them.
Broken access control cannot be confirmed by reading code, because the question is not whether a check exists in the source but whether it holds for a real request. An IDOR is not a suspicion that an identifier looks enumerable; it is the moment user A asks for object B and the server hands it over. We raise the finding on that moment and only that moment.
Folding SSRF in fits this exactly. We do not raise it because an endpoint accepts a URL parameter; we raise it because a benign, controlled request reached an internal resource and the response carried something back that proves the server made the fetch. No outbound exploit, no real attack on a third party - a marker request and the evidence of where it landed.
Security misconfiguration climbed to A02 because configuration drifts faster than review can keep up. A storage bucket goes public in a single line of Terraform, a security group opens 0.0.0.0/0 in a pull request nobody reads closely, a debug flag ships to production. These are not subtle logic bugs; they are facts sitting in a file, and the right way to surface them is to parse the file and point at the line.
That is what IaC parsing does. A finding here is not a probability score - it is a file and a line number with the offending setting quoted back. "Bucket policy at infra/storage.tf:42 grants public-read" is something an engineer can fix in the same pull request that introduced it, which is the only place a misconfiguration is cheap to fix. The further it travels, the more it costs.
Software Supply Chain Failures earning its own category reflects where the highest average exploit and impact scores now sit, even though the raw occurrence count is the lowest of the three. A compromised dependency does not need to appear often to be catastrophic; one malicious package in a transitive position reaches every build that pulls it. The risk is in what you compose, not only in what you wrote.
apPosture covers this end of the list with SCA, secrets detection and malicious-package detection. SCA maps a vulnerable component to the CVE that affects it; secrets detection finds credentials that leaked into the tree where a dependency or a CI step can read them; malicious-package detection flags the install-time and typosquat behaviors that turn a single bad dependency into a campaign. Each is a fact about the composition of the build, not a guess about intent.
apPosture maps every finding to its OWASP category deterministically - the same finding always lands in the same place, because the mapping is a lookup, not a judgement call. But the mapping is the easy half. The half that matters is that an A01 through A10 finding is only raised when the evidence supports it: a differential for access control, a parsed line for misconfiguration, a resolved CVE or install-time signal for the supply chain.
A ranking is a prioritization aid, not a coverage plan. The reason these three rose to the top is that each is proven at a layer source review never sees - runtime, deployment, and composition. We raise A01 through A10 on evidence, deduplicate them into a single posture so the same root cause is not counted three times, and gate the build on the ones that are actually reachable. A shorter list every item of which survives an audit is worth more than a long list a reviewer abandons at the first false positive.