Software supply chain trust gaps are still breaking CI pipelines

At a glance

What this is: Kusari says a compromised Trivy release showed how unpinned workflows and transitive dependencies can turn CI/CD trust assumptions into credential theft and wider supply chain compromise.

Why it matters: For IAM and security teams, this is a reminder that build pipelines now carry identity risk as well as code risk, because compromised automation can expose secrets and expand blast radius across projects.

Context

Software supply chain risk arises when build systems trust external code, actions, or dependencies without enough verification at the point of use. In this case, the trust gap sat inside CI/CD pipelines, where mutable workflow references and hidden transitive dependencies allowed a compromised release artifact to travel farther than teams expected.

The identity angle is practical, not theoretical. When build tooling is compromised, the attacker is not only affecting software integrity but also reaching credentials, tokens, and other secrets that live inside automation, which is why NHI governance and software supply chain governance increasingly overlap. That overlap is typical in modern pipelines, not an edge case.

Key questions

Q: What breaks when a CI workflow depends on mutable action tags?

A: Mutable tags turn a build step into a remote code execution dependency because the workflow resolves whatever code the tag points to at run time. That means the attacker can replace the trusted action body without changing the repository that calls it. Teams should treat tag mutability as a supply chain control failure, not just a versioning preference.

Q: Why do compromised build tools so often expose credentials?

A: CI systems commonly hold deployment tokens, package publishing secrets, and other machine credentials with enough privilege to move code or access services. When a compromised tool runs inside the pipeline, it inherits that trust and can read or misuse those secrets unless the credentials are tightly scoped and isolated.

Q: What are the signs that software supply chain controls are failing in practice?

A: Common warning signs include overreliance on vulnerability lists, weak visibility into third party dependencies, limited scrutiny of developer tooling, and no practical way to audit the full software estate. If teams can only identify known CVEs but cannot assess package provenance, build trust, or dependency risk at scale, their controls are missing the real attack surface.

Q: How should teams respond when a trusted dependency is poisoned?

A: Contain the identity layer first: revoke exposed tokens, rotate credentials, inspect active sessions, and trace which pipelines consumed the poisoned reference. Then rebuild trust from immutable artifacts and verified provenance. The response is less about removing bad code from one repository and more about closing the access paths the compromised code could use.

Technical breakdown

Why unpinned GitHub Actions create a trust gap

GitHub Actions references such as version tags are pointers, not immutable controls. If a workflow uses a moving tag instead of a commit hash, the pipeline is trusting whatever code that tag resolves to at runtime. That is convenient for maintainers, but it creates a governance problem because the build no longer verifies the exact workflow logic that was reviewed. In a supply chain attack, attackers exploit that gap by replacing the trusted code behind the reference while preserving the appearance of normality.

Practical implication: Pin workflow references to immutable commit hashes so reviewed automation cannot be silently replaced later.

How transitive dependencies widen blast radius

A transitive dependency is a package or component pulled in indirectly through another dependency. Teams often do not know they rely on it until a compromise or vulnerability forces inventory work under pressure. That invisibility matters because an attacker only needs one widely used upstream component to reach many downstream builds. Once the compromised artifact is inside the dependency graph, every project inheriting it may inherit the same exposure, even if the team never explicitly chose that package.

Practical implication: Inventory transitive dependencies continuously so a compromised upstream component can be identified before it spreads across builds.

Why SBOMs matter when CI pipelines are compromised

A software bill of materials records which components, and often which versions, were present in a build. In a compromise scenario, that turns incident response from guesswork into a targeted search across affected services, repositories, and releases. Without that record, teams have to reconstruct build history from logs and package traces, which is slower and less reliable. The real operational value is not documentation for its own sake, but the ability to answer which artifacts are affected and where secrets or malicious code may have propagated.

Practical implication: Generate and retain build-level SBOMs so incident responders can map exposure without reconstructing every repository manually.

Threat narrative

Attacker objective: The attacker aimed to poison a trusted open source security tool so downstream pipelines would expose credentials and extend compromise into many projects at once.

