Software supply chain trust gaps are still breaking CI pipelines

At a glance

What this is: This is an analysis of how a compromised security scanner and malicious GitHub Actions workflow exposed a software supply chain trust gap that let attackers steal credentials and spread compromise downstream.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly depend on pipeline identities, build artefacts, and delegated trust, all of which can become high-blast-radius access paths when verification is weak.

By the numbers:

• Some companies reported having to audit over 50 active repositories to determine the exact version installed in each workflow run.

👉 Read Kusari's analysis of the Trivy compromise and CI supply chain exposure

Context

Software supply chain security fails when build systems trust mutable artefacts, unpinned actions, and transitive dependencies as if they were stable assets. In practice, a single compromised package or workflow can move from a developer convenience issue to credential theft and cross-organisation impact. The identity angle is real because CI/CD systems increasingly operate through service accounts, tokens, and release automation that behave like non-human identities.

This article is about that trust boundary, using the Trivy compromise as a concrete example of how one malicious workflow can propagate through many downstream projects. That starting position is not unusual; it reflects how modern software delivery still depends on trust more than verification, even where the blast radius is large enough to affect multiple organisations.

Key questions

Q: How should security teams prevent malicious dependencies from reaching CI pipelines?

A: Use immutable pinning, trusted provenance checks, and pull request review for every executable dependency in the pipeline. Mutable tags and indirect package references should be treated as unapproved access paths until they are bound to a known commit or signed release. That reduces the chance that a compromised upstream artefact can execute inside your build environment.

Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?

A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews. If defenders only track direct components, they can miss the code attackers are most likely to exploit. A dependency-aware inventory reduces that blind spot and gives teams a realistic view of what is actually present in production.

Q: How can security teams measure whether supply chain controls are actually working?

A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise. If malicious releases still reach trusted build paths before detection, the controls are not containing trust inheritance.

Q: Who is accountable when a compromised workflow changes trusted release artefacts?

A: Accountability sits with the organisation that defines workflow permissions, release governance, and token lifecycle controls. For auditors, the relevant question is whether automation identities were approved, scoped, monitored, and revocable before the compromise. Frameworks such as NIST CSF and NIST 800-53 place that responsibility under access control and change management.

Technical breakdown

Why unpinned GitHub Actions create a mutable trust boundary

GitHub Actions references such as version tags are convenient, but they are not immutable unless pinned to a commit hash. If an attacker can modify the referenced action or publish a malicious version under a trusted tag, every workflow that consumes that reference inherits the change. That turns the CI pipeline into an implicit trust channel rather than a controlled dependency path. In security terms, the control gap is not only code review, but provenance verification for executable build-time components.

Practical implication: require commit-hash pinning and review of workflow changes before merge.

How transitive dependencies hide exposure until incident response starts

Transitive dependencies are packages or actions brought in by other dependencies rather than directly by the application owner. They are hard to see because they sit several layers deep in the dependency graph, yet they can still execute during builds or runtime. When a compromised package sits in that chain, many teams will not know they are affected until they reconstruct build history, repository by repository. This is why software bills of materials matter: they create an inventory that is queryable under pressure.

Practical implication: maintain an always-current SBOM so affected services can be identified without manual repository audits.

Why blast-radius analysis depends on build provenance, not just vulnerability scores

Risk scoring based on CVSS, EPSS, or known exploited vulnerabilities helps prioritise remediation, but it does not answer the operational question of where a compromised artefact landed. Blast-radius analysis works only when the organisation can map specific builds to specific dependencies and versions. That requires provenance data from the pipeline, not just a vulnerability feed. Without that linkage, teams know something is risky but cannot quickly tell which services are actually exposed.

Practical implication: couple dependency scoring with build provenance so response teams can isolate impacted services fast.

Threat narrative

Attacker objective: The attacker aimed to turn a trusted build dependency into a credential-harvesting and downstream compromise mechanism at scale.

1. Entry occurred when the attacker compromised a widely used security scanner distribution path and inserted malware into GitHub Actions and release artefacts.
2. Credential access followed when downstream projects executed the compromised version and credentials were stolen from affected pipelines.
3. Impact came when the stolen credentials were used to compromise downstream organisations and spread the blast radius across multiple projects.

