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

At a glance

What this is: Equixly compares OWASP Top 10 2025 with 2021 and concludes that appsec is moving toward systemic resilience, with supply chain risk and misconfiguration rising sharply.

Why it matters: IAM, PAM, and platform teams should read this as a warning that access control, trust boundaries, and configuration governance now sit closer together in modern attack paths.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Equixly’s analysis of what changed in OWASP Top 10 2025 versus 2021

Context

OWASP Top 10 2025 is not just a reorder of familiar web risks. It shows that modern application security is being pulled toward broader control failures, where access control, configuration, dependency trust, and resilience all interact in the same attack surface.

For IAM practitioners, the identity angle is real: broken access control, authentication failures, and supply chain trust problems all depend on how identities, privileges, and service relationships are governed across code, infrastructure, and runtime. The shift is typical of cloud-native environments, where control boundaries are increasingly blurred.

Key questions

Q: What breaks when broken access control is treated as a purely application-layer issue?

A: Teams miss the service and token boundaries where authorization actually fails. In modern applications, privilege is often expressed through APIs, workload tokens, and internal calls, so a user-centric view leaves the real trust path unprotected. Security teams need to test where authorization is enforced, inherited, and bypassed across the application stack.

Q: Why do cloud-native environments make vulnerability management harder?

A: Because infrastructure changes faster than traditional scan cycles can keep up. Containers, serverless services, and ephemeral workloads can appear and disappear before a quarterly or monthly process finishes, while a single vulnerable image can spread widely. Teams need discovery and remediation that operate continuously, not in fixed review windows.

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: How should teams respond when error handling becomes a security boundary?

A: Teams should test exception paths with the same rigour they apply to normal workflows. If a service fails open, exposes unauthorised data, or skips an auth check when a dependency is unavailable, attackers will look for that path. Resilience and security need to be assessed together, especially in distributed systems.

Technical breakdown

Why broken access control still leads the OWASP Top 10

Broken access control stays at the top because authorization logic is contextual, not pattern-based. A scanner can find obvious injection signatures, but it cannot decide whether one user should reach another user’s record, or whether a service should call an internal endpoint. That makes entitlement validation, object-level authorization, and trust boundary checks harder to automate than syntax flaws. The 2025 list also folds SSRF into this category, showing how OWASP is broadening access control to include server-to-server trust decisions as well as user permissions.

Practical implication: teams need authenticated, role-aware testing that validates object-level authorization and internal request boundaries, not just generic vulnerability scanning.

Security misconfiguration as an operational control problem

Security misconfiguration climbs because modern environments expose more control planes than code alone can safely manage. Cloud roles, container permissions, headers, secrets, and XML parsers all carry security consequences when defaults, inheritance, or YAML drift are wrong. This is not a single bug class. It is a governance problem created by rapid infrastructure change, shift-left ownership, and inconsistent runtime baselines. Point-in-time audits miss too much because deployment velocity now outpaces manual review cycles.

Practical implication: continuous configuration validation must be built into CI/CD and runtime monitoring so misconfigurations are caught at deploy time, not at the next audit.

Software supply chain failures widen the trust model

Software supply chain failures expand the scope from vulnerable components to the full path of acquisition, build, and distribution. That includes third-party libraries, transitive dependencies, CI/CD systems, package registries, and the integrity of build outputs. The important shift is that many of these failures do not map cleanly to CVEs because the defect is in trust, not code. In practice, this means the security model must cover who can introduce code, who can sign it, and which systems are trusted to move it into production.

Practical implication: teams should extend control testing to build pipelines, dependency provenance, and release trust so supply chain abuse is treated as a core appsec risk.

Threat narrative

Attacker objective: The attacker wants to turn a trusted software path or internal control gap into broader access, code influence, or downstream compromise.

1. Entry begins when an attacker exploits broken access control, misconfiguration, or a compromised dependency path to reach a trusted application, API, or build environment.
2. Escalation follows when the attacker uses weak authorization boundaries, exposed infrastructure controls, or trusted CI/CD processes to gain broader access or inject malicious logic.
3. Impact occurs when the attacker pivots into data theft, service manipulation, or supply chain contamination that propagates beyond the original application boundary.

NHI Mgmt Group analysis

Broken access control is increasingly a governance failure, not just a coding flaw. The 2025 ranking reinforces that entitlement logic is still the hardest appsec problem because it depends on business context and object ownership. In identity terms, this is where authorization, RBAC, and API security intersect most sharply. Practitioners should treat access control testing as a core governance control, not a niche AppSec exercise.

