Mar 30, 2026

How Secure Build Practices Protected Us from the Trivy Supply Chain Attack

Recently, reports emerged of a supply-chain attack involving compromised releases of the Trivy vulnerability scanner and related components, a widely used vulnerability scanner, and its related GitHub Actions. Given that Trivy is integrated into our core development workflows, we immediately initiated an internal investigation to assess any potential impact on our infrastructure.

This post outlines our findings and, more importantly, the specific security controls that ensured our repositories remained unaffected.

What happened

On March 19, 2026, a threat actor identified as "TeamPCP" compromised the release pipeline for several Aqua Security projects. By exploiting a previously identified configuration weakness, the attackers force-pushed malicious code to the v0.69.4 tag of the core Trivy binary and nearly all version tags of aquasecurity/trivy-action.

The malicious payload was designed to exfiltrate sensitive CI/CD data, including cloud provider credentials, SSH keys, and Kubernetes tokens, to a typosquatted domain (scan.aquasecurtiy[.]org). In some cases, the malware attempted to create a fallback repository named tpcp-docs within the victim's GitHub organization to store stolen secrets.

Why this mattered to us

Trivy is used in multiple repositories across our organization as part of our CI/CD pipelines. It is one of many tools we use to proactively detect and resolve vulnerabilities in our code. Any compromise of a widely used development tool warrants immediate review.

As soon as credible reports surfaced, we treated the situation as a potential incident and began an internal investigation.

Our investigation

As soon as the incident was reported, we audited our CI/CD execution logs to identify which versions of the Trivy binary were actually pulled and executed by our runners.

Our investigation confirmed that during the attack window, our pipelines executed Trivy v0.69.2 (Confirmed as Safe Version). This version was released prior to the compromise. Several factors contributed to our protection:

GitHub Action Pinning (Commit SHA): By referencing aquasecurity/trivy-action via its unique commit SHA, we ensured the logic of the automation itself was untampered.
Version Consistency: Our environment naturally remained on v0.69.2, avoiding the malicious v0.69.4 release that was briefly pushed to the registries.

Conclusion: Our repositories were not affected

After completing our analysis, we confirmed that our repositories were not impacted by the Trivy supply chain attack.

Several existing controls played a key role.

Why we were protected

1) GitHub Actions pinned to commit SHAs

Unlike mutable version tags (v0.69.4), which can be pointed to a different commit by anyone with repository access, Commit SHAs are immutable.

Because our pipelines reference specific hashes, the malicious "force-push" performed by the attackers never reached our runners; our systems continued to look for the exact, trusted code they were programmed to run.

2) Use of previously cached trusted binaries

Our systems retained a safe, previously verified Trivy binary. As a result, our pipelines did not download compromised releases during the attack window.

3) Update timing

We had updated Trivy approximately nine days before the attack occurred (March 10, 2026), further reducing the likelihood of exposure to affected versions.

4) CI/CD architecture

Even though this was not relevant in this case, Tenchi made the decision to only execute CI (tests) in Github actions. All of the CD (deployment) logic is executed from inside our own AWS environment, precisely to minimize the amount of external code that could have access to staging and production environment credentials. So even if we had executed the malicious version of Trivy, none of the secrets on the Github actions where it is executed could have led to a compromise of our customers’ data. We already discussed this when we talked about the tj-actions/changed-files supply chain compromise on our podcast.

Ongoing monitoring

Although no impact was identified, we continue to monitor developments related to this incident and review our security controls as part of our standard practices.

More details about the attack