When Your Security Scanner Becomes the Weapon: Lessons from the Trivy Supply Chain Attack

This article was originally published on LucidShark Blog.

---

When Your Security Scanner Becomes the Weapon: Lessons from the Trivy Supply Chain Attack

On March 19, 2026, a group called TeamPCP compromised 75 tags of the aquasecurity/trivy-action GitHub Action. The attack involved silently executed attacker-controlled code that appeared to function normally while exfiltrating credentials. The incident lasted five days before detection on March 24.

Critical Warning: If your CI/CD pipeline ran trivy-action or setup-trivy without a pinned commit SHA between March 19 and March 24, 2026, treat all secrets accessible from that pipeline as compromised.

How the Attack Worked

TeamPCP exploited GitHub Actions mutable tag system by compromising a maintainer account at Aqua Security through targeted phishing. They force-pushed release tags to point to commits containing WAVESHAPER.V2, a cross-platform remote access tool.

The attack remained nearly undetectable because:

• The action executed successfully with plausible scan results
• The malicious binary ran the legitimate Trivy scan and forwarded results
• The payload executed in-memory and self-deleted
• No unexpected files remained in the workspace
• GitHub Actions logs appeared normal

Only network egress monitoring could have reliably detected the C2 callback to 142.11.206.73 and sfrclak.com.

The Three-Layer Trust Model Problem

Layer 1: Mutable References - Tags and versions are pointers, not guarantees. Only full commit SHAs are immutable.

Layer 2: Elevated Trust by Design - Security scanners require broad file system access, making compromised versions catastrophic.

Layer 3: Trust from Reputation - Teams trust based on vendor reputation rather than cryptographically grounded verification.

Accessible Data at Risk

Any CI/CD job running a compromised action exposes:

• GITHUB_TOKEN (automatic, grants repository access)
• Container registry credentials (Docker Hub, GHCR, ECR, GCR, ACR)
• Cloud provider credentials (AWS, GCP, Azure)
• Kubernetes service account tokens
• Any environment-injected secrets

Hardening Recommendations

1. Pin to Commit SHA

Replace tag references with full commit SHAs:

# Before: mutable tag reference
- uses: aquasecurity/trivy-action@v0.29.0

# After: pinned to immutable commit SHA
- uses: aquasecurity/trivy-action@a2901b0d1cf3ff4857f5cdf63e42e26d35cfa5e1

2. Verify Binary Signatures

Use cosign to verify binaries before execution with certificate identity and OIDC issuer validation.

3. Apply Minimal Permissions

Restrict job permissions to only what is needed; avoid injecting unrelated credentials into security scan jobs.

4. Enable Network Egress Monitoring

Use StepSecurity harden-runner to monitor and control outbound connections during CI/CD runs.

Consider a Local-First Alternative

Running security tooling locally before code reaches CI reduces credential exposure and limits blast radius to your workstation rather than entire pipeline credential sets.

Incident Response Steps

If your pipeline ran trivy-action or setup-trivy between March 19 and March 24, 2026:

• Rotate GITHUB_TOKEN and all Personal Access Tokens
• Rotate container registry credentials
• Rotate cloud provider credentials (AWS, GCP, Azure)
• Audit and rotate Kubernetes service accounts
• Check network logs for IOC indicators (connections to 142.11.206.73 or sfrclak.com)

Hardening Checklist

• Pin all actions to commit SHA
• Verify scanner binary signatures
• Restrict job permissions to minimum required
• Separate unrelated secrets from security scan jobs
• Enable egress monitoring on CI runners
• Rotate credentials exposed during the compromise window
• Consider local-first pre-commit scanning to reduce CI exposure