OWASP Top 10 2025 elevates supply chain and LLM risk

At a glance

What this is: This analysis argues that OWASP Top 10 2025 reflects a broader appsec shift toward supply chain integrity and LLM risk.

Why it matters: It matters because IAM, PAM, and NHI practitioners increasingly have to govern secrets, tool access, and pipeline privilege across human and AI-driven development workflows.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Cycode's analysis of OWASP Top 10 2025 and AI-driven appsec risk

Context

OWASP Top 10 2025 is best read as a governance signal, not just a vulnerability list. The article's primary message is that application security now has to cover software supply chain integrity, AI-generated code, and LLM-specific misuse as one continuous control problem, especially where secrets, CI/CD access, and runtime trust intersect with IAM and NHI governance.

That shift matters because traditional appsec programmes were built around isolated defects and periodic testing. In practice, modern SDLCs expose credentials, dependencies, and automation paths that blur the boundary between human developers, service accounts, and AI-assisted tooling.

For identity teams, the real issue is who or what can introduce, move, or abuse privileged material across the delivery chain. Cycode's starting position is increasingly typical for organisations trying to reconcile appsec with identity governance.

Key questions

Q: How should security teams govern AI agents and LLM tools in the SDLC?

A: Treat AI agents and LLM integrations as privileged workloads with explicit identity, task scope, and approval boundaries. Give them only the APIs, repositories, and data sources they need, then log tool use and require human approval for sensitive actions such as releases, signing, or permission changes.

Q: Why do software supply chains create identity governance risk?

A: Because the identities that sign, build, approve, and deploy software can change the final outcome more than the code itself. Service accounts, CI tokens, and release credentials often have broad privileges and weak lifecycle controls. If those identities are not governed, the supply chain can be compromised without a visible perimeter breach.

Q: What breaks when secrets are stored in code and CI/CD tools?

A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.

Q: Who is accountable when an AI coding tool introduces insecure code into production?

A: Accountability stays with the organisation that allowed the tool to operate without enforced guardrails. The model is not the accountable party. Security, engineering, and platform owners share responsibility for defining policy, enforcing it at runtime, and logging the decision trail that proves controls were applied.

Technical breakdown

Software supply chain risk now spans the full SDLC

Software supply chain risk no longer means only vulnerable libraries. It includes source repositories, build systems, signing keys, CI/CD integrations, artifact registries, and deployment workflows. Once any one of those control points is compromised, malicious code or exposed secrets can move downstream with the appearance of legitimacy. The article correctly treats provenance, inventory, and policy gates as a linked control chain rather than separate hygiene tasks. For IAM and PAM teams, the important point is that every automated step in delivery has an identity and permission footprint.

Practical implication: map every build and release identity to a named owner and restrict its permissions to the minimum required.

LLM risks are governance problems before they are model problems

The OWASP Top 10 for LLM Applications matters because model misuse often starts with trust boundary failure. Prompt injection, tool abuse, and confused-deputy behaviour occur when an LLM is allowed to mix untrusted input with privileged actions or sensitive context. Security controls therefore need to separate prompts, tools, data sources, and approval boundaries. This is where agentic AI security meets NHI governance: the model itself may not be a human user, but its runtime access still has to be authenticated, authorised, and constrained like any other privileged workload.

Practical implication: treat AI agents and LLM integrations as governed identities, not as neutral application components.

Continuous testing is replacing periodic sign-off as the control model

Cycode's article pushes a continuous control model because static review cannot keep pace with automated code generation and rapid dependency change. Shift-left testing still matters, but it is no longer enough without runtime observability, provenance checks, and policy enforcement across the delivery pipeline. The main architectural shift is from point-in-time assurance to ongoing trust verification. That aligns with modern identity security thinking, where credentials, permissions, and authorisation should be evaluated continuously rather than assumed safe after initial approval.

Practical implication: add continuous integrity checks to CI/CD and alert on privilege drift in build and deployment tooling.

Threat narrative

Attacker objective: The attacker aims to turn trusted development and AI delivery paths into a scalable channel for code execution, secret theft, and downstream compromise.

1. Entry begins when an attacker abuses a compromised dependency, mutable build step, or over-permissive CI/CD integration to insert malicious code or extract secrets.
2. Escalation follows when stolen credentials, signing keys, or pipeline privileges let the attacker make the compromised artefact appear trusted across downstream systems.
3. Impact occurs when poisoned builds, leaked secrets, or manipulated LLM interactions spread through deployments, causing data exposure, tampered releases, or broader compromise.

