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.
Expanded Definition
A software supply chain is the full path from code creation to deployment, including source repositories, build systems, package registries, signing services, CI/CD runners, and the machine identities that connect them. In NHI security, the important point is not just software provenance but whether automation is trusted to move credentials, artifacts, and releases with too much privilege.
Definitions vary across vendors, but the governance pattern is consistent: every step that can fetch code, inject secrets, sign binaries, or deploy to production becomes part of the attack surface. The OWASP Non-Human Identity Top 10 frames this as an identity problem as much as a code integrity problem, because service accounts, tokens, and workload credentials often control the pipeline.
This matters in both traditional DevOps and agentic workflows, where an DeepSeek breach style exposure can begin with one compromised credential and end with widespread automation abuse. The most common misapplication is treating supply chain security as a software vendor issue, which occurs when internal build, release, and secrets controls are left outside security review.
Examples and Use Cases
Implementing software supply chain controls rigorously often introduces friction in developer velocity, requiring organisations to weigh faster releases against tighter approval, signing, and verification steps.
- A CI/CD pipeline uses short-lived credentials and scoped tokens so runners can fetch dependencies without holding standing access to production systems.
- Build artifacts are signed and verified before deployment, reducing the chance that a tampered package or malicious dependency reaches customers.
- Secrets are removed from code and pipeline variables, then monitored for leakage in repositories, chat systems, and ticketing tools, reflecting patterns highlighted in the 52 NHI breaches Report.
- Automated release jobs are isolated with least privilege so that a compromise in one runner cannot pivot into signing infrastructure or cloud control planes.
- Dependency intake is checked against policy before merge, especially when AI-assisted code generation creates more machine-written changes than human reviewers can manually inspect.
In practice, this is where guidance from the OWASP Non-Human Identity Top 10 becomes operational: pipeline identities must be governed like production identities, not treated as disposable tooling. Supply chain compromise is often traced back to an overlooked token, a reused secret, or a runner that was trusted far beyond its purpose, as seen in the Reviewdog GitHub Action supply chain attack.
Why It Matters in NHI Security
software supply chain risk becomes an NHI issue because the pipeline is made of identities: automation tokens, deployment roles, signing keys, and temporary credentials. When those identities are over-privileged, the blast radius is much larger than a single repository. The challenge is amplified by secrets sprawl. In The State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, showing that the operational center of gravity has shifted into automation infrastructure.
That shift means revocation, signing, rotation, and environment isolation must be treated as core controls, not afterthoughts. The LiteLLM PyPI package breach and the Shai Hulud npm malware campaign both illustrate how quickly malicious code or leaked credentials can move through trusted publishing paths. In NHI programs, software supply chain security is therefore a control plane issue, not just an engineering hygiene issue.
Organisations typically encounter software supply chain controls only after a poisoned build, leaked signing key, or compromised runner has already forced an incident response and release rollback, 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 Zero Trust (SP 800-207) and NIST CSF 2.0 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 handling across non-human identities in pipelines. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust limits lateral movement from compromised build or runner identities. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management are central to secure software delivery. |
Inventory pipeline identities, remove standing secrets, and enforce least privilege on build and release automation.
Related resources from NHI Mgmt Group
- What is the difference between software supply chain risk and NHI risk?
- What is the difference between SaaS supply chain security and software supply chain security?
- When does SaaS supply chain risk become more dangerous than software supply chain risk?
- Why does AI make software supply chain risk harder to control?
