The Trivy Supply Chain Attack: SHA Pinning Isn't the Defense You Think It Is

If you're running Aqua Security's open-source Trivy scanner in your CI/CD pipelines, stop what you're doing and check your versions. If any workflow executed the compromised `v0.69.4` components - anytime between late February and March 22, 2026 - assume every secret those pipelines could reach is already in someone else's hands.

This wasn't a theoretical supply chain risk. It executed. It stole credentials. And it did it while your Trivy scans came back clean.

What Happened

On March 4, a commit landed in `aquasecurity/trivy` with the message `fix(ci): Use correct checkout pinning`. It touched two workflow files. Fourteen lines. Most of it was cosmetic noise - single quotes swapped for double quotes, a trailing space removed. The kind of diff that gets approved in 30 seconds because there's nothing suspicious to review.

Two lines mattered. The first swapped the `actions/checkout` SHA in the release workflow. The `# v6.0.2` comment stayed. The SHA itself changed - pointing to an orphaned commit sitting in a fork of `actions/checkout`, invisible in normal GitHub navigation. The second change added `--skip=validate` to the GoReleaser invocation, disabling integrity checks on the build artifacts.

The attacker had compromised a legitimate Trivy maintainer's account (attributed to DmitriyLewen in the commit history). They'd pre-staged the malicious payload months earlier in an orphaned fork commit. GitHub even flags these with a yellow banner: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." Nobody checked.

The malicious payload ran before legitimate Trivy scanning logic could execute. Your pipeline looked normal. Your scan results came back. And in the background, the malware silently exfiltrated:

• AWS, GCP, and Azure API tokens

• SSH private keys

• Kubernetes service account tokens

• Docker configuration files

The C2 server was `scan.aquasecurtiy[.]org` - a typosquatted domain, one character off from the real Aqua Security domain. Block it at your network perimeter if you haven't already.

The Multi-Stage Timeline

This wasn't a smash-and-grab. The breach started in late February 2026. Aqua detected suspicious activity and performed a credential rotation on March 1 - but it was incomplete. The attacker maintained access. Further suspicious activity appeared on March 22, suggesting an attempt to reestablish the foothold.

Aqua has since brought in Sygnia for incident response, revoked all credentials, transitioned away from long-lived tokens, and removed malicious artifacts from distribution channels. Aqua's commercial platform was never affected - it operates on entirely separate build infrastructure, isolated from the open-source GitHub environment.

Open-source Trivy users had no such isolation.

SHA Pinning Has a Blind Spot

The standard advice - pin GitHub Actions to SHA hashes instead of version tags - is correct, but incomplete. The Trivy attack exposed a gap that most teams haven't internalized.

Tags are mutable. An attacker with write access can point `v0.69.4` at any commit. That's why SHA pinning exists.

But here's what the Trivy attack showed: GitHub resolves SHAs across forks. An attacker can push a malicious commit to a fork, walk away, and reference that SHA from any repository. The SHA is real. The commit is real. Your pinning tool verifies it correctly. What it doesn't tell you is that the commit lives in an orphaned fork with no branch, no review history, and a spoofed author.

The commit that triggered this attack attributed itself to Guillermo Rauch (a well-known developer), referenced a closed GitHub PR, and had no GPG signature. Every metadata signal was designed to look routine in a drive-by review.

What You Need to Do

If you're using open-source Trivy, act now:

• Update Trivy binary to v0.69.2 or v0.69.3 (safe versions confirmed by Aqua)

• Update `trivy-action` to v0.35.0 or earlier

• Update `setup-trivy` to v0.2.6 or earlier

• Block `scan.aquasecurtiy[.]org` at your firewall

If any pipeline ran compromised components:

Assume every credential accessible to those workflows is compromised. That means rotating AWS IAM keys, GCP service accounts, Azure service principals, SSH keys, and Kubernetes tokens - all of them, not just the ones you think were exposed. Attackers exfiltrate everything the environment can reach.

For ongoing pipeline hardening:

Pinning by SHA is still better than pinning by tag. But pair it with Sigstore/cosign for signed artifact verification, and audit any SHA that points outside the main repository's commit graph. GitHub's dependency review tooling and tools like `zizmor` can flag orphaned-fork SHAs before they land in your pipelines.

The Bigger Picture

CybrPulse has tracked a steady increase in supply chain attacks targeting CI/CD tooling throughout early 2026. The Trivy incident is notable not just for the target - a security tool used by millions of developers - but for the patience. An attacker who stages a malicious commit in an orphaned fork months in advance, compromises a maintainer account, and hides the payload inside a boring cosmetic PR is not opportunistic. This was deliberate, researched, and nearly invisible.

The security scanner that was supposed to catch threats was the threat. That's the threat model worth revisiting.