NHI Mgmt Group analysis

OWASP Top 10 2025 confirms that appsec is now an identity governance problem as much as a code quality problem. Once supply chain compromise, CI/CD privilege, and AI-generated output are in scope, the question is no longer only whether code is vulnerable. It is who can introduce trust into the pipeline, which identities can promote it, and how quickly abuse can propagate across automated delivery. Practitioners should treat privileged build paths as governed identities, not invisible infrastructure.

Software supply chain integrity is the named concept that best captures this shift. The article shows that component risk, build integrity, signing trust, and release promotion now move together. That matters because fragmented controls create false confidence: dependency scanning without pipeline protection still leaves the release path exposed. Security leaders should align inventory, provenance, and release authority under one control model.

AI-generated code multiplies the governance burden rather than replacing it. The problem is not only that models can produce insecure code, but that they can do so at speed and at scale across human and machine contributors. This creates a policy gap where old approvals assume a human developer model that no longer exists in practice. Practitioners should redefine SDLC guardrails around behaviour and permission, not around authorship alone.

LLM abuse becomes much harder to contain when tool access is treated as a convenience layer. Prompt injection and confused-deputy failures exploit the same weak trust assumptions that privilege escalation does in conventional systems. If an LLM can call internal tools, access repositories, or move data without task-scoped boundaries, it behaves like an over-entitled NHI. Security teams should place explicit authorisation between model output and action execution.

Appsec programmes will increasingly be judged on continuous control, not episodic testing. The article's emphasis on automated inventory, testing, and policy-driven controls reflects the direction the market is heading. That aligns with NIST-CSF and OWASP-NHI-style governance thinking, where visibility and enforcement must persist across the lifecycle. Practitioners should expect audit questions to move from whether scanning exists to whether trust is continuously validated.

What this signals

Software supply chain integrity has become a control plane issue, not just an AppSec issue. As AI-generated code and third-party dependencies proliferate, identity teams need to know which automation paths can sign, promote, or deploy code. The practical shift is toward continuous entitlement review for build and release identities, not just human access reviews.

NHI governance now extends into development tooling. Service accounts, tokens, and signing keys used by pipelines can create the same blast radius problems that production workloads do when they are left with standing privilege. The strongest programmes will align CI/CD permissions with least privilege and measured exposure windows.

The 27-day remediation gap for leaked secrets shows why visibility without action is weak assurance. When combined with AI-assisted development and multiple secrets managers, the programme signal is clear: centralise ownership, shorten secret lifetime, and instrument revocation as an operational metric.

For practitioners

• Implement identity-aware pipeline governance Assign a named owner to every source control, build, signing, and release identity, then review its privileges against task scope and approval boundaries.
• Enforce provenance checks before promotion Require signed builds, dependency verification, and artifact attestation before code can move from test to production environments.
• Constrain AI tools to task-scoped access Limit LLM and agent tool calls to the minimum internal APIs, repositories, and data stores needed for the task, then log every escalation path.
• Add secrets controls to CI/CD and developer workflows Scan for exposed credentials in code, workflows, and logs, and rotate any leaked secret on a governed schedule rather than waiting for incident response.

Key takeaways

• OWASP Top 10 2025 reflects a broader move from isolated application bugs toward supply chain, pipeline, and AI-assisted delivery risk.
• The identity problem is growing inside the SDLC itself, where service accounts, tokens, and signing keys can be used to make malicious artefacts appear trusted.
• Practitioners need continuous provenance, task-scoped privilege, and secrets governance if they want appsec controls to keep pace with AI-driven development.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• LLM Prompt Injection: LLM prompt injection is an attack that uses crafted input to override or redirect a model's intended behaviour. It becomes dangerous when the model can call tools, access data, or trigger actions, because the injected instruction can turn into a real operational change.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full article

Cycode's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific mappings between OWASP Top 10 2025 categories and SDLC control points across source control, CI/CD, and runtime
• Examples of continuous remediation workflows for exposed secrets, signed artefacts, and dependency verification
• Implementation guidance for LLM and AI-generated code risk controls inside application security programmes
• Practical policy gate ideas for teams that need to reduce OWASP 10 exposure without slowing delivery

👉 Cycode's full post covers supply chain incidents, LLM risk categories, and SDLC control recommendations in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger access controls. It is designed for teams that need to connect identity governance to modern delivery and automation risks.