OWASP Top 10 2025 shifts appsec toward resilience and supply chain risk

At a glance

What this is: Equixly argues that the OWASP Top 10 2025 RC reorients application security toward resilience, with supply chain failure, misconfiguration, and error handling rising in importance.

Why it matters: IAM and AppSec teams should treat authorization, configuration control, and dependency trust as part of the same governance problem, because exploitability now spans code, runtime, and delivery paths.

By the numbers:

• The OWASP Top 10 2025 release candidate places security misconfiguration in second place, up from fifth in 2021.
• Equixly says the security community ranked software supply chain failures as its top concern with 50% of survey respondents.

Context

The core governance gap in this article is that application security is no longer shaped only by code defects. Cloud-native systems, third-party dependencies, and configuration-heavy delivery pipelines have made exploitability depend on how software is built, deployed, and operated, not just on whether individual functions are vulnerable. The primary security question is whether controls still assume a static application perimeter when the real attack surface is distributed across APIs, build systems, and runtime environments.

For IAM and NHI teams, the identity angle sits in authorization logic, service trust, and access to the software supply chain. Broken access control, API authentication, and misconfigured infrastructure all depend on who or what can act inside a system, while machine identities and CI/CD credentials increasingly determine whether attackers can move from one trust boundary to another. That makes this article relevant to both appsec and identity governance programmes.

Equixly’s comparison of the 2021 and 2025 rankings is best read as a control maturity signal. The list is no longer only about finding exploitable flaws in code, but about proving that systems fail safely, dependencies are trusted, and access decisions hold under real operating conditions.

Key questions

Q: What breaks when broken access control is not tested with real identities?

A: Teams miss the decisions that matter most because authorization is contextual. Tests that do not use authenticated users, service accounts, and resource-level permissions can pass while the application still allows one identity to reach another identity’s data or internal function. The failure is usually not in syntax but in business logic and trust boundaries.

Q: Why do misconfigurations and privileged access drift create so much risk in cloud-native environments?

A: Cloud-native systems move fast, so a small error in IAM, pipeline integrity, or infrastructure-as-code can quickly become production exposure. Privilege drift expands the blast radius of a compromise and makes lateral movement easier. The risk is highest when teams lack contextual visibility across code, build, and deployment stages, because they cannot see how the weakness was introduced.

Q: What do security teams get wrong about software supply chain risk?

A: They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software. Signed artifacts, build integrity, and separation of duties matter because attackers frequently abuse the pipeline rather than the package itself. Supply chain governance has to cover provenance, promotion, and update trust.

Q: What should appsec and IAM teams do when a control can fail open?

A: They should test the error path, not just the success path. If an authentication check, dependency lookup, or policy evaluation fails, the system must deny access or degrade safely. Any silent fallback that grants access or suppresses enforcement turns an exception into a security decision.

Technical breakdown

Why broken access control still dominates modern application risk

Broken access control remains the hardest AppSec problem because it is contextual, not syntactic. A scanner can often spot unsafe code patterns, but it cannot reliably determine whether a user, service, or API client should be allowed to reach a given resource. The article also notes that SSRF has been folded into this category, expanding the idea from user-resource authorization to trust boundary enforcement. That matters because object-level access, internal network reachability, and service-to-service permissions are all governed by the same question: who is allowed to access what, and under what conditions?

Practical implication: test authorization decisions with authenticated roles, service identities, and resource-level assertions, not only with unauthenticated scans.

Security misconfiguration as a cloud and infrastructure control failure

Security misconfiguration rises because modern systems expose more configuration surfaces than traditional monoliths did. Cloud IAM roles, container settings, HTTP headers, default accounts, and infrastructure-as-code templates all create opportunities for unsafe defaults to become production exposure. The article’s point is not that code quality collapsed, but that operational complexity outpaced manual review. In this model, misconfiguration is a governance failure across environment, deployment, and runtime layers, which is why point-in-time review misses what continuous deployment introduces. Continuous validation is now a security control, not a nice-to-have.

Practical implication: verify deployed configuration continuously, especially for cloud permissions, default settings, and runtime exposure paths.

Software supply chain failures and the shift from CVEs to trust failures

The new software supply chain category expands beyond vulnerable components to include acquisition, build, and distribution processes. That is a significant shift because many compromises in this space do not map cleanly to CVEs. A dependency may be technically clean while the package source, build pipeline, or release artifact has been tampered with. In practical terms, supply chain security now includes provenance, integrity, and trust in the tooling that assembles software. For identity teams, that also means build and deployment credentials become high-value machine identities whose compromise can turn trusted automation into an attack path.

