How the Trivy supply chain attack harvested credentials from secrets managers

The anatomy of the attack

On March 19, 2026, Aqua Security's Trivy — one of the most widely used vulnerability scanners in the world — was compromised. Attackers injected credential-harvesting logic directly into the official release binary.

The payload was sophisticated: scans appeared to complete and pass normally. The credential exfiltration ran silently alongside legitimate functionality. Teams had no indication anything was wrong.

This is the supply chain attack model that makes traditional secrets management insufficient: if the key exists as a plaintext string anywhere in your runtime environment, a compromised tool can find and exfiltrate it.

Attacker compromises Trivy release

Exploits mutable Git tags and self-declared commit identity to inject malware into official v0.69.4 release binary.

GitHub Actions pick up the payload

Both trivy-action and setup-trivy GitHub Actions are simultaneously compromised. Millions of CI/CD pipelines now run malicious code.

Credentials harvested from runtime environment

The malicious payload accesses plaintext API keys from environment variables — exactly where every secrets manager places them after retrieval. Keys sent to attacker C2 server.

No plaintext key exists to steal

With VaultProof, the full API key never exists in the CI/CD environment. Only cryptographic shares are present — individually useless to an attacker. Nothing to harvest.

Why your secrets manager didn't help

Every secrets manager available in March 2026 — Vault, AWS Secrets Manager, Doppler, Infisical — follows the same retrieval model. You store the key encrypted. Your CI/CD pipeline retrieves it via API at runtime. The key becomes a plaintext environment variable that your tools can read.

This is intentional. It's how these tools are designed. They protect the key at rest — not in use.

$ doppler run -- npm test
# Doppler retrieves OPENAI_API_KEY from vault...
# Sets it as environment variable...
export OPENAI_API_KEY=sk-proj-Ab3xK9mNpQ...
# ↑ Plaintext. In the environment.
# Every tool this pipeline runs can read it.
# Including a compromised Trivy binary.

Running tests...
Running Trivy scan...
OPENAI_API_KEY exfiltrated to 185.220.101.x
✓ Trivy scan passed (0 vulnerabilities found)

The Trivy malware didn't need to find a vulnerability. It just read what was already there. Your secrets manager did exactly what it was designed to do — and the attacker still got the key.

What would have stopped this

The only complete defense against a supply chain attack targeting credentials is to ensure the credential doesn't exist as plaintext in the environment at any point.

VaultProof uses split-key architecture to divide API keys into cryptographic shares. Your CI/CD pipeline never has the full key — only shares. Even if a compromised tool reads every byte of the environment, it finds nothing useful.

Key Registration

Your API key is split into N shares. Distributed to separate storage. Each share is individually useless.

Runtime Request

Your app requests the API call. VaultProof proxy collects shares, reconstructs key in memory for milliseconds only.

Call Complete

API call succeeds. Reconstructed key is zeroed from memory. No plaintext key was ever in your app environment.

If Trivy was running during this process, it would find nothing. There is no credential to harvest. The attack model breaks entirely when the key doesn't exist in the runtime environment.