OWASP Top 10 2025 shifts appsec toward root causes

At a glance

What this is: OWASP Top 10 2025 refocuses application security on root causes, with access control, misconfiguration, supply chain, and integrity failures taking sharper shape.

Why it matters: For IAM, NHI, and appsec teams, the update shows that identity governance and configuration hygiene are now core application security controls, not supporting concerns.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Orca Security's analysis of the OWASP Top 10 2025 release candidate

Context

OWASP Top 10 2025 is an application security risk model that now leans more explicitly into root causes such as access control failure, misconfiguration, supply chain weakness, and integrity breakdown. For IAM and NHI programmes, that matters because many appsec findings are ultimately identity problems expressed through code, pipelines, and runtime trust.

The shift from symptom labels to cause labels changes how security teams should read application risk. If a control failure can be traced to privilege, provenance, or configuration trust, then the boundary between appsec, IAM, and workload identity governance is thinner than many operating models assume.

The 2025 release candidate is therefore not just a list refresh. It is a reminder that modern applications fail where identity, configuration, and software provenance intersect, and that is now a baseline concern for cloud, platform, and security architecture teams.

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 security misconfigurations keep creating major exposure in cloud environments?

A: Because configuration is now part of the runtime control plane, not a one-time setup task. Default permissions, exposed services, and drift across environments can create persistent access that is hard to notice and harder to retire. Continuous verification is the only reliable way to keep configuration aligned with intended trust.

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 organisations decide whether appsec, IAM, or platform teams own a control failure?

A: They should assign ownership based on where the trust decision is made, not where the symptom appears. If the issue is authorization, configuration, signing, or lifecycle of a secret, the fix spans appsec and identity governance. Shared control ownership is often the only realistic model for root-cause remediation.

Technical breakdown

Broken access control in modern applications

Broken access control remains the category that catches privilege escalation, token manipulation, insecure direct object reference, and service-level access abuse. In cloud-native systems the control boundary is rarely a single user session, because APIs, microservices, and workload tokens extend the trust surface beyond the browser. When SSRF is folded into access control, OWASP is signalling that a request path can become an authorization path if the application lets internal calls inherit excessive trust. That makes authorization enforcement a server-side design problem, not a front-end validation problem.

Practical implication: review application authorization paths at the service and token boundary, not only at the user login boundary.

Security misconfiguration and cloud permissions

Security misconfiguration covers default accounts, missing hardening, unsafe permissions, exposed services, verbose errors, and cloud storage mistakes. The 2025 framing matters because configuration drift now creates durable exposure across environments that are deployed quickly and changed often. In practice, misconfiguration is less about one bad setting and more about the absence of repeatable configuration control, drift detection, and verification. For IAM teams, that means permissions, secrets handling, and runtime settings need continuous governance rather than periodic review.

Practical implication: treat configuration verification as a continuous control, especially where cloud permissions and service defaults can expand blast radius.

Software supply chain failures and integrity checks

Software supply chain failures now span build systems, package sources, updates, third-party tooling, and delivery infrastructure, not just known vulnerable components. OWASP’s shift reflects a broader threat reality: the question is no longer only whether a dependency is vulnerable, but whether it was delivered, updated, or altered through a trustworthy path. Software or data integrity failures sit alongside this by focusing on whether the artifact itself was verified before execution. Together, they describe a provenance problem that identity controls alone cannot solve without signed builds, trusted pipelines, and strong separation of duties.

Practical implication: verify provenance and integrity at build and deployment time, not only during vulnerability scanning.

Threat narrative

Attacker objective: The attacker aims to convert application trust assumptions into unauthorized access, tampered software, or exposed data at scale.

1. Entry begins when an attacker abuses weak access control, exposed internal request paths, or insecure configuration to reach a trusted application or pipeline boundary.
2. Escalation follows when privilege, token trust, or unsigned software paths are used to expand access across services, dependencies, or update channels.
3. Impact occurs when the attacker manipulates data, code, or runtime trust to cause exposure, tampering, or delivery of malicious functionality.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OWASP Top 10 2025 is really an identity governance document in appsec clothing. The list now concentrates on access control, configuration, provenance, and integrity because those are the control planes where modern applications fail. That is why IAM, PAM, and NHI teams should read this update as a map of where application trust is breaking, not as a pure developer checklist.