NHI Mgmt Group analysis

Implicit trust in build tooling is now a governance failure, not a convenience trade-off. Teams often treat third-party actions and packages as low-friction infrastructure, but the Trivy case shows how quickly that assumption collapses when the artefact itself becomes malicious. Software supply chain governance must therefore treat executable dependencies as controlled access paths, not passive libraries. Practitioners should align pipeline controls with NIST CSF, NIST SP 800-53, and MITRE ATT&CK to reflect that build systems are part of the threat surface.

Mutable tags are a hidden identity problem because they weaken provenance for non-human actors. A workflow that references a changing tag is effectively delegating trust to an identity that can be rewritten after approval. That intersects directly with NHI governance because CI runners, tokens, and automation accounts act on behalf of the organisation without human review. The better model is to bind approval to immutable artefacts and scoped credentials, then verify every execution path before release.

Software bills of materials are becoming incident-response infrastructure, not compliance paperwork. The article’s blast-radius examples show why teams need a continuously current view of what each build contains. When a compromise hits, the question is not whether a dependency is theoretically vulnerable, but which repositories, services, and runtime paths consumed that exact version. Practitioners should treat SBOM quality as an operational readiness metric.

Blast-radius governance is the named concept this article exposes. The real failure mode is not just a bad package, but the inability to answer where that package propagated before the issue was detected. That affects remediation speed, containment confidence, and board-level reporting. Security teams should structure supply chain controls around propagation visibility, because without it every incident becomes a manual investigation.

What this signals

Blast-radius visibility is becoming a baseline requirement for supply chain resilience. Teams that cannot map exact build inputs to impacted services will keep paying for manual repository audits every time a trusted dependency turns malicious. That is a control maturity issue, not just an incident-response inconvenience.

Non-human identities inside pipelines need lifecycle governance, not informal handling. CI runners, release tokens, and deployment credentials behave like access-bearing identities, which means provisioning, scope, and revocation must be managed with the same discipline as other privileged accounts. Where that discipline is absent, compromise travels faster than detection.

Reference data from The State of Secrets in AppSec shows how fragmented secrets estates and slow remediation still weaken response readiness. When build systems and secret stores are both fragmented, attackers gain more room to move before defenders can contain the incident.

For practitioners

• Pin every CI workflow to immutable commit hashes Replace mutable version tags such as action@v1 with commit-hash references, and reject pull requests that introduce unpinned executable workflow dependencies.
• Generate a continuously updated SBOM for each build Record the exact dependency versions and build inputs for every release so affected services can be queried immediately after a compromise.
• Map transitive dependencies to affected services Maintain a queryable dependency graph that includes indirect packages and actions, then use it to identify which repositories inherit exposure from a compromised component.
• Prioritise response by provenance and exploitability Combine dependency provenance with vulnerability intelligence so teams can focus first on artefacts that were actually executed in production workflows.
• Review pipeline identities as privileged access paths Treat CI runners, deployment tokens, and release automation as non-human identities with scoped lifecycles, least privilege, and revocation plans.

Key takeaways

• The Trivy compromise shows that mutable build artefacts can become a credential theft path across many downstream projects.
• Repository-level audits and delayed remediation reveal a deeper problem: many teams still lack reliable provenance and blast-radius visibility.
• Immutable pinning, SBOM quality, and non-human identity governance are the controls that most directly reduce this class of supply chain risk.

Key terms

• Software Supply Chain: 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.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.

What's in the full article

Kusari's full analysis covers the operational detail this post intentionally leaves for the source:

• A workflow-level breakdown of how Trivy compromise paths can be detected before merge.
• Specific guidance on pinning GitHub Actions to commit hashes instead of mutable tags.
• Repository and SBOM tactics for tracing transitive dependency exposure across environments.
• Response patterns for identifying which services inherited a compromised build input.

👉 Kusari's full post covers workflow pinning, dependency graphs, and blast-radius response detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to govern privileged automation and identity-bearing infrastructure across the wider programme.