Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
Expanded Definition
Software supply chain risk covers the ways source code, package dependencies, build systems, CI/CD pipelines, release artifacts, and deployment definitions can be altered before software reaches production. In NHI operations, the risk becomes sharper when an AI coding assistant or OWASP Non-Human Identity Top 10 style workflow can modify repositories, generate configuration, or trigger automation with credentials attached.
Definitions vary across vendors on whether this term includes only third-party dependencies or also internal pipeline integrity, but no single standard governs this yet. NIST treats software and system integrity as part of broader resilience and risk management in NIST Cybersecurity Framework 2.0, which is a useful baseline for governance even when the threat source is an agent, bot, or build runner. In practice, NHI teams care less about abstract software provenance and more about whether secrets, signed artifacts, and privileged automation can be trusted end to end. The most common misapplication is treating supply chain risk as only a developer dependency problem, which occurs when build and deployment identities are left outside review.
Examples and Use Cases
Implementing software supply chain controls rigorously often introduces more release friction, requiring organisations to weigh delivery speed against stronger provenance, revocation, and review.
- A code assistant proposes changes to infrastructure-as-code, and an over-permissioned service account approves and deploys them without human review.
- A compromised package or post-install script injects malicious logic into a build, similar to patterns seen in the Shai Hulud npm malware campaign.
- A GitHub Action or CI runner leaks tokens during a pipeline run, echoing lessons from the Reviewdog GitHub Action supply chain attack.
- A new internal tool adds dependencies that are never pinned or reviewed, creating an exposure path that only appears after release.
- An agent is allowed to open pull requests, update manifests, and call deployment APIs, but its permissions are not constrained by NIST Cybersecurity Framework 2.0 governance expectations.
NHIMG research shows this is not theoretical: the 52 NHI Breaches Analysis repeatedly shows that identity abuse, exposed secrets, and automation trust failures tend to compound across the delivery chain.
Why It Matters in NHI Security
Software supply chain risk is an NHI issue because non-human identities often hold the keys to source control, package registries, runners, and cloud deployment targets. Once those identities are compromised, the attacker does not need to break into production directly; they can arrive through the path that builds production. That is why supply chain compromise so often becomes a secrets problem, an access problem, and an integrity problem at the same time.
NHIMG research on The State of Secrets in AppSec found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. That matters because runners are often treated as disposable infrastructure, yet they carry highly privileged tokens and short-lived credentials that can still be abused if revocation is weak. The same lesson appears in the DeepSeek breach, where rapid adoption expanded credential exposure faster than guardrails could keep pace. Organisations typically encounter software supply chain risk only after a poisoned build, leaked token, or unauthorized release, at which point the term becomes operationally unavoidable to address.
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-02 | Covers secret and credential exposure in automation and delivery paths. |
| NIST CSF 2.0 | PR.DS | Addresses data and system integrity across software build and release stages. |
| NIST Zero Trust (SP 800-207) | Zero trust principles reduce implicit trust in runners, agents, and deployment tokens. |
Restrict pipeline identities, rotate exposed secrets, and verify release provenance before deployment.
Related resources from NHI Mgmt Group
- What is the difference between software supply chain risk and NHI risk?
- When does SaaS supply chain risk become more dangerous than software supply chain risk?
- How should security teams reduce the risk of secret theft from npm supply chain attacks?
- How should teams reduce identity risk in cloud supply chain attacks?
