OWASP Top 10 2025 shifts appsec risk toward supply chains

At a glance

What this is: OWASP’s 2025 Top 10 reframes application security around supply chain exposure, error handling, and access control rather than code-only defects.

Why it matters: For IAM and NHI practitioners, the change matters because application risk now intersects more directly with secrets, service access, build pipelines, and delegated permissions across software delivery.

By the numbers:

• Semgrep contributed insights derived from 127M security findings, 340k repositories, and 13k organizations.
• Semgrep updated all 4,000+ Semgrep rules to use the new OWASP Top 10 mappings.

👉 Read Semgrep’s analysis of the 2025 OWASP Top 10 changes

Context

Application security is shifting from isolated code defects to failures that emerge across the software development lifecycle, including build systems, dependency trust, and how applications handle exceptions. That matters because OWASP Top 10 updates increasingly map to operational control gaps, not just vulnerable lines of code, and that creates direct overlap with secrets, privileged access, and machine identity governance.

For identity and security teams, the key implication is that application controls now influence who and what can act inside delivery pipelines and runtime environments. Where services, tokens, and automation identities are involved, the boundary between AppSec and NHI governance becomes much thinner, especially around access paths, exception handling, and supply chain integrity.

Key questions

Q: How should security teams govern software supply chain risk in application delivery?

A: Treat software supply chain risk as a lifecycle control problem, not just a vulnerability-management issue. Teams should govern dependency trust, build integrity, release signing, and the service accounts that can alter artefacts. The key question is whether any identity in the pipeline can change what gets shipped without strong approval and provenance controls.

Q: Why does SSRF belong in access control discussions?

A: SSRF matters because it can make a trusted service send requests that the attacker could not send directly. That turns a request path into an authorisation path. When internal services, metadata endpoints, or privileged back channels are reachable, the real failure is usually over-broad trust, not just unsafe input handling.

Q: What do security teams get wrong about exception handling?

A: Many teams treat exception handling as a reliability concern and stop there. In security terms, failures can leak internal state, reveal secrets, and expose request details that help attackers move faster. Good governance tests what happens when systems fail, not only when they succeed, because failure paths are often the richest source of intelligence for an adversary.

Q: What is the difference between code-level bugs and software supply chain failures?

A: Code-level bugs live inside the application, while software supply chain failures affect the artefacts, dependencies, and update paths that deliver the application. The difference matters because a secure codebase can still ship compromised software if the build or dependency chain is not trusted. Teams need controls that cover provenance, signing, and release governance, not only static analysis.

Technical breakdown

Software supply chain failures in application risk

The 2025 OWASP Top 10 treats software supply chain failures as a first-class application security problem. That includes compromised dependencies, malicious packages, tampered builds, and insecure updates. The technical shift is important: attackers do not need to break your application logic if they can alter the artefacts, dependencies, or build inputs that shape runtime behaviour. This expands AppSec from source review into provenance, integrity, and release-path assurance. For identity teams, the hidden issue is that build systems and CI/CD pipelines rely on service accounts, tokens, and automation credentials that must be tightly scoped and continuously governed.

Practical implication: treat pipeline identities and build artefact trust as part of the application security control surface.

Why exceptional condition handling is a security control

Mishandling of exceptional conditions covers failures such as verbose error messages, poor exception handling, and unstable crash behaviour. These are not just reliability problems. They can leak data, reveal internal state, or create paths for denial of service and follow-on exploitation. In practice, exception handling becomes a security boundary because it determines what information is exposed when a system fails and whether attackers can force predictable failure states. For programs using secrets, tokens, or delegated access, overly detailed errors can expose enough context to accelerate abuse.

Practical implication: test exception paths with the same rigour as primary code paths, especially where sensitive data or credentials may surface.

Broken access control now absorbs SSRF risk

OWASP’s decision to roll SSRF into Broken Access Control reflects an architectural reality: server-side request forgery often succeeds because a system can be induced to make unauthorised requests on behalf of an attacker. That is an access problem, not only an input-validation problem. The deeper lesson is that internal services, metadata endpoints, and privileged back-channel requests become reachable when trust assumptions are too broad. In identity terms, SSRF frequently becomes a way to abuse ambient credentials or service trust that should never have been implicitly available to the request path.

Practical implication: review every service-to-service trust path as an authorisation problem, not only as a network or input-filtering issue.

Threat narrative

Attacker objective: The attacker aims to turn trusted software delivery and application trust paths into a route for code tampering, data exposure, or privileged execution.

1. Entry occurs when an attacker reaches a vulnerable application path, dependency, or build artefact that has been trusted inside the development lifecycle.
2. Escalation follows when the attacker abuses supply chain trust, exception leakage, or internal request handling to reach privileged services or reveal sensitive execution context.
3. Impact occurs when altered code, exposed data, or unauthorised requests propagate into runtime systems, deployment pipelines, or downstream users.

NHI Mgmt Group analysis

