Aqua Security releases post-mortem on the Trivy v0.69 supply chain attack. Discover how GitHub Actions tokens were compromised to inject malware. Full analysis.
What Happened to Trivy v0.69
Trivy is an open-source scanner that teams run to find vulnerabilities in container images, filesystems, and code dependencies. That makes it a high-value target: a scanner sits deep inside CI/CD pipelines and often runs with broad access to the artifacts it inspects. According to the post-mortem from Aqua Security, the maintainers of Trivy, the v0.69 release was compromised through a supply chain attack that injected malware into the distributed build.
The significance here is not a single bug in the tool's scanning logic. It is that a trusted security product, pulled automatically by countless pipelines, became the delivery mechanism for malicious code. When the thing you use to check for compromise is itself compromised, the normal detection loop breaks down.
How the GitHub Actions Tokens Were Abused
The root cause traced back to GitHub Actions tokens being compromised. In a typical release workflow, automation tokens hold the permissions needed to build artifacts, publish releases, and push to registries. If an attacker gains control of one of those tokens, they can operate inside the pipeline with the same authority the maintainers granted their own automation—no need to breach a developer's laptop or guess a password.
With that access, an attacker can alter what gets built or replace a legitimate release with a tampered one that still carries the project's name and expected provenance. Because the injection happens on the build side rather than in reviewed source code, a reader browsing the public repository may see nothing wrong. The malicious payload lives in the shipped artifact, not the commit history everyone is watching.
Lessons for Anyone Running CI/CD
This incident is a reminder that release automation is production infrastructure and deserves the same scrutiny as any other privileged system. The failure mode—a stolen token quietly rewriting a trusted release—is one that most projects using hosted CI are exposed to, not something specific to a single scanner.
- Scope automation tokens to the minimum permissions a job actually needs, and prefer short-lived, workflow-scoped credentials over long-lived secrets.
- Pin dependencies and build tools to specific versions and verified digests, rather than always pulling the latest tag by default.
- Require signed artifacts and verify signatures at install time, so a swapped release fails the check instead of running silently.
- Separate the identity that can build from the identity that can publish, so one compromised token cannot do both.
- Monitor release workflows for unexpected changes—new steps, altered outputs, or publishes that no human initiated.
Why the Post-Mortem Matters
Publishing a post-mortem is the responsible move after an incident like this. A clear account of how the tokens were compromised and how malware reached users lets other maintainers check whether their own pipelines share the same weaknesses, and it gives downstream teams the facts they need to assess their exposure and respond.
The practical takeaway is to treat every dependency—including your security tooling—as code you are choosing to trust and execute. Verify what you pull, limit what your automation can do, and assume that a signed, reproducible build with least-privilege tokens is the baseline, not an optional hardening step.