Security misconfiguration now functions as a control-plane exposure problem. Cloud-native systems spread decision-making across IAM roles, container policies, headers, and infrastructure templates, so the security outcome depends on how consistently those layers are governed. This is the same reason identity teams see mis-scoped roles and over-permissive service accounts become attack accelerants. Practitioners should align configuration management with access governance instead of treating them as separate disciplines.

Software supply chain failures create a provenance gap that conventional vulnerability management cannot close. The category is important because many compromises do not arrive as exploitable code defects but as trusted artefacts, build paths, or release processes. That makes provenance, signing, and pipeline integrity part of the security model. Practitioners should assume trust in upstream software must be continuously verified, not inherited.

Auth and supply chain controls are converging into the same risk conversation. Once identity, build systems, and infrastructure all contribute to whether code is trusted, no single team can own the full control surface. This is where IAM, PAM, and appsec programmes need shared assurance models. Practitioners should coordinate on who authorises code, who authorises access, and who verifies release integrity.

Exceptional-condition handling is a resilience issue with security consequences. Mishandling failure paths matters because modern systems often fail open when error logic is weak, incomplete, or untested. That creates exploitable gaps in authentication, authorisation, and service continuity. Practitioners should test failure states as thoroughly as success paths, because attackers look for what happens when systems do not behave normally.

What this signals

Supply chain governance is now part of identity governance. When build systems, package registries, and release pipelines become trusted execution paths, the identities that matter are not only human users but also the service accounts, tokens, and automation behind software delivery. Teams should map which identities can alter provenance, approve artefacts, or bypass release checks, because that is where trust can be converted into compromise.

Misconfiguration and authorisation failures are converging into the same control conversation. In practice, overly permissive cloud roles and weak object-level access checks often compound each other, which means separating appsec from IAM produces blind spots. Practitioners should treat entitlement review, policy-as-code, and runtime validation as one control chain rather than disconnected tasks.

Failure-path testing will matter more as systems become more distributed. The 2025 OWASP shift suggests attackers gain leverage where systems fail open, lose context, or rely on assumptions about upstream integrity. Teams should prepare to test not only steady-state access but also what happens when an identity check, dependency, or configuration control breaks under pressure.

For practitioners

• Re-test object-level authorisation paths Build authenticated test cases for user-to-user, tenant-to-tenant, and service-to-service access checks. Focus on resources that should never be reachable through ID guessing, parameter tampering, or API chaining. This is where broken access control hides most often.
• Continuously validate cloud and runtime configurations Automate checks for overly permissive IAM roles, exposed management interfaces, insecure headers, and misconfigured container settings in CI/CD and at runtime. Treat configuration drift as an active control failure, not an audit finding.
• Extend trust controls to the software supply chain Require provenance checks, signing verification, dependency review, and pipeline segmentation for build systems and registries. Track which identities can publish, approve, and promote artefacts into production.
• Test failure states, not just happy paths Model what happens when authentication, error handling, or upstream dependencies fail. Verify that services deny by default, preserve isolation, and do not leak access when exceptions occur.

Key takeaways

• OWASP Top 10 2025 shifts appsec toward control failures that span access, configuration, and supply chain trust.
• The ranking change matters because modern exploit paths increasingly cross identity, infrastructure, and build boundaries before they reach data or runtime impact.
• Practitioners should test authorisation, configuration, provenance, and failure handling as one connected assurance problem.

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.
• Failure-Path Testing: Security testing that verifies what a system does when dependencies, authentication checks, error handling, or external services fail. It is distinct from happy-path validation because attackers often look for conditions where the software fails open, leaks data, or skips enforcement.

What's in the full article

Equixly's full blog post covers the technical comparison this post intentionally leaves at the strategy layer:

• The detailed 2021 to 2025 category-by-category comparison, including how each OWASP risk moved and why.
• The article’s deeper treatment of SSRF, broken access control, and the way OWASP is reframing trust boundaries.
• The breakdown of supply chain, misconfiguration, and authentication changes across cloud-native and API-heavy environments.
• The relationship between the web Top 10 and the OWASP API Security Top 10 for practitioners deciding which standard to apply.

👉 Equixly’s full post covers the category shifts, API security relationship, and the practical reading of each ranking change.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security practitioners connect identity controls to the broader access and trust decisions their programmes depend on.