What happened
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.
The attack didn't need to find a vulnerability in your code. It exploited the fact that your CI/CD pipeline runs tools with access to your environment — and your API keys live in that environment as plaintext strings.
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.
ENTRY POINT
Attacker compromises Trivy release
Exploits mutable Git tags and self-declared commit identity to inject malware into official v0.69.4 release binary.
PROPAGATION
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.
EXFILTRATION
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.
WHERE VAULTPROOF BREAKS THE CHAIN
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.
The blind spot
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.
The solution
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.