Trivy supply chain attack exposes CI/CD tag poisoning risks

At a glance

What this is: This is Aqua Security’s account of the Trivy supply chain attack, showing how compromised credentials and tag poisoning let malicious code ride trusted CI/CD update paths.

Why it matters: It matters because IAM, PAM, and CI/CD owners cannot treat repository automation as a static delivery path when release tags, service accounts, and token reuse can be abused after containment.

Context

Trivy tag poisoning is a CI/CD trust problem, not just a code-integrity problem. When pipelines consume mutable version tags, the identity behind a release action matters as much as the artifact itself, because the tag can point somewhere else without changing the visible workflow.

Aqua Security’s incident shows how compromised credentials, incomplete rotation, and residual access can turn release automation into an attack path. The governance gap is familiar to IAM teams: access was removed partially, but not decisively enough to stop later abuse of the same automation chain.

For NHI governance, the lesson is that repository automation behaves like a non-human identity with release authority. If that identity can still publish, retag, or invoke downstream automation after containment, the control failure is in lifecycle closure, not just detection.

Key questions

Q: What breaks when CI/CD pipelines trust mutable version tags?

A: Mutable tags break the assumption that a release reference always points to the same code. If an attacker can rewrite the tag, every downstream pipeline that resolves by name may execute a different artifact without noticing. Teams should treat tag mutability as a trust control failure and require immutable references for build integrity.

Q: Why do incomplete credential rotations keep supply chain incidents alive?

A: Incomplete rotation keeps incidents alive because one surviving token, bot account, or secret can preserve attacker access after the first response. In supply-chain environments, that residual identity can reach release automation, repositories, and signing paths. The real containment test is whether any credentialed path remains valid after rotation.

Q: What signals show that CI/CD automation has been poisoned?

A: Look for forced tag moves, unsigned commits where signed ones were expected, impossible parent-child commit history, unexpected release asset creation, and workflow runs that now reference the same tag but different code. Those are strong signs that release identity and execution identity have diverged.

Q: How should security teams govern release automation after a supply chain attack?

A: Treat release automation as a privileged non-human identity with a defined owner, limited scope, and explicit offboarding path. Separate publishing from secret access, require immutable provenance for consumed artifacts, and validate that no residual token can still invoke the compromised workflow or registry action.

Technical breakdown

How mutable tags turned trusted releases into a delivery channel

Mutable version tags let a repository name appear stable while the commit behind it changes. In this attack, trusted references such as trivy-action and setup-trivy were force-pushed so existing CI/CD workflows continued pulling the same tag name but executed malicious code instead. That pattern defeats workflow assumptions built around version labels instead of immutable commit pinning. The technical failure is not only code tampering, but the gap between human-readable release identity and the actual object executed in the pipeline.

Practical implication: Pin CI/CD consumption to immutable commits or digests, not moving tags.

Why residual credentials kept the attack alive after rotation

Credential rotation only helps if every active token, secret, and service account is covered. Aqua Security’s timeline says an initial rotation was not fully comprehensive, which left residual access available after containment. That matters because automation identities often have multiple valid touchpoints across GitHub, release tooling, and artifact publishing systems. If one token survives, the attacker can re-enter through a path defenders believed they had closed. In NHI governance terms, partial rotation creates a false sense of closure.

Practical implication: Treat rotation as complete only when every credential path has been enumerated and revoked.

How release automation became a multi-stage supply chain compromise

The attack combined repository tampering, release poisoning, and downstream credential theft in one chain. The compromised automation account triggered malicious releases, while the payload attempted to steal additional secrets from CI/CD environments and developer systems. This is why supply chain incidents now sit at the intersection of NHI, CI/CD identity, and workload exposure. Once a trusted automation identity can both publish artifacts and harvest secrets, the pipeline stops being a build-only system and becomes an execution and exfiltration surface.

Practical implication: Segment build, publish, and secret-access permissions so one automation identity cannot do all three.

Threat narrative

Attacker objective: The attacker aimed to inject malicious artifacts into trusted open-source release paths and use those paths to steal additional credentials from downstream environments.

1. Entry occurred through a misconfiguration in Trivy’s GitHub Actions environment, where attackers extracted a privileged access token and established foothold in repository automation.
2. Credential access persisted because the first rotation was incomplete, leaving still-valid credentials that allowed the actor to retain or regain access after initial containment.
3. Escalation and impact followed when the attacker force-pushed trusted tags and used a compromised service account to publish malicious releases that downstream CI/CD systems executed as legitimate updates.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• 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.

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

Mutable release tags create identity ambiguity, not just version risk. When CI/CD pipelines trust a tag name instead of an immutable object, they are trusting an identity reference that can be rewritten after approval. That breaks the assumption that release identity is stable across the approval and execution window. Practitioners should treat mutable tags as a governance defect, not a packaging convenience.

Residual access is the real control failure in this incident. The attack continued because rotation did not eliminate every credentialed path into release automation. That is a lifecycle failure, not a detection failure, and it shows how partial offboarding leaves non-human identities able to outlive the containment event. The lesson is to close the credential estate, not to declare victory after the first rotation pass.

CI/CD release accounts now function as high-value non-human identities. They can publish artifacts, trigger automation, and in some cases access secrets that should never be co-located with release authority. That is why OWASP-NHI concerns such as overprivilege, long-lived secrets, and improper offboarding map directly to software delivery systems. Identity teams should manage release automation as a governed NHI, not as a build convenience.

Tag poisoning is a replay problem in disguise. The attacker reused trusted workflow names and familiar release paths to make malicious code look routine. That means the control boundary must shift from artifact appearance to provenance, provenance enforcement, and strict release identity governance. Practitioners should assume the pipeline will be targeted through its most reusable reference points.

Identity blast radius: This incident shows how one compromised automation identity can spill across publishing, workflow execution, and secret collection when permissions are not isolated by function. The broader implication is that release systems need privilege separation just like production systems. Governance teams should map where one automation identity can still touch multiple stages of the delivery chain.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Tag poisoning should be treated as an identity problem: the release reference is only trustworthy if the identity behind it cannot be rewritten after approval. In practice, CI/CD teams need to assume that mutable tags and reusable workflow names are governance objects, not just developer convenience.

A related control failure is incomplete offboarding of automation credentials. The moment a compromised token survives a partial rotation, the attacker can return through the same release path, which is why containment has to end with lifecycle closure rather than with the first response milestone.

The blast radius of a compromised release identity can expand across artifact publication, secret harvesting, and downstream pipeline execution. That is why publish, build, and secret-access permissions should be separated as distinct governance domains, not collapsed into one service account.

For practitioners

• Pin pipeline inputs to immutable releases Replace mutable version tags with pinned commits, digests, or signed release references in build and deployment workflows.
• Inventory every release-path credential Enumerate service accounts, PATs, and bot tokens that can publish artifacts, trigger workflows, or create releases, then validate each one against current ownership.
• Separate build, publish, and secret-access roles Keep artifact publication, workflow execution, and secret retrieval on different identities so compromise in one stage does not grant control of the others.
• Verify rotation actually removed residual access After any incident, confirm that no old token, bot credential, or cached secret can still reach repositories, registries, or automation APIs.
• Hunt for tag poisoning in release logs Review repository history for force-pushed tags, impossible commit ancestry, unsigned commits, and unexpected release asset creation tied to trusted names.

Key takeaways

• The Trivy incident shows how mutable tags and residual credentials can turn CI/CD release automation into a reusable attack surface.
• The attack involved compromised credentials, force-pushed tags, and malicious releases that downstream pipelines could treat as trusted updates.
• The control that would have reduced impact most directly is immutable provenance combined with complete credential offboarding for release automation.

Key terms

• Mutable Release Tag: A mutable release tag is a version label that can be reassigned to different code after it has already been trusted. In CI/CD environments, that makes the tag a governance risk because approval can be bypassed without changing the visible workflow path.
• Residual Access: Residual access is any permission, token, account, or data path that continues to work after a user should no longer have access. It is a common failure mode in SaaS-heavy environments because deprovisioning one system does not automatically shut down all downstream connections.
• Release Automation Identity: A release automation identity is a non-human identity that can publish, tag, sign, or distribute software artifacts. It should be narrowly scoped and lifecycle-managed because it sits on the path from source control to downstream trust and can be abused to push malicious releases.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.