1. Entry occurred through malicious changes to Trivy's GitHub Actions and release pipeline, which let the attacker place malicious logic into trusted build automation.
2. Credential access followed when downstream CI runs executed the compromised release and exposed credentials from affected workflows.
3. Impact came from spread across multiple projects, including credential theft and broader compromise of organizations that consumed the poisoned build artifact.

Breaches seen in the wild

• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Build trust has become a governance control, not a developer convenience. The article shows that mutable workflow references and implicit confidence in popular open source tooling let a single poisoned release travel through CI/CD systems. In governance terms, this is not just a software quality issue. It is a control failure over what automation is allowed to execute before code ships.

Credential exposure is now a supply chain outcome. When compromised build tooling executes in CI, the attacker is not only touching code. The attacker is reaching secrets, tokens, and other non-human credentials that pipelines routinely hold. That makes NHI governance part of software supply chain defense, because the exposure path is through machine identities and automation, not just source code.

Immutable verification is the right named concept for this pattern. The issue is not whether teams perform review, but whether they verify the exact artifact that will run after review. This article shows that one-time verification is not enough when tags move and dependencies change underneath the pipeline. Practitioners need controls that bind approval to an immutable commit, artifact, or provenance record.

SBOMs shorten the distance between compromise and containment. The operational problem is not only preventing malicious packages, but knowing where they landed when prevention fails. Continuous build inventory turns a supply chain incident into a bounded response problem instead of a manual audit exercise. That is now part of resilience planning, not merely compliance documentation.

Supply chain security and identity security are converging at the pipeline edge. The compromised build path works because trusted automation can execute with broad access to repositories, registries, and secrets. That means IAM, NHI governance, and software supply chain assurance have to be designed together. Practitioners should treat pipeline trust as a privileged access problem with code attached.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Guide to SPIFFE and SPIRE

What this signals

Immutable workflow pinning is becoming a pipeline trust requirement, not an optional hardening step. The article shows that tag-based references let malicious changes ride through review and into runtime execution. For teams that also manage machine identities, the lesson is clear: issuance and execution controls have to be tied together, because compromised automation can consume secrets with the same ease as a human operator.

Blast-radius control is the real test of supply chain maturity. Once a malicious artifact reaches CI, the question is no longer whether the package was trusted upstream. The question is how fast teams can identify affected services, revoke exposed credentials, and prevent repeat exposure across repositories.

For practitioners

• Pin every workflow reference to an immutable commit hash Replace mutable version tags in GitHub Actions and other CI tooling with commit-hash pins so reviewed workflow logic cannot be swapped after approval.
• Inventory transitive dependencies in build pipelines Maintain a dependency graph that includes indirect packages and actions so hidden upstream exposure is visible before a compromise reaches production builds.
• Generate build-level SBOMs for every release Record the exact versions used in each build so responders can identify affected services quickly when an upstream package or action is compromised.
• Treat pipeline secrets as non-human credentials Scope CI tokens and secret access to the narrowest possible build context, and assume any compromised workflow can abuse those credentials immediately.

Key takeaways

• The compromise exposed a common software supply chain failure mode: teams trust mutable build inputs and only discover the problem after secrets have already been exposed.
• The article connects that failure to downstream credential theft and multi-project impact, which makes build integrity an identity problem as much as a code problem.
• Pinned workflow references, transitive dependency visibility, and build-level SBOMs are the controls that reduce the blast radius when upstream trust fails.

Key terms

• Immutable Workflow Reference: A workflow reference that points to a fixed, unchangeable code revision rather than a mutable tag. This reduces the chance that a trusted dependency can be silently retargeted after approval, but it still needs permission scoping and secret governance to be effective.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Pipeline Trust Gap: The mismatch between the trust a build or release system is given and the level of identity governance it actually receives. It appears when CI/CD accounts, signing identities, and automation tokens can change production outcomes without the monitoring, scope limits, or lifecycle controls usually reserved for privileged access.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need a shared language for machine identity risk, secrets management, and governance.