Practical implication: treat build provenance and pipeline credentials as security assets, not just developer tooling.

Threat narrative

Attacker objective: The attacker seeks to turn weak authorization, unsafe configuration, or compromised software trust into durable access and downstream control of application or deployment assets.

1. Entry begins when attackers exploit misconfiguration, trust-boundary mistakes, or compromised supply chain inputs to reach an exposed application, API, or build path.
2. Credential or access abuse follows when attacker-controlled identities, overly permissive roles, or inherited trust let the intruder pivot into internal services or deployment systems.
3. Impact occurs when unauthorized access, tampered artifacts, or failed error handling expose data, enable persistence, or undermine the integrity of the application estate.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application resilience has become an identity and trust governance problem. The article shows that the old separation between AppSec, IAM, and platform security is no longer defensible. Access control, configuration control, and supply chain trust now interact at runtime, which means governance has to follow the path of execution rather than the perimeter of the codebase. Practitioners should treat authorization and trusted automation as one control surface.

Software supply chain failures are really machine identity failures in disguise. Build systems, package registries, and deployment pipelines are only trustworthy if the non-human identities behind them are tightly scoped and observable. When those identities are overprivileged or poorly governed, the supply chain becomes an access path rather than a delivery mechanism. Practitioners should review pipeline credentials as part of supply chain risk management, not as separate admin hygiene.

Security misconfiguration is the category that exposes governance debt fastest. As cloud and infrastructure complexity rises, the weakest control is often the one assumed to be implicit rather than enforced. That includes default settings, exposed management interfaces, and cloud IAM assumptions that were never validated under real deployment conditions. Practitioners should convert configuration expectations into continuously tested controls.

Resilience testing now needs to cover fail-open behavior as well as vulnerability presence. The replacement of SSRF with mishandling of exceptional conditions shows that security is moving toward whether systems fail safely under abnormal inputs, not just whether they block known exploits. That is a broader governance signal for AppSec and IAM leaders, because error paths often decide whether access is denied or silently granted. Practitioners should test failure handling as a control boundary, not an edge case.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• More than 80% of enterprises will have used generative AI APIs or deployed GenAI applications by 2026, up from 5% in 2023, according to Gartner.
• Read next: API Key Management Guide

What this signals

Fail-open resilience is now a governance requirement, not a niche appsec concern. When systems depend on external code, cloud controls, and delegated identities, the question is no longer only whether a flaw exists but whether the platform behaves safely when validation, lookup, or policy evaluation fails. Appsec teams should map those failure states explicitly and make them test cases, because exception handling is now part of the control boundary.

Software supply chain governance must include the machine identities that operate the pipeline. Build and release systems are only as trustworthy as the credentials that move code, sign artifacts, and publish dependencies. That means inventorying non-human identities, scoping them tightly, and treating pipeline compromise as an identity event as much as a software event.

For practitioners

• Test authorization with authenticated identities Use multi-role and service-account test cases to validate object-level access, tenant boundaries, and API authorization decisions under real credentials.
• Continuously validate cloud and runtime configuration Scan deployed environments for exposed management interfaces, permissive IAM roles, unsafe defaults, and container settings as part of release validation.
• Govern build and release credentials as machine identities Inventory the identities used by CI/CD, package delivery, and artifact publishing, then scope their permissions to the minimum required task.
• Add fail-safe tests for exceptional conditions Exercise error paths, malformed inputs, and dependency failures to confirm the application denies access or degrades safely instead of failing open.

Key takeaways

• OWASP’s 2025 draft ranking shows that appsec is moving beyond vulnerability hunting toward control assurance across access, configuration, and delivery paths.
• The biggest change is not a single new bug class but the recognition that software supply chain trust and exceptional-condition handling can determine exploitability.
• For practitioners, the practical shift is to validate authorization, configuration, and failure behavior continuously instead of relying on periodic testing alone.

Key terms

• 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.
• Security Misconfiguration: Security misconfiguration is a control failure caused by unsafe defaults, incorrect settings, or overly broad permissions in systems and pipelines. In NHI environments, it often shows up as exposed secrets, persistent roles, or permissive cloud templates. The risk is that routine automation becomes a durable access path.
• 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.
• Fail-Open Behaviour: Fail-open behaviour allows output to pass through when a control errors or times out. It preserves availability and avoids silent loss of useful information, but it also accepts the risk of imperfect or incomplete messages reaching the user.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to broader security programmes. It helps security teams translate identity risk into operational governance across modern environments.