The vulnerability scanner became the way in — what CI users should do after the Trivy supply-chain compromise

Aqua asks users to review workflow run logs from March 19–20, 2026. The windows in the advisory (UTC) are: trivy-action, about 17:43 on March 19 to about 05:40 on March 20; setup-trivy, about 17:43 to about 21:44 on March 19; Trivy v0.69.4, 18:22 to about 21:42 on March 19; Docker Hub images v0.69.5 and v0.69.6, 15:43 on March 22 to about 01:40 on March 23. If your organization has many workflows, search for those referencing aquasecurity/trivy-action and aquasecurity/setup-trivy and filter their run history by these windows.

In the advisory, what matters is how you referenced the component.
trivy-action — affected: any tag other than 0.35.0 (0.0.1–0.34.2); version: latest set explicitly during the window; a SHA pin to a commit from before April 9, 2025. Not affected: the 0.35.0 tag; SHA pins to safe commits after April 9, 2025.
setup-trivy — affected: any use without a SHA pin. Not affected: SHA pins to safe commits.
Trivy itself — affected: v0.69.4 (including latest during the window; GitHub, deb, rpm, get.trivy.dev, GHCR, ECR Public, Docker Hub) and Docker Hub v0.69.5 and v0.69.6. Not affected: v0.69.3 and earlier; images referenced by digest; builds from source; the official Homebrew formula.

Aqua says that if there is any possibility a compromised version ran, all secrets accessible to the affected pipelines must be treated as exposed: cloud credentials (AWS, GCP, Azure), Git credentials, container registry credentials, SSH keys, Kubernetes tokens, and environment variables and other automation secrets. It asks that npm publish tokens be treated as actively compromised, saying stolen tokens are being used to spread malware across npm. For self-hosted runners, Aqua also lists database credentials, TLS private keys and VPN configurations stored on the runner.

This step comes from Trivy's own root cause. According to Aqua, the March 1 rotation was not done all at once, and during a rotation that took several days, the attacker may have used a still-valid token to take even the newly issued secrets. Once you have listed the secrets in scope, invalidate the old keys together first, then issue new ones. Rotating one key at a time leaves room for a still-valid old key to read the new ones. Plan for a short outage as the price.

Aqua lists, as items to check, a repository created in your GitHub organization if a fallback exfiltration path was used, and files left on a machine where v0.69.4 ran outside CI, such as a developer workstation. If you may be affected, follow the checklists in Aqua's disclosure and the advisory linked below (this article does not reproduce the indicator values).

Aqua lists the safe versions as Trivy v0.69.2 and v0.69.3, trivy-action v0.35.0, and setup-trivy v0.2.6. According to the advisory, the old trivy-action tags (0.0.1–0.34.2) were deleted and cannot be re-created under the same names, so they were republished with a v prefix (for example v0.34.0), pointing to the original legitimate commits (a few have not been restored). If you still reference an older version, you need to update the reference.

According to the advisory, trivy-action switched its internal component references to SHA pins in a pull request merged on April 9, 2025. People who pinned trivy-action to an earlier commit had a safe trivy-action that called a malicious setup-trivy by tag. If you use actions built from other actions (composite actions), open the action.yml at the commit you pinned and check whether the uses: lines inside are pinned by SHA. If not, move to a newer commit or call the inner components directly from your own workflow, pinned by SHA.

In August 2025, GitHub added an option to the allowed-actions policy that requires actions to be pinned to a full commit SHA. It can be set at the enterprise, organization or repository level, and workflows that use an unpinned action fail. The same policy can block specific actions or versions, which also gives you a way to shut off an affected version across the whole organization during an incident like this.

According to the advisory, Trivy v0.69.3 and trivy-action 0.35.0 escaped because GitHub's immutable releases were enabled before they were published. Aqua, however, says the "Immutable" badge also appeared next to rewritten tags, and that pinning to a full commit SHA, not the badge, is the reliable protection. The badge describes a release as of when it was published.

In the advisory, images referenced by digest (@sha256:…) were not affected. Pulling by latest or a version tag alone would have picked up the malicious build during the window. Trivy's advisory also shows how to verify binaries and images with Sigstore signatures and signing timestamps. For tools your CI downloads, state the version and, where possible, pin by digest or checksum.

According to Aqua, the malicious code ran before the legitimate scan, and the scan output looked normal, which made it hard to notice. A scan normally needs no write access to your cloud or registry. Run scanning in a separate job that receives no deployment secrets, with permissions: set to read-only. According to Aqua, the fallback exfiltration path worked only when a personal access token (PAT) was passed to the workflow and failed with the default GITHUB_TOKEN. Check that you are not handing a personal token to your scanning step.