TL;DR: OWASP’s 2025 Top 10 reflects a structural shift in application risk, with security misconfiguration rising and software supply chain failures widening the attack surface, according to Sprocket Security. Static scans and point-in-time reviews are no longer enough when change itself now drives exposure.
At a glance
What this is: OWASP’s 2025 Top 10 shifts appsec attention toward misconfiguration, drift, and supply chain exposure rather than only code-level defects.
Why it matters: For IAM, PAM, and NHI practitioners, the message is that access, policy, and dependency changes can create the exploit path even when code itself is unchanged.
By the numbers:
- Security misconfiguration surged three spots up OWASP’s 2025 Top 10.
Context
OWASP’s 2025 Top 10 is not just a ranking update. It is a signal that application risk is now driven by change in systems, configurations, and dependencies, not only by defects in the codebase.
That matters to identity teams because modern app environments increasingly fail through overly permissive access, exposed integrations, and third-party components that alter the effective trust boundary. In practice, the security problem is now as much about runtime and governance drift as it is about software flaws.
Key questions
Q: How should privacy teams implement CPRA controls in cloud and API environments?
A: Start by mapping where personal and sensitive personal information actually moves, then enforce purpose-based access and traceable rights workflows across those paths. Cloud and API environments change quickly, so static records are insufficient. The control objective is to prove that collection, use, sharing, deletion, and restriction all match current production behaviour.
Q: Why do software supply chain failures create risk even when application code is unchanged?
A: Because the risk often enters through components around the code, not the code itself. Dependencies, build tooling, CI/CD integrations, and container images can all introduce compromise or trust failure that changes how the application behaves. That means defenders have to govern the assembled delivery path, not just the repository contents.
Q: How do security teams know if recon findings are showing real exposure drift?
A: Look for repeated discoveries of stale subdomains, forgotten documentation, exposed secrets, or orphaned endpoints across different scans and testers. If the same classes of asset keep appearing, the problem is not an isolated bug. It is an inventory and ownership failure that needs governance attention.
Q: What should teams do when third-party dependencies can alter production behavior?
A: Treat third-party influence as part of the trust model and narrow it to the minimum required scope. That means reviewing which packages, actions, APIs, and images can change production behavior, then removing unnecessary privilege and validating the full chain that delivers software into production.
Technical breakdown
Why configuration drift becomes an exploit path
Configuration drift is the gap between the settings you believe are in place and the settings that are actually running. In cloud, container, and API-heavy environments, that gap widens quickly because policy, identity permissions, and deployment states change continuously. A missing deny rule, an overbroad IAM policy, or a lingering debug flag can create exposure without any code change. Traditional scanners see known vulnerabilities, but they often miss whether a misconfiguration is exploitable in the live environment. That is why misconfiguration has become a practical attack surface rather than a housekeeping problem.
Practical implication: validate live configuration state continuously, not only after releases or audit cycles.
How software supply chain failures widen application risk
Software supply chain failures are weaknesses introduced through dependencies, build tooling, CI/CD integrations, container images, and other external components that the application inherits. The risk is not limited to a bad library version. A compromised dependency or exposed build pipeline can create an entry point even when the application’s own code is unchanged. That broadens appsec from code review into ecosystem assurance. It also means dependency scanning alone is incomplete, because knowing what is present is not the same as knowing how an attacker would chain it into access or execution.
Practical implication: assess the security of the assembled delivery chain, not just the source repository.
Why point-in-time scanning loses relevance in dynamic systems
Point-in-time testing assumes the environment stays stable long enough for the result to remain true. Modern applications do not behave that way. Infrastructure updates, policy changes, and automated deployments can reintroduce exposure within hours or days, which makes a one-off validation cycle stale quickly. Continuous testing is the better fit because it measures whether the current environment still matches the intended security posture. In identity terms, this is especially important when access control, service permissions, and third-party trust relationships are being adjusted continuously across the stack.
Practical implication: replace periodic validation with controls that recheck exposure as the environment changes.
Threat narrative
Attacker objective: The attacker objective is to turn routine environmental change into a durable entry point for access, compromise, or downstream deployment abuse.
- Entry begins when a misconfiguration, such as an overly permissive IAM policy or exposed deployment setting, creates a reachable path into the application stack.
- Credential or dependency abuse follows when attackers use that weak control point or a compromised third-party component to expand access beyond the intended trust boundary.
- Impact occurs when the exposed path is chained into application compromise, data exposure, or malicious code delivery before defenders notice the drift.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Misconfiguration is now a first-class attack surface: OWASP 2025 reflects a reality many teams still underweight. In cloud and API-heavy environments, small policy errors can become the easiest way into an application because they are live, reachable, and often invisible to code-focused tooling. For IAM and PAM teams, the lesson is that access governance and appsec are converging around the same failure mode: the environment changes faster than the control record. Practitioners need to treat configuration state as part of the attack surface, not as a deployment afterthought.
Software supply chain exposure has become an identity problem as much as a code problem: Dependencies, build systems, CI/CD integrations, and service accounts now shape whether software can be trusted. When a compromised package, token, or pipeline connection is enough to alter behavior, the governance question shifts to who and what is allowed to speak for the software. That is where NHI governance becomes directly relevant. Unmanaged machine identities, excessive pipeline privilege, and third-party trust sprawl are now part of application risk, not side issues. Practitioners should map trust relationships across the full delivery chain, not only the application boundary.
Configuration drift creates governance debt: The central named concept here is configuration drift exposure, meaning the gap between intended policy and the live state attackers actually encounter. That gap accumulates as automation, updates, and emergency changes alter permissions and settings faster than teams can re-verify them. Static assurance models assume the state they checked still exists; drift breaks that assumption. Security leaders should measure whether controls still match runtime reality, because a control that cannot keep pace with drift becomes a paper boundary.
Continuous validation is becoming the control model that matters: The article points toward a shift from periodic assurance to always-on validation. That matters because modern applications fail through combinations of changes rather than isolated defects. When misconfiguration and supply chain exposure interact, the exploit path often appears only in the assembled system. For practitioners, the right question is no longer whether a category exists in the Top 10, but whether current controls can detect when that category becomes exploitable in your environment.
OWASP’s 2025 update should change programme design, not just scan coverage: Teams that continue to treat OWASP as a checklist will miss the category shift. The useful response is to redesign assurance around live state, dependency trust, and access path verification. That aligns appsec more closely with identity governance, because the decisive risk is now often who can change or speak for the environment. Practitioners should adjust reporting, testing cadence, and ownership so change itself is monitored as a security event.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Identity Security Posture Management (ISPM) Guide
What this signals
Configuration drift exposure: The practical problem is not that teams lack policies, but that live environments move faster than point-in-time assurance can follow. The useful control objective is to detect when runtime state has diverged from approved access and deployment settings, especially in cloud and API-heavy systems.
For identity-led programmes, this is a reminder that IAM and appsec are now coupled at the point where service accounts, pipeline permissions, and third-party trust paths are created. The strongest response is to verify the assembled system continuously, not the design document once per release.
For practitioners
- Continuously verify runtime configuration Track policy, IAM, container, and API settings in the live environment rather than relying on release-time checks or quarterly reviews.
- Map and test the full delivery chain Inventory build systems, CI/CD integrations, dependency sources, and deployment connectors so you can test the assembled system instead of only the codebase.
- Reduce trust in third-party components Review where external packages, actions, APIs, and images can influence production behavior and remove permissions that are not essential to operation.
- Treat drift as a security signal Escalate configuration deltas, unexpected policy expansion, and unreviewed deployment changes as actionable findings rather than routine noise.
Key takeaways
- The 2025 OWASP update shows that appsec risk is increasingly created by misconfiguration, drift, and dependency exposure rather than only by defects in source code.
- That shift matters because live permissions and third-party integrations can create exploit paths that static scans and periodic reviews miss.
- Security programmes need continuous validation of runtime state and software supply chains if they want OWASP categories to reflect real-world exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centers on misconfiguration in API-heavy environments as a dominant application risk. |
| Recommendation — Review API and deployment settings for security misconfiguration and validate them continuously. | ||
| CIS Controls v8 | CIS-5 — Account Management | Overly permissive IAM policies and service permissions are part of the misconfiguration problem. |
| Recommendation — Tighten account and service access to remove standing permissions that create exploitable exposure. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly ties risk to permission drift and overly broad access paths. |
| Recommendation — Continuously review entitlements and authorizations against the live environment, not the last approved state. | ||
| MITRE ATT&CK | TA0003;TA0004;TA0006;TA0008 — Persistence; Privilege Escalation; Credential Access; Lateral Movement | Misconfigurations and compromised supply-chain components can enable escalation and movement through the environment. |
| Recommendation — Map exposure paths to ATT&CK tactics and test whether weak configurations enable escalation or lateral movement. | ||
| SLSA | L3 — Build provenance | The article highlights build and dependency chains as part of modern application exposure. |
| Recommendation — Strengthen build provenance so compromised dependencies and pipelines cannot silently alter production software. | ||
Key terms
- Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
- 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.
- Continuous Penetration Testing as a Service: A delivery model that runs penetration testing as an ongoing process rather than a one-time engagement. It uses change detection, human validation, and remediation loops to keep security findings aligned with the current environment instead of a stale snapshot.
- Runtime State Management: The discipline of recording and governing state transitions in a distributed agent system. It covers what happened, what remains valid, where execution can resume, and how failures are localized and recovered. In production, this state is part of the system’s reliability model, not just an observability byproduct.
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. It helps security and identity practitioners connect machine identity governance to broader access and trust decisions.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org