The Trivy Supply Chain Attack: What Every Development Team Should Learn From It

What happened

On March 19, 2026, a threat actor used compromised credentials to take over Aqua Security’s Trivy project — the most widely adopted open-source vulnerability scanner in the cloud-native ecosystem. The irony is hard to miss: the tool teams rely on to find vulnerabilities became the vulnerability.

The attackers published a malicious Trivy v0.69.4 release, force-pushed 76 of 77 version tags in the trivy-action GitHub Action to credential-stealing malware, and replaced all 7 tags in setup-trivy with malicious commits. The trivy-action compromise lasted approximately 12 hours, setup-trivy about 4 hours, and the malicious binary release about 3 hours.

Three days later, on March 22, they came back and published malicious Docker Hub images tagged as v0.69.5 and v0.69.6. The security tool that was supposed to protect your pipeline was actively stealing your secrets — twice.

What the malware did

The payload was surgical. It targeted exactly what you would expect from a CI/CD-focused attack: AWS, GCP, and Azure credentials, SSH keys, Kubernetes tokens, Docker configuration files, Git credentials, and any other secrets available in the CI environment.

A group calling themselves TeamPCP claimed responsibility. Analysis confirmed that at least 45 repositories had workflow runs that used a compromised version of trivy-action or setup-trivy during the attack window. The real number is likely higher — not every affected organization has disclosed.

Microsoft, Palo Alto Networks, Wiz, Docker, and Legit Security all published post-incident analyses. When that many security vendors write about the same incident, you know it is significant.

Why this keeps happening

This is not a novel attack pattern. It follows the same playbook as the tj-actions/changed-files compromise and other GitHub Actions supply chain attacks. The formula is simple: compromise a maintainer’s credentials, push malicious code to a widely-used action, and harvest secrets from every CI pipeline that runs it.

The core problem is trust. Most teams pin their GitHub Actions to a tag like @v3 instead of a specific commit SHA. Tags are mutable — an attacker who gains write access can point them anywhere. A workflow file says trivy-action@v3 and assumes it runs the same code as yesterday. It does not.

The second problem is blast radius. A single compromised GitHub Action can affect thousands of repositories simultaneously. There is no review step, no approval gate — when a workflow triggers, it pulls whatever the tag currently points to and runs it with full access to secrets.

What development teams should do

Pin GitHub Actions to full commit SHAs, not version tags. Instead of uses: aquasecurity/trivy-action@v0.18.0, use the exact commit hash. This is the single most effective defense against action supply chain attacks.

Restrict secret access in workflows. Use GitHub’s environment protection rules to require approval before workflows can access production secrets. Not every PR build needs production credentials.

Monitor dependencies. Tools like StepSecurity Harden-Runner and GitHub’s own dependency review action can detect when an action’s underlying code changes unexpectedly. Set up alerts for any action in the pipeline.

Audit exposure. If CI pipelines ran trivy-action or setup-trivy between March 19-22, 2026, assume CI secrets were exposed. Rotate every credential that was available to those workflows: cloud provider keys, Docker Hub tokens, NPM tokens, SSH keys, and anything else in the CI environment.

Have an incident response plan for supply chain attacks. Most teams have a plan for “our code has a vulnerability.” Few have a plan for “our security tooling was the attack vector.” The Trivy incident proves you need one.

The uncomfortable truth

Modern software delivery is built on a foundation of implicit trust. Teams trust that npm packages are what they say they are, that Docker images have not been tampered with, that GitHub Actions run the code that was reviewed when they were first added.

Every major supply chain attack — SolarWinds, Codecov, ua-parser-js, tj-actions, and now Trivy — is a reminder that this trust is misplaced. The tools used to build and secure software are themselves software, with all the same risks.

The teams that handle these incidents well are not the ones with the best tools. They are the ones that assumed their tools could be compromised and built their pipelines accordingly. Defense in depth is not just a server architecture principle — it applies to the entire delivery pipeline.