Software supply chain failures are now a provenance problem, not just a vulnerability problem. The category has expanded because the industry has learned that trusted build paths, package ecosystems, and CI/CD tooling can be abused without a conventional exploit in the application layer. The practitioner conclusion is that identity, signing, and separation of duties must cover the path that produces software, not only the software that runs.

Security misconfiguration and broken access control are converging into one operational failure mode: excessive trust at runtime. APIs, microservices, and cloud services blur the line between privileged infrastructure access and application authorization. That means governance teams need to stop treating configuration drift, token misuse, and over-permissioning as separate problems, because they now define the same exposure surface.

Cryptographic and integrity controls are becoming board-relevant because they decide whether trust is verifiable at all. OWASP’s move away from symptom language shows that teams need to think in terms of broken trust chains rather than isolated defects. The practical conclusion is simple: if provenance, keys, and verification are weak, the rest of the control stack inherits that weakness.

Root-cause framing improves prioritization, but it also raises the bar for control ownership. When a finding can be traced back to access, configuration, or supply-chain governance, appsec cannot own the entire fix alone. The implication for practitioners is to assign responsibility across application, IAM, platform, and build teams before the same failure reappears in a different layer.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader NHI control baseline, see Ultimate Guide to NHIs - Key Challenges and Risks, which frames the visibility and over-privilege issues that appsec teams now inherit.

What this signals

Broken access control and misconfiguration are now operational identity problems, not just appsec defects. Teams that separate application security from IAM will miss the runtime trust paths where API calls, workload tokens, and cloud permissions intersect. The practical signal is that control ownership needs to span code, identity, and platform teams, with clear accountability for each trust boundary.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the exposure problem is no longer hypothetical. That volume shows why provenance, secret handling, and deployment integrity belong in the same operating model. If your programme cannot see secrets, ownership, and build paths together, it is reacting to symptoms after the trust breach has already occurred.

Supply chain governance is becoming the deciding factor in whether root-cause fixes stick. The industry should expect more attention on signed artifacts, controlled promotion, and dependency provenance because those controls reduce recurrence across multiple OWASP categories. For practitioners, the next step is to map OWASP categories to the lifecycle controls that actually prevent repeat exposure.

For practitioners

• Map appsec findings to identity and authorization boundaries Trace broken access control findings to the service, token, and API layers where trust is actually enforced. Use this to identify where application code depends on identity decisions that are currently assumed rather than verified.
• Harden configuration control across cloud and runtime settings Automate baseline hardening, drift detection, and permission verification for cloud services, storage, and application runtimes. Keep misconfiguration review continuous rather than tied to project milestones.
• Verify software provenance before deployment Require signed builds, controlled artifact promotion, and clear separation of duties in CI/CD. Add checks that confirm the artifact, dependency, and update path are trusted before code reaches production.
• Treat secrets and tokens as governance assets Inventory secrets, reduce fragmentation across managers, and tie rotation or revocation to ownership and lifecycle state. Link secrets governance to application delivery so exposure does not persist after code changes.

Key takeaways

• OWASP Top 10 2025 reframes application risk around broken trust, which places identity, configuration, and provenance at the centre of security governance.
• The most relevant control failures are no longer isolated bugs but repeated patterns of excessive access, weak configuration control, and unverified software delivery paths.
• Practitioners should align appsec findings to ownership across IAM, platform, and build teams so root-cause remediation does not stop at code-level fixes.

Key terms

• Broken Access Control: Broken access control occurs when a system lets a subject act beyond the permissions it was meant to have. In modern application environments this often shows up through APIs, service tokens, and internal requests that inherit trust without a fresh authorization check.
• Software Supply Chain Failure: A software supply chain failure is a breakdown in how code, dependencies, builds, or updates are produced and delivered. The problem is not only vulnerable code, but also compromised provenance, unsigned artifacts, unsafe tooling, or weak control over who can change what reaches production.
• Security Misconfiguration: Security misconfiguration is the presence of unsafe settings, default access, exposed services, or missing hardening in a system. It is usually an operational control failure rather than a code defect, which makes continuous verification and drift detection essential in cloud and platform environments.
• Software Or Data Integrity Failure: A software or data integrity failure happens when a system trusts an artifact, update, or payload without verifying that it is authentic and unchanged. The risk is especially high in CI/CD, package delivery, and runtime updates where unsigned or tampered inputs can be executed as trusted code.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: the OWASP Top 10 2025 release candidate and what changed. Read the original.