TL;DR: OWASP Top 10 2025 shifts application security toward software supply chain failures and LLM-specific threats, with Cycode framing the update as a call for continuous inventory, automated testing, and policy-driven controls across the SDLC. The practical consequence is that security teams must govern code, dependencies, pipelines, and AI-generated output as one risk surface, not separate problems.
At a glance
What this is: Cycode’s analysis says OWASP Top 10 2025 reorients appsec toward software supply chain failures and LLM-specific threats, with the biggest risk shift sitting in the SDLC rather than isolated application bugs.
Why it matters: This matters because appsec teams now have to govern code, dependencies, pipelines, and AI-generated output as one control surface, which pulls identity, secrets, and runtime trust into the same risk conversation.
Context
The security gap is no longer just vulnerable application code. As software delivery becomes more dependent on third-party packages, CI/CD automation, and AI-generated output, the meaningful control problem shifts to whether organisations can maintain trust across the full software development lifecycle.
OWASP Top 10 2025 reflects that shift by treating ecosystem-level compromise as the core issue. For identity and access teams, the intersection is real: secrets, service accounts, signing keys, and pipeline permissions now shape whether code can be trusted before it ever reaches production.
Key questions
Q: What breaks when software supply chain controls are only partially automated?
A: Partial automation creates inconsistent enforcement, which means some builds are protected while others slip through manual exceptions or forgotten paths. That weakens trust in the whole release process. The practical consequence is asymmetric risk, where attackers only need to find one unprotected route to get a compromised artefact into production.
Q: Why do LLM-powered applications need more than access control to stay secure?
A: Access control limits who can reach the system, but it does not control what the model may do once it is invoked. LLM applications can still leak data, follow malicious prompts, or produce unsafe outputs. Security teams need content controls, runtime monitoring, and behavior validation so trust is based on both permission and observed model action.
Q: What are the signs that an SDLC policy is failing in practice?
A: Common warning signs include production changes that bypass review, poor separation between development and production data, unclear ownership of code changes, and missing records for testing or approval. If teams cannot quickly explain who changed what, when it was approved, and how it was verified, the SDLC policy is not providing real control.
Q: How should appsec teams govern supply chain and LLM risk together?
A: They should use one control model for source, build, dependency, and AI-assisted development paths. The practical goal is to align inventory, policy gates, and runtime monitoring so the same trust rules apply whether code was written by a person, generated by a model, or pulled from a third-party package.
Technical breakdown
Software supply chain risk now spans the full SDLC
Software supply chain risk is no longer confined to vulnerable open-source components. It includes source control, build steps, dependency registries, signing keys, CI/CD permissions, and artifact promotion, because compromise at any one point can alter what is delivered downstream. The architectural shift matters: the security question becomes whether the delivery chain is provable, not just whether the code compiles. That is why SBOMs, provenance, and continuous verification sit closer to the centre of modern AppSec programs than one-off scans do.
Practical implication: Treat provenance, dependency inventory, and pipeline integrity as control requirements, not optional hygiene.
LLM-specific threats behave like new application attack surfaces
LLM risks sit alongside classic AppSec issues but behave differently because the model can be influenced by prompts, context, tools, and integrated data sources. That means the attack surface includes prompt injection, confused-deputy behaviour, tool misuse, and insecure handling of model output. The governance challenge is to separate trusted instructions from untrusted input and to constrain what the model can do once it is engaged. In practice, AI features should be assessed as part of the application trust boundary, not treated as a separate innovation layer.
Practical implication: Define explicit tool boundaries and validation rules for any workflow that lets an LLM act on data or systems.
Policy gates are replacing ad hoc security reviews
The article’s underlying direction is toward continuous control enforcement rather than manual, after-the-fact review. Policy-driven gates, automated testing, and runtime observability are necessary because both human and AI-generated code can introduce the same classes of defects at speed. This is where governance becomes operational: the organisation needs repeatable decision points that stop untrusted artifacts, unauthorised changes, and unsafe model outputs from moving forward. Without those gates, developer velocity simply outruns control coverage.
Practical implication: Move security decisions into CI/CD policies so risky changes are blocked before release.
Threat narrative
Attacker objective: The attacker wants to turn trusted delivery mechanisms into a distribution channel for tampered code, exposed secrets, or manipulated application behaviour.
- Entry occurs through compromised dependencies, mutable build artefacts, stolen signing keys, or over-permissive CI/CD integrations that let adversaries influence the software supply chain.
- Credential access and privilege abuse follow when attackers steal secrets, pipeline tokens, or maintainer credentials and use them to alter trusted build or release paths.
- Impact is achieved when malicious code, poisoned packages, or unsafe model-driven output is shipped downstream into production systems and partner environments.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- GemStuffer RubyGems campaign 2026: AI agents attributed to OpenAI mass-created RubyGems accounts, ran code on RubyDoc build servers and probed a flaw to steal API keys.
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
Software supply chain trust is now an identity problem as much as a code problem. Once build systems, package registries, and signing keys become the trust anchor for delivery, the question is who or what is allowed to introduce change. That makes secrets governance, maintainer authentication, and pipeline privilege part of AppSec governance rather than a separate operational concern. Practitioners should treat provenance as a control plane, not a reporting artefact.
LLM risk should be read as a governance extension of application risk, not a special case. Prompt injection, tool misuse, and insecure output handling matter because they let untrusted input influence actions inside a business workflow. The important shift is that the model is not the only thing under test; the delegated permissions around it are under test too. Security teams should judge AI features by the boundaries they enforce, not by the novelty of the interface.
Policy-driven controls are becoming the only scalable way to manage SDLC trust. Manual review cannot keep pace with dependency churn, AI-generated code, and automated release pipelines. The named concept here is continuous trust enforcement: security must verify every artifact and every permission as the software moves, not only after it lands. This changes AppSec from a point-in-time review model to a lifecycle governance model.
OWASP Top 10 2025 validates that supply chain and model risk now share the same control logic. Both depend on knowing what enters the build, what is allowed to execute, and what can reach production without adequate inspection. That convergence means security leaders can no longer split AppSec, AI governance, and secrets management into disconnected programmes. The practical conclusion is to align controls, telemetry, and ownership across all three.
Teams that ignore delivery-chain trust will keep mistaking speed for maturity. The article’s direction is clear: faster software delivery only becomes safer when trust boundaries are measurable and enforced. That means governance around source control, CI/CD, dependency intake, and AI-assisted coding has to be explicit. Practitioners should expect audit questions to move from 'did you scan it' to 'can you prove what you shipped and who could change it?'
From our research library:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Agentic AI Security Guide
What this signals
Continuous trust enforcement: AppSec teams are moving toward a model where every artifact, dependency, and pipeline permission must be verifiable before promotion. That changes the operating question from whether a control exists to whether the control is enforced at the moment trust is granted.
The identity bridge is now unavoidable. Secrets, signing keys, service accounts, and maintainer credentials determine whether a software delivery chain is trustworthy, so IAM and PAM teams need to be part of application security governance rather than invited only after compromise.
OWASP Top 10 2025 is a signal that AI-assisted development will not be governed safely by adding more manual review alone. The programme has to assume faster code creation, more third-party dependency churn, and more machine-generated output, then design policy gates accordingly.
For practitioners
- Audit pipeline trust boundaries Map where code, dependencies, signing keys, and release permissions cross trust boundaries, then remove unnecessary write access from build and deployment paths.
- Enforce provenance checks on artifacts Require signed builds, dependency verification, and artifact attestation before promotion into higher environments, especially where third-party components are introduced.
- Gate AI-generated code with policy Apply the same quality and security gates to AI-generated code as to human-authored code, including dependency review, test coverage, and approval workflows.
- Constrain LLM tool access Limit LLMs and agents to the minimum APIs, repositories, and actions required for their task, and log every tool invocation for review.
- Inventory third-party package exposure Track which projects depend on externally maintained packages and prioritise the ones that can reach build, secrets, or deployment systems.
Key takeaways
- OWASP Top 10 2025 shifts appsec from isolated code defects to ecosystem trust, especially across supply chains and LLM-enabled workflows.
- The control problem now includes source control, build systems, secrets, dependencies, and AI-generated output, not just application-layer bugs.
- Security leaders should align inventory, provenance, policy gates, and runtime monitoring so delivery-chain trust is continuously enforced.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly ties supply chain compromise to exposed CI/CD secrets and signing keys. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party packages, actions, and registries are central to the supply-chain threat pattern described. | |
| Recommendation — Scan build and deployment paths for exposed secrets and revoke any credentials that can alter release integrity. Inventory third-party dependencies that can influence build or release systems and verify their trust posture continuously. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The LLM section focuses on models using tools unsafely or beyond intended boundaries. |
| Recommendation — Restrict agent tool permissions to the minimum required and validate every high-risk action before execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's governance model depends on controlling who and what can change code, secrets, and pipelines. |
| Recommendation — Review pipeline and repository entitlements so only approved identities can modify artifacts or release paths. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The cited incidents rely on stolen credentials and downstream propagation through trusted build channels. |
| Recommendation — Map supply-chain detections to credential access and lateral movement patterns across CI/CD and package ecosystems. | ||
Key terms
- Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
- Continuous Trust Enforcement: A security approach that keeps evaluating whether an identity should retain access after it authenticates. Rather than trusting a session until logout, controls reassess behavior, device posture, privilege changes, and context during the entire session. This helps limit attacker dwell time and supports real-time access reduction or revocation.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps security and IAM teams connect identity controls to modern delivery pipelines. It is a fit for practitioners who need to govern machine trust across SDLC, cloud, and AI-enabled environments.
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