They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software. Signed artifacts, build integrity, and separation of duties matter because attackers frequently abuse the pipeline rather than the package itself. Supply chain governance has to cover provenance, promotion, and update trust.
Why Security Teams Miss the Real Supply Chain Risk
Security teams often over-index on dependency vulnerabilities because they are visible, scannable, and easy to assign to a product owner. The larger failure is the trust path: who built the artifact, which runner signed it, what secrets were available during build, and whether promotion into production was gated by meaningful policy. That is where attackers usually win, as shown in incidents such as the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign.
The practical problem is that package trust, build trust, and update trust are often managed in separate silos. That fragmentation creates gaps between code review, CI/CD execution, artifact signing, and deployment approval. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 points toward provenance, least privilege, and continuous validation, but many programmes still stop at vulnerability management. In practice, many security teams encounter compromise only after a malicious pipeline credential or poisoned build has already been used to ship trusted software.
How Software Supply Chain Risk Actually Shows Up in Practice
Supply chain risk is rarely just a bad library. It is usually a trust breakdown in the pipeline that turns ordinary build systems into credential harvesters or artifact forgers. The most effective attackers abuse what already has permission: CI runners, signing jobs, release workflows, package publish tokens, and update channels. NHIMG research on the LiteLLM PyPI package breach and the 52 NHI breaches Report shows how non-human identities and pipeline trust paths become the real blast radius.
Operationally, strong supply chain governance should cover:
- Artifact provenance, including signed builds and verifiable attestations.
- Separation of duties between code authoring, build execution, signing, and release promotion.
- Ephemeral credentials for CI/CD rather than long-lived secrets embedded in runners or repository variables.
- Policy checks at promotion time, not just at commit time, so tampered artifacts cannot pass silently into production.
- Continuous verification of who or what is requesting publish, deploy, or update authority.
That model aligns with current best practice in the OWASP Non-Human Identity Top 10 because CI systems, signing services, and package publishers are all non-human identities that need scoped trust, rotation, and auditable use. It also fits the NIST CSF emphasis on supply chain risk management, but only if teams treat runners and release automation as high-value identities rather than background infrastructure. These controls tend to break down in fast-moving monorepos with shared runners because over-permissioned automation becomes both the attacker’s entry point and the trusted release path.
Where the Standard Advice Breaks Down
Tighter supply chain controls often increase delivery overhead, requiring organisations to balance release velocity against verifiable trust. That tradeoff becomes especially visible in environments with many microservices, frequent dependency updates, or external package publishers, where every added approval can slow shipping.
There is no universal standard for this yet, but the direction is clear: provenance is more important than static trust, and static allowlists age poorly. Teams should be cautious about relying on a single control such as SLSA level targets or dependency scanning alone, because those measures do not fully address update trust, build isolation, or secret exposure inside pipelines. The Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same point: when machine identities are over-privileged, attackers do not need to break the software itself.
The hard edge cases are vendor-managed build services, legacy release tooling, and organisations that reuse the same signing key or publish token across multiple products. In those environments, the right answer is usually narrower trust domains, shorter-lived credentials, and policy enforced at runtime rather than a one-time architecture decision.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while 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-03 | Covers weak lifecycle control of machine credentials used in pipelines. |
| OWASP Agentic AI Top 10 | A1 | Pipeline automation behaves like autonomous tooling with delegated authority. |
| NIST CSF 2.0 | ID.SC-4 | Supply chain trust and third-party risk are central to the question. |
Map artifact, runner, and publisher trust relationships into supply chain risk controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
