Trivy Scanner Breach: When 32,000 GitHub Stars Became a Liability

What Happened

On March 19, 2026, attackers compromised Aqua Security's Trivy vulnerability scanner through GitHub Actions. Trivy, with over 32,000 stars on GitHub, is a critical dependency in thousands of CI/CD pipelines worldwide. The attackers force-updated existing version tags to distribute malicious code to downstream users who had pinned their builds to what they believed were stable releases.

The attack was not a zero-day exploit or sophisticated code injection. Instead, compromised credentials gave attackers write access to the repository's automation workflows.

Timeline

March 19, 2026 (Time unknown): Attackers gained access to GitHub Actions credentials with write permissions to the Trivy repository.

March 19, 2026 (Shortly after initial access): Malicious code was pushed to the repository using force-update on existing version tags. Organizations using tag-based pinning (e.g., aquasecurity/[email protected]) automatically pulled the compromised version on their next build.

March 19-20, 2026: AppOmni Labs detected and analyzed the compromise, publishing their findings.

Post-detection: Aqua Security rotated credentials and remediated the compromised tags. The exact restoration timeline was not disclosed.

Which Controls Failed or Were Missing

Credential Management: The attackers obtained credentials with excessive permissions to modify production code through automated workflows. Your GitHub Actions workflows should never use personal access tokens with write access to protected branches or tag management. This incident suggests either:

• A PAT with repo-level write permissions was exposed
• The GitHub Actions default token had overly permissive settings
• No credential rotation policy existed for automation tokens

Immutable Release Artifacts: Git tags are mutable by default. The force-update tactic worked because Trivy's release process allowed existing tags to be overwritten. Organizations consuming Trivy had no mechanism to detect that v0.50.0 on March 20 was different from v0.50.0 on March 18.

Workflow Approval Gates: The compromise suggests GitHub Actions workflows could modify release tags without human approval or secondary verification. A pull request to change source code requires review; a workflow that rewrites release history apparently did not.

Artifact Signing: No evidence suggests Trivy releases were cryptographically signed in a way that would have alerted consumers to the tampering. Even if signatures existed, automated pipelines rarely verify them before execution.

What the Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates that bespoke and custom software be developed securely, including establishing secure coding practices and protecting authentication credentials. The requirement explicitly covers credentials used in build and deployment processes. If your CI/CD pipeline processes cardholder data or sits in the CDE boundary, exposed GitHub Actions credentials are a finding.

NIST 800-53 Rev 5 Control IA-5(1) requires password-based authentication to use encrypted or hashed passwords and enforce minimum password complexity. More relevant here: IA-5(7) addresses unencrypted static authenticators embedded in access scripts or stored in function keys. GitHub PATs used in workflows fall squarely into this control family. Your assessor will ask: Where are these tokens stored? How often do you rotate them? Who has access?

ISO/IEC 27001 Control 5.17 (Authentication Information) requires organizations to ensure proper use of secret authentication information. The control's implementation guidance specifically mentions service accounts and automated processes. If you're using GitHub Actions tokens with write access to production repositories, you need documented procedures for issuance, rotation, and revocation.

SOC 2 Type II CC6.1 (Logical and Physical Access Controls) requires that the entity implements logical access security software, infrastructure, and architectures to protect against threats. Your auditor will test whether CI/CD credentials are managed with the same rigor as production database passwords. This incident demonstrates they often aren't.

Lessons and Action Items for Your Team

Implement credential hygiene for CI/CD immediately:

• Audit every GitHub Actions workflow in your organization. List every secret, PAT, and service account token.
• Replace long-lived PATs with short-lived tokens where possible. GitHub supports OIDC federation with major cloud providers—use it.
• Set your GITHUB_TOKEN permissions to the minimum required. The default is often write-all, which is indefensible.
• Rotate all automation credentials quarterly at minimum. Document the rotation in your ISMS.

Make your release artifacts immutable:

• Use content-addressable storage. Pin dependencies by commit SHA, not tag: aquasecurity/trivy@7a3c9b2 instead of aquasecurity/[email protected].
• For your own releases, configure tag protection rules in GitHub. Require signed commits for tag creation.
• Implement release signing with Sigstore or GPG. More importantly, verify signatures in your pipelines before execution.

Add approval gates to sensitive workflows:

• GitHub Actions workflows that can modify release tags, push to protected branches, or access production secrets should require manual approval.
• Use environment protection rules. Configure your production environment to require review from two people before deployment workflows run.
• Separate your build and release workflows. The workflow that compiles code should not have credentials to publish releases.

Test your supply chain visibility:

• Can you list every third-party action your workflows execute? Most organizations cannot.
• Do you pin third-party actions to commit SHAs? actions/checkout@v4 is a moving target; actions/checkout@b4ffde6 is not.
• Run trufflehog or gitleaks against your .github/workflows directory. You'll be surprised what you find.

The Trivy compromise succeeded because convenience trumped governance. Your scanner ran in every pipeline with credentials that could rewrite its own source code. That's not a supply chain attack—it's architectural malpractice. Fix your credential hygiene before your next audit flags it, or worse, before your next incident response.