Software supply chain risk is now an identity problem as much as a code problem. The new OWASP category reflects how much of application trust depends on service accounts, CI/CD tokens, and automation credentials. Once those identities are over-scoped or poorly governed, attackers can tamper with builds, packages, or updates without needing a traditional exploit chain. The control gap is no longer only code review. It is also whether machine identities are constrained enough to protect the software lifecycle.

Exceptional-condition handling is a governance issue because failure paths reveal more than normal paths. Verbose errors, unstable crashes, and poor exception design can leak secrets, internal topology, or account context. That is especially dangerous in environments where applications touch tokens, API keys, or delegated service access. The practitioner lesson is simple: security teams should treat failure modes as part of the attack surface, not just as an engineering quality concern.

SSRF becoming part of Broken Access Control is the right conceptual move. SSRF is often a way to make a privileged service act on behalf of an attacker, which means the real issue is who is authorised to cause which request. That maps directly to how IAM teams think about delegation, ambient trust, and service-to-service permission boundaries. Access path overreach: this is the named failure mode the consolidation highlights, and it should push teams to re-test internal trust paths, not just external inputs.

AppSec and identity governance are converging around machine trust. The 2025 Top 10 shows that application risk increasingly depends on how identities are issued, scoped, and monitored inside pipelines and runtime systems. That matters for NHI programmes because the same service accounts and secrets that enable delivery can also amplify compromise. Practitioners should use OWASP’s shift as a prompt to align AppSec, IAM, and PAM controls around the full software lifecycle.

The category update also signals that security measurement has to move upstream. A programme that only tracks application vulnerabilities will miss compromised dependencies, insecure update channels, and failure-path leakage. The more meaningful question is whether teams can prove trust in artefacts, requests, and identities across the build and runtime chain. That is where governance needs to mature next, especially for organisations scaling automation and AI-assisted development.

What this signals

Secrets fragmentation will become harder to ignore as AppSec categories expand. When organisations run multiple secrets managers, pipeline identities, and update paths, the control problem shifts from protecting individual credentials to proving where authority actually lives. That is why the NHI governance conversation increasingly overlaps with supply chain assurance and workload identity controls, especially for teams using OWASP Non-Human Identity Top 10 guidance.

Access path overreach is the signal practitioners should watch most closely. Once SSRF, internal callbacks, and privileged service requests are treated as authorisation problems, teams can no longer rely on perimeter assumptions alone. Programs should align AppSec findings with NIST Cybersecurity Framework 2.0 functions and the OWASP mapping in the 2025 Top 10 so that identity, build integrity, and exception handling are measured together.

The practical next step is to stop separating application trust from identity trust in reporting and remediation. If a pipeline identity can change a build, a secret can outlive its intended use, or an exception can expose enough context for abuse, the risk is governance failure, not isolated technical debt.

For practitioners

• Map pipeline identities to supply chain trust paths Inventory every CI/CD service account, deployment token, and signing credential that can alter build artefacts or release packages. Scope each identity to the narrowest possible repository, pipeline, or environment, and require review for any credential that can influence updates or dependencies.
• Test exception paths for data leakage Add security tests for verbose error messages, stack traces, and crash behaviour in pre-production and production-like environments. Verify that failures do not expose secrets, internal service names, or request metadata that can accelerate exploitation.
• Re-classify SSRF as an authorisation issue Review service-to-service request flows, metadata access, and internal callbacks as permission boundaries rather than only as network paths. Apply allowlists, explicit request mediation, and workload identity controls where internal requests can reach sensitive systems.
• Align AppSec findings to OWASP 2025 mappings Update risk reporting, backlog triage, and threat modelling to reflect the 2025 OWASP Top 10 categories. Use the new taxonomy to separate supply chain failures, access control issues, and exception-handling defects instead of collapsing them into generic injection or dependency risk.

Key takeaways

• OWASP’s 2025 update pushes AppSec toward supply chain integrity, exception handling, and access control rather than isolated code defects.
• The operational gap is not only vulnerability volume but trust fragmentation across build systems, service identities, and failure paths.
• Security teams should align AppSec, IAM, and NHI governance so they can control who and what is allowed to shape software delivery.

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.
• Exception handling: Exception handling is the process for resolving requests that do not fit standard automation paths. In support operations, exceptions often require human judgment, policy override, or manual approval. When AI is introduced, exception handling becomes a key boundary for what the system can safely automate and what it must defer.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• Rule-by-rule OWASP 2025 mapping changes across Semgrep’s 4,000+ rules, useful for teams updating scanning workflows
• Examples of how specific findings are re-categorised under the new Top 10 structure, including injection and access control
• Context on how the new taxonomy affects practitioners using the Semgrep AppSec Platform
• Links to the updated Semgrep Registry mappings for implementation teams that need to operationalise the changes

👉 Semgrep’s full post covers the mapping updates, category changes, and rule examples in detail

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, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity controls to real operational risk across modern security programmes.