TL;DR: OWASP’s 2025 Top 10 keeps Broken Access Control at number one, moves Security Misconfiguration to second, expands supply chain risk into a broader category, and adds Mishandling of Exceptional Conditions, reflecting 589 CWEs and a stronger focus on root causes, according to GitGuardian. The update makes NHI governance, secrets hygiene, and build-chain visibility harder to treat as secondary controls.
At a glance
What this is: OWASP’s 2025 Top 10 reorders application risk around access control, misconfiguration, supply chain failure, and runtime error handling.
Why it matters: For IAM and NHI practitioners, the list reinforces that secrets exposure and overprivileged non-human identities remain core attack paths, not peripheral hygiene issues.
By the numbers:
- OWASP’s 2025 edition analyzes 589 CWEs across the dataset, with 248 mapped into the ten categories.
👉 Read GitGuardian's analysis of the OWASP 2025 Top 10 for NHI and secrets risk
Context
OWASP’s 2025 Top 10 is not just a ranking of application bugs. It is a signal about where modern software delivery is creating the most exploitable trust assumptions, especially where non-human identities, secrets, and access decisions intersect.
For IAM and NHI governance teams, the important shift is that access control, configuration drift, and supply chain compromise are being treated as connected failure modes rather than separate problem domains. That matters because service accounts, CI tokens, API keys, and deployment credentials now sit inside the same blast radius as code and infrastructure.
The pattern is familiar to teams dealing with cloud-native environments, but the 2025 list makes it explicit. What used to be framed as hygiene now reads like an identity control problem with application consequences.
Key questions
Q: How should organisations respond when NHI secrets are exposed in code or CI pipelines?
A: Treat exposure as an identity incident, not just a code cleanup task. Inventory every credential that could have been copied, revoke or rotate them in priority order by privilege and reach, and verify where the secret was used in build or deployment paths. If the token can reach production, the response must assume active misuse until proven otherwise.
A: Broken access control is a policy failure where an identity can do more than intended. Security misconfiguration is a setup failure where defaults, templates, or permissions create that excess access in the first place. In NHI environments, the two often overlap because a mis-set role or secret can create a standing access path that no application check later corrects.
Q: Why do software supply chain failures matter so much for IAM and NHI teams?
A: Because the supply chain is full of machine identities that can be stolen, reused, or abused. A compromised package or build step becomes far more dangerous when the attacker can also capture tokens, keys, or signing credentials. IAM teams need to treat release engineering as an access domain, not only as a software integrity domain.
Q: How can security teams reduce the blast radius of overprivileged NHIs?
A: Scope each non-human identity to one job, one environment, and one time window whenever possible. Remove persistent roles that are only needed during deployment or recovery, and enforce rotation and revocation on a fixed schedule. The smaller the reachable set, the less useful a stolen secret becomes to an attacker.
Technical breakdown
Why broken access control now includes SSRF-style abuse
Broken access control remains the dominant category because many modern attacks do not need code execution if they can coerce a system into acting on behalf of a higher-privilege identity. Server-side request forgery fits here because the attacker is effectively redirecting trust. The application or service makes requests it should never make, often using internal network position or attached credentials that were never meant to be exposed to the requester. In NHI terms, the failure is not only authorization logic. It is also the unchecked power of machine identities embedded in workflows, proxies, and cloud services.
Practical implication: Review service-to-service trust paths and strip unnecessary network and credential reach from every workload identity.
Security misconfiguration as an identity and secrets problem
Security misconfiguration rises when cloud templates, deployment defaults, and environment settings determine access more than application code does. A broad role, a cleartext secret, or an insecure default can create direct identity exposure even when the software itself is otherwise well built. This is why misconfiguration and NHI governance are increasingly inseparable. The problem is not only bad settings at deploy time. It is the accumulation of standing privilege, weak secret handling, and incomplete environment review across pipelines, platforms, and runtime infrastructure.
Practical implication: Treat configuration review, secrets visibility, and entitlement checks as one control family rather than separate tasks.
Software supply chain failures and the new identity attack surface
OWASP’s broadened supply chain category reflects a reality security teams already see in practice: attackers are not limited to poisoning packages. They can target build systems, release pipelines, signing steps, and the credentials that move artifacts through those stages. Once an NHI secret is exposed in source control or CI, the integrity problem becomes an access problem. That is why supply chain defense now requires both dependency hygiene and identity hygiene. If the pipeline can be trusted only when credentials remain secret, then secret detection and rotation are part of supply chain security.
Practical implication: Map every build and release credential to its pipeline stage and make leak detection a release gate.
Threat narrative
Attacker objective: The attacker wants to turn a small secrets exposure into trusted access across the software delivery and runtime environment.
- Entry begins when an attacker finds an exposed token, API key, or cloud credential in code, CI, or a build artifact.
- Escalation follows when that non-human identity carries broad permissions or internal reach, allowing the attacker to move from code access to infrastructure access.
- Impact occurs when the compromised identity is used to tamper with builds, access internal services, or exfiltrate sensitive data from the delivery chain.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access control is now an NHI governance problem, not only an application logic problem. The OWASP update reinforces that attackers increasingly exploit service accounts, tokens, and other machine identities rather than waiting for a classic login bypass. When those identities are overprivileged, the control failure lives in identity governance as much as in code review. Practitioners should treat access paths for humans and non-humans as one policy surface.
Security misconfiguration is the fastest way to turn ordinary automation into standing privilege. Cloud defaults, environment variables, and pipeline settings often outlive the assumptions they were built on. That creates a durable identity risk because the permission survives long after the deployer has forgotten why it existed. Teams should assume every convenience setting can become an access control exception.
Software supply chain failures now include identity leakage as a core failure mode. The article’s shift from vulnerable components to broader supply chain failures matches what NHI governance teams already encounter in CI/CD and release engineering. A leaked secret, not just a compromised dependency, can be the shortest path from build-time compromise to runtime access. The practical conclusion is that supply chain controls must include secret inventory, rotation, and provenance checks.
Mishandling exceptional conditions is a reminder that security breaks at runtime, not only at design time. Error paths, fail-open logic, and partial outages create conditions where identity checks and access controls can behave differently than expected. In autonomous and highly automated environments, that matters because recovery logic may grant more than intended. Practitioners should test failure states with the same discipline they apply to normal flows.
Ephemeral access does not remove trust debt unless the surrounding governance model also changes. Even short-lived credentials can be dangerous when issuance, scope, and revocation are not tightly controlled. The emerging governance challenge is not whether credentials expire, but whether the systems that mint them are trustworthy enough to limit blast radius. Teams should measure identity exposure by scope, not by lifespan alone.
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.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- For a broader view of how exposed credentials become real incidents, see The 52 NHI breaches Report, which documents repeated identity-led failure patterns across environments.
What this signals
Ephemeral credential trust debt: short-lived access still creates residual risk when issuance, scope, and revocation are not governed as one lifecycle. The operational challenge is not only reducing credential lifetime, but proving that the systems granting access are constrained enough to keep blast radius small. Teams that already manage secrets and workload identities separately will struggle to close that gap.
The practical signal for security programmes is that secrets hygiene, pipeline security, and entitlement review are converging into a single control plane. With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec, identity leakage is now a data handling issue as much as an access issue.
For practitioners aligned to broader governance frameworks, the next step is to map machine identity controls to least privilege and continuous verification. OWASP and zero trust both point in the same direction here: reduce standing access, detect leaked credentials earlier, and test whether recovery paths fail closed when the environment goes wrong.
For practitioners
- Inventory all non-human identities Map service accounts, CI tokens, API keys, and certificates to the systems they can reach, then classify them by privilege, environment, and business criticality. Use the inventory to identify orphaned access and standing privilege before you review individual permissions.
- Separate secrets detection from release approval Add secret scanning and leak response to the build and deployment path so credentials are discovered before artifacts ship. Make unresolved exposures block promotion, especially where build systems or distribution channels can convert a small leak into broad access.
- Reduce trust in internal request paths Review SSRF-prone services, proxies, and internal APIs to ensure they do not inherit more network or identity reach than necessary. Limit which workloads can talk to sensitive internal services and remove default access that was added for convenience.
- Tighten configuration and entitlement reviews Audit cloud permissions, infrastructure templates, and environment defaults together so the same review catches mis-set flags, insecure defaults, and overly broad roles. Treat configuration drift as an identity control issue, not only an operations issue.
- Build rotation into incident response When secrets are exposed, rotate them as part of a documented response path rather than as an afterthought. Track which identities were used in the pipeline, which were shared across environments, and which need revocation first.
Key takeaways
- OWASP’s 2025 Top 10 treats access control, configuration drift, and supply chain compromise as linked identity risks rather than isolated bugs.
- For NHI and IAM teams, the central issue is not just secret exposure but the standing permissions attached to exposed machine identities.
- The practical response is to combine inventory, rotation, leak detection, and entitlement review into one governed lifecycle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Access control failures and exposed NHIs are central to the article. |
| NIST CSF 2.0 | PR.AC-4 | The article focuses on permissions, trust boundaries, and access enforcement. |
| NIST Zero Trust (SP 800-207) | Zero Trust is relevant because the article centers on reducing implicit trust in machines and pipelines. |
Apply least-privilege reviews to service accounts, tokens, and build credentials on a recurring basis.
Key terms
- Non-Human Identity: A non-human identity is any credentialed entity that acts on behalf of software, infrastructure, or automation rather than a person. It includes service accounts, API keys, tokens, certificates, bots, and AI agents. In practice, these identities often hold privileged access and require lifecycle governance, just like human identities.
- 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.
- Standing Privilege: Standing privilege is access that remains continuously available rather than being issued only when needed. For non-human identities, it is one of the main reasons a leaked secret turns into a broad compromise. Removing standing privilege reduces the usefulness of stolen credentials and limits attacker reach.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- How GitGuardian maps exposed secrets to NHI Governance workflows across codebases, CI pipelines, and cloud environments
- The specific ways honeytokens act as tripwires for supply chain compromise and secret reuse
- The article’s practical breakdown of how GitGuardian ties secret discovery to rotation tracking and incident response
- The broader rationale behind GitGuardian’s reading of OWASP’s category changes and how that informs implementation
Deepen your knowledge
OWASP Top 10 shifts in NHI governance are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is aligning secrets, access, and pipeline controls to the 2025 risk landscape, it is worth exploring.
Published by the NHIMG editorial team on 2025-11-24.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org