OWASP Top 10 2025 shifts appsec risk toward supply chains

At a glance

What this is: Semgrep’s analysis of OWASP Top 10 2025 says application security risk is broadening toward supply chain integrity, error handling, and access control rather than remaining centred on code defects alone.

Why it matters: AppSec teams, IAM leads, and platform security owners need to treat build provenance, dependency trust, and access control as linked governance problems, not separate silos.

By the numbers:

• Semgrep contributed insights derived from its dataset of 127M security findings.
• Semgrep also drew on 340k repositories in its analysis.
• The analysis covered 13k organizations.
• Semgrep updated more than 4,000 rules to map findings to the new OWASP Top 10 categories.

Context

The key governance gap in this OWASP update is that many teams still treat application risk as a code-quality problem when the real exposure now spans the software lifecycle. Dependency trust, build integrity, exception handling, and access control are operating together, which means the security boundary has moved upstream and outward from source code alone.

That matters for identity and access governance because software supply chains depend on privileged build accounts, pipeline credentials, and control over what can be published or consumed. When access paths and delivery integrity are weakly governed, application security failures become an identity and lifecycle problem as much as a coding problem.

Key questions

Q: What should application security teams do first after the OWASP Top 10 2025 update?

A: Start by remapping existing findings to the new categories, then identify where supply chain integrity, access control, and exception handling controls are missing or weak. That reveals whether the programme is still focused mainly on code defects or whether it now covers build provenance, release trust, and failure-state behaviour as well.

Q: Why does software supply chain risk now matter more in application security?

A: Because modern applications depend on code, packages, build systems, and update channels that can all be compromised independently of source code quality. If a trusted dependency or signed artifact is tampered with, the application can inherit malicious behaviour even when developers wrote secure code. Governance has to move to the full delivery chain.

Q: What breaks when exception handling is not part of appsec review?

A: Systems can leak sensitive data through error messages, crash unpredictably, or expose internal states that should remain hidden. Those failure modes create attack surface because adversaries often probe malformed inputs and edge cases precisely to trigger unsafe behaviour. Secure design has to include how software behaves when things go wrong.

Q: How should teams test whether SSRF-like paths are actually contained?

A: Review request flows that can reach internal services, callback endpoints, or proxy logic, and confirm they are governed by explicit authorization and segmentation. If an application can be persuaded to fetch resources it should not reach, the control failure is usually broader than a single vulnerable endpoint.

Technical breakdown

Why software supply chain failures now sit inside appsec risk

Software supply chain failures cover the path from dependency selection to build, packaging, signing, and update delivery. If any step in that chain is compromised, the application can ship trusted malicious code even when the application source itself looks clean. That is why this category expands beyond outdated libraries into tampered builds, compromised dependencies, malicious packages, and insecure updates. In practice, the security model has to follow the artifact, not just the repository.

Practical implication: teams must govern build provenance and dependency trust as part of application security, not as a separate engineering concern.

How broken access control absorbs SSRF-like failure paths

SSRF becomes an access control issue when an application can be induced to make requests on behalf of a caller and thereby reach internal resources it should not touch. The control failure is not only input validation but also authorization boundaries around what the application is allowed to fetch, proxy, or disclose. OWASP’s consolidation reflects a broader pattern in which request routing, service-to-service trust, and privilege boundaries blur. That makes access control a system property, not just a route or endpoint check.

Practical implication: reviewers should test whether request mediation, proxy logic, and internal fetch paths are actually constrained by authorization policy.

Why mishandling exceptional conditions is now a first-order security issue

Exceptional conditions are the cases software does not handle cleanly, such as malformed inputs, resource failures, partial outages, or unexpected states. When those cases produce verbose errors, crashes, or inconsistent state transitions, they can leak data or expose attack paths that normal flows would hide. OWASP’s addition signals that resilient failure handling is part of secure design, not just reliability engineering. For AppSec, the question is whether the system fails closed, degrades safely, and avoids exposing sensitive internals when stressed.

Practical implication: teams need to validate error handling, crash behaviour, and failure-state disclosure alongside standard vulnerability scanning.

NHI Mgmt Group analysis

Software supply chain risk is now an application security governance problem, not just a developer hygiene problem. The 2025 OWASP Top 10 makes clear that compromised dependencies, tampered builds, and insecure updates belong in the core risk model. That changes ownership: security teams must govern artifact trust, pipeline credentials, and release integrity with the same seriousness they apply to code review and vulnerability remediation. Practitioners should treat supply chain integrity as an AppSec control surface.

Exception handling is a security control, not a reliability afterthought. Mishandling exceptional conditions often becomes the mechanism by which sensitive information leaks or internal state is exposed. This is a useful correction to the industry habit of separating secure coding from resilient operations. Practitioners should assess whether failure states are observable, bounded, and safe under stress.

Access control is absorbing more of the web attack surface than many teams realise. The SSRF-to-broken-access-control consolidation is a signal that authorization failures increasingly appear through request mediation, not just direct privilege checks. That is especially relevant where service accounts, automation, and internal APIs can be induced to act on behalf of an attacker. Practitioners should review access boundaries at every hop, including proxy and callback flows.

Build provenance and runtime trust need shared governance language. The article shows that OWASP’s model is moving from isolated defect classes toward lifecycle integrity. That mirrors what identity teams already see in NHI governance: credentials, trust decisions, and usage context must be controlled together or the system remains exploitable. Practitioners should align AppSec, platform engineering, and IAM around a common trust model.

OWASP Top 10 2025 sharpens the industry’s shift from vulnerability counting to control design. The most useful change is not the category list itself but the fact that it reframes risk around how software is built, connected, and made to fail. Teams that keep treating findings as isolated issues will miss the control-plane problems underneath them. Practitioners should use the update to re-baseline what their secure development and release controls are actually meant to govern.

What this signals

Application security teams should treat the 2025 OWASP Top 10 as a control-design reset, not a simple category refresh. The update points to build provenance, exception handling, and access boundaries as programme-level concerns that cut across appsec, platform engineering, and IAM.

Lifecycle trust gap: the most important shift is that software risk now follows the artifact from dependency selection through build and release, so governance has to cover those handoffs explicitly. That is where NHI-style credential and pipeline control thinking becomes relevant to application delivery as well.

Teams that still measure AppSec mainly by defect counts will miss the organisational issue the article exposes, which is whether software can be built, trusted, and failed safely under real operational conditions.

For practitioners

• Review build provenance controls Inventory where dependencies are introduced, who can modify build pipelines, and how artifacts are signed before release. Tie those controls to software supply chain failures rather than treating them as separate release engineering checks.
• Test exception handling under failure states Exercise malformed inputs, partial outages, and denied access paths to verify that applications fail closed and do not leak internal detail through verbose error messages or unexpected crashes.
• Map SSRF exposure to access boundaries Review every route that can trigger server-side requests, callback handling, or internal fetch logic, and confirm that each path is constrained by explicit authorization and network segmentation.
• Align AppSec findings to updated OWASP categories Reclassify existing findings against the 2025 Top 10 so teams can see whether open issues cluster around supply chain integrity, access control, or exception handling rather than only injection-style defects.

Key takeaways

• OWASP Top 10 2025 moves application security beyond code-centric defect hunting and toward control over supply chains, access boundaries, and failure behaviour.
• The update matters because compromised dependencies, tampered builds, and unsafe exceptions can all create risk even when the application source itself looks sound.
• AppSec programmes should re-baseline their findings, ownership, and review processes around the full software lifecycle rather than treating release integrity and error handling as secondary concerns.

Key terms

• Software Supply Chain Failure: A software supply chain failure is any breakdown in the build, dependency, signing, or distribution chain that allows tampering, compromise, or unauthorized access. For NHI security, the concern is not only corrupted code but also the credentials and machine identities that move that code through the pipeline.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Exceptional Conditions: The unusual or failure states software enters when inputs are malformed, dependencies fail, resources run out, or assumptions break. Secure systems must handle these states without leaking data, crashing unsafely, or exposing internal implementation details.
• Artifact Integrity Check: An artifact integrity check compares an image’s expected fingerprint with the actual file or layer hash observed in the environment. The goal is to detect tampering, replacement, or unexpected modification before trust is assigned. In cloud security, integrity validation is a core control for unverified public images and other deployed artifacts.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.