Alex Reed · April 27, 2026 · 9 min read

The Security Scanner That Became the Attack Vector: Inside the Trivy Compromise

In March 2026, attackers compromised Aqua Security's Trivy — an open-source vulnerability scanner used by over 100,000 organizations in enterprise CI/CD pipelines. They didn't exploit a zero-day in the scanner itself. They exploited a misconfiguration in Trivy's own GitHub Actions environment, stole a privileged access token, and published malicious versions of the scanner that stole CI/CD secrets from thousands of pipelines.

The tool designed to detect supply chain attacks became a supply chain attack. This is the most consequential open-source compromise since the Axios hijacking twelve days later, and it exposes a structural problem that SBOMs, signed commits, and pinned actions all fail to address.

What Happened

This is the first of five major open-source compromises in twelve days. The others — Axios (attributed to North Korean APT UNC1069), Checkmarx, LiteLLM, and Telnyx — followed the same pattern: target popular, trusted infrastructure and weaponize the trust itself.

Why Trivy Specifically

Trivy is embedded deep in CI/CD pipelines. It's the scanner that runs after your build, before your deploy. It has access to container images, filesystems, and — critically — the environment variables in your GitHub Actions runtime. Those environment variables contain secrets: GITHUB_TOKEN, npm tokens, SSH keys, cloud credentials, API keys.

A compromised Trivy scan doesn't just report false negatives. It can exfiltrate everything in the runner environment. The irony is structural: the security tool has the broadest access to the most sensitive data in your pipeline.

The SBOM Illusion

Every organization affected by the Trivy compromise had SBOMs. The SBOMs didn't help. Here's why:

SBOMs are inventories, not controls. They tell you what's in your software. They don't stop a compromised version from running. When Trivy went malicious, the SBOM said "yes, that's Trivy 0.58.1" — correct and completely useless.

SBOMs are stale on generation. Most are produced at build time. The Trivy compromise happened at runtime — a malicious action pulled from the marketplace during CI execution. The SBOM recorded the clean version from the last build; the pipeline ran the dirty one.

SBOMs don't model trust relationships. Trivy's position in the pipeline means it has access to secrets. An SBOM lists Trivy as a dependency. It doesn't annotate "this dependency has credentials to everything."

Supply chain attacks surged 73% in 2025. Malicious open-source packages more than doubled on npm. This happened during peak SBOM adoption. If SBOMs were an effective security control, the trend would go the other direction.

The Actions Misconfiguration Pattern

The root cause wasn't exotic. It was a GitHub Actions environment with more permissions than it needed. This is the same pattern I found when I scanned 15 GitHub workflows and found 96 security issues in a single repo.

Here's the specific class of misconfiguration that enabled the Trivy compromise:

# Dangerous: broad permissions on workflow
permissions:
  contents: write       # Can push to repo
  packages: write       # Can publish packages
  actions: write        # Can modify other workflows

# The token from these permissions is what the attackers
# extracted and used to publish malicious versions

The fix is straightforward but almost nobody does it:

# Safer: minimal permissions, explicitly scoped
permissions:
  contents: read        # Only what the scanner needs
  security-events: write  # For SARIF upload only

# Better: pin the action to a specific commit SHA
- uses: aquasecurity/trivy-action@abc123def456...
  # NOT @main, NOT @master, NOT @latest

The Partial Rotation Problem

The most damning detail: Trivy's team detected the compromise and rotated credentials, but missed some. Attackers maintained access after the initial response.

This is the "known unknowns" problem in credential management. When a token is compromised, you have to rotate every token it could have accessed — not just the one you know about. In a CI/CD environment, a single token often touches repositories, package registries, cloud providers, and artifact stores. Missing one is the same as missing all of them.

The Trivy team is not unique in this. Partial rotations are the norm, not the exception. Ask yourself: if a single GitHub token in your CI/CD pipeline was compromised right now, could you enumerate every secret it has access to? Could you rotate all of them in under an hour?

The Five Attacks in Context

The Trivy compromise wasn't an isolated incident. It kicked off twelve days of supply chain attacks on major open-source projects:

The pattern: all five targeted tools with massive reach and deep integration into CI/CD pipelines. All five exploited non-human identities (service accounts, tokens, GitHub Actions). All five weaponized trust that took years to build.

The Bitwarden CLI supply chain attack I covered on April 22 was a downstream effect of the Checkmarx compromise. Attackers used Checkmarx's compromised GitHub Actions workflow to tamper with the Bitwarden CLI npm package. Supply chain attacks cascade.

Your 15-Minute Pipeline Audit

What I'm Doing About It

When I audited keephq/keep's GitHub Actions workflows, I found 60+ unpinned actions across 15 workflow files. Most had excessive permissions. 14 out of 15 checkout steps persisted credentials to disk. That was a snapshot of one repo — and it's representative of the industry.

The Trivy compromise proves the pattern has teeth now. It's not theoretical. The security scanner you trust to find vulnerabilities in your dependencies is itself a dependency with access to your secrets. The threat model is recursive.

Pin your actions. Rotate your credentials. Trust nothing that runs in your pipeline without verifying what it can access.