In March 2026, the Trivy ecosystem suffered a new major compromise:
malicious publication of v0.69.4, compromise of setup-trivy, rewriting of
trivy-action tags, then an extension to Docker Hub images 0.69.5 and
0.69.6. The incident was a brutal reminder: a project can keep a healthy
source code while distributing dangerous artifacts through a
compromised release chain.
It is in this context that Chainguard published a post stating that its customers had not been affected. Taken as a mere marketing message, the article would hold little interest. Taken as a case study, it highlights a far more important idea: rebuilding from source in an independent chain sharply reduces the impact of an upstream compromise.
What was actually compromised in the Trivy incident?
On 19 March 2026, an attacker used compromised credentials to publish a
malicious v0.69.4 release of Trivy, while also modifying trivy-action and
setup-trivy. GitHub then published an advisory summarising the incident:
76 tags out of 77 on trivy-action were force-pushed to malicious
commits, and the 7 tags of setup-trivy were replaced. A few days later,
the incident extended to Docker Hub with compromised 0.69.5 and
0.69.6 images.
(GitHub advisory)
The most serious part is not only the distribution of a compromised binary. The real danger is Trivy's position inside CI/CD pipelines. When a security scanner, a GitHub Action or a tooling image is compromised, what potentially becomes accessible to the attacker are GitHub tokens, cloud credentials, registry passwords, API keys or Kubernetes secrets.
Aqua actually recommends treating as potentially exposed the secrets accessible to pipelines that executed affected versions. This is an essential point: the incident is not limited to "a broken tool", it quickly becomes a compromise of machine identities and of the CI/CD chain of trust.
Why does a legitimate source repository not mean a trustworthy artifact?
A project can keep a healthy application source code while distributing malicious binaries, images or GitHub actions, if the release chain or the publishing credentials are compromised. Many teams still believe that a legitimate GitHub repository, an official release and an artifact downloaded from a well-known channel are three equivalent things.
They are not.
The Trivy incident shows it plainly. In other words, the problem is not always in the code you read: it can be in the path taken to turn that code into an executable artifact.
This is precisely where the Chainguard post becomes interesting.
What does the Chainguard article really show?
Chainguard explains that its Trivy images are not built from the already published upstream artifacts: they are rebuilt from source in its own build chain. Their argument is therefore not only commercial: it illustrates a concrete security property.
If the attack targets the publication of releases, the tags, the images pushed to public registries or the GitHub actions, then an organisation that rebuilds in its own software factory from a verified source breaks part of the chain of trust the attacker is trying to poison.
Put differently: it is not only the tool that matters, it is the place where you put your trust.
The important point is therefore not "Chainguard magically protects everything". The important point is that an independent build chain can limit the impact of an upstream compromise, especially when the attack hits the distributed artifacts more than the source code itself.
Is this a green light to go back to Trivy?
No: this post is not a rehabilitation of Trivy as a default choice in production. Let me be clear about that.
My position remains the same as after the March 2026 incidents: for production pipelines, I currently prefer Grype as the main scanner, at least until the whole Trivy sequence has produced a sufficient level of transparency and guarantees on the complete remediation, the publication controls and the rotation of accesses.
The value of the Chainguard article lies elsewhere. It brings a concrete case to illustrate an idea many teams keep postponing: stop blindly trusting precompiled upstream artifacts, even when they are published by a popular and reputable project.
Why does the story not stop at Trivy?
The incident must not be read as an isolated episode.
On one hand, Aqua indicates that the investigation was still ongoing after 24 March and that the exact vector that allowed the attacker to regain access still had to be publicly confirmed. BoostSecurity also stresses that the re-entry mechanism into the Aqua organisation at the time of the second incident remains an open question. In other words, even after the first fixes were published, the full scenario of initial access and persistence was not yet fully clarified.
On the other hand, several industry actors have started linking this
compromise to a broader wave targeting security or CI/CD components.
StepSecurity even presents CanisterWorm as a direct continuation of the
second Trivy incident, with the reuse of stolen secrets from pipelines to
then publish compromised npm packages. This attribution still calls for
caution, but it reinforces a simple idea: when a pipeline tool is
compromised, the damage can spread far beyond the original project.
This is exactly why these incidents must be treated not as classic CVEs, but as machine identity and supply chain propagation incidents.
What would I change in my pipelines?
The Trivy incident reinforces several decisions I now consider non-negotiable.
1. Pin GitHub actions on SHAs
A tag, even a versioned one, remains a mutable reference if the publication
governance is compromised. The attack on trivy-action demonstrated it
brutally.
2. Reduce trust in precompiled upstream artifacts
Whenever possible, favour artifacts you rebuild or can verify. That means:
- internal rebuilds,
- images rebuilt in a controlled chain,
- or at minimum sources with attestations, signatures and a verifiable provenance.
3. Introduce real internal promotion of artifacts
Pipelines should not pull directly into production from the Internet. You need an internal registry or a trusted mirror, with validation before promotion.
4. Plan for fast rotation of CI/CD secrets
As soon as a tool executed in the pipeline is suspected of having been able to read the runner's memory, the hypothesis of secret compromise must be taken seriously. Rotation has to be ready before you need it.
5. Control provenance, not just CVEs
Scanning for vulnerabilities remains useful, but it is not enough against a malicious artifact published "officially". You also have to verify:
- signatures,
- attestations,
- SBOM,
- build identity,
- distribution channel,
- internal promotion policy.
What does the Trivy affair make impossible to ignore?
The lesson of the Trivy affair is not "buy product X"; the real lesson is that many teams still confuse a legitimate source repository, an official release and a trustworthy artifact.
These three things are not equivalent.
From the moment the release chain becomes a priority target, supply chain security can no longer be limited to scanning CVEs after the fact. You have to control provenance, verify attestations, reduce trust in upstream binaries, and stop executing "official" components without scrutiny simply because they are popular.
The Chainguard article is useful for one single reason: it is a very concrete reminder that an independent build chain is sometimes worth more than one extra security tool.
And that is probably the most durable lesson of this whole episode.