Trivy Breach Round 2: GitHub Actions Hijacked for CI/CD Secret Theft
Has anyone else caught the latest on Aqua Security’s Trivy? This is the second time in a month their supply chain has been hit. The aquasecurity/trivy-action and aquasecurity/setup-trivy repositories had roughly 75 tags hijacked to push malware designed to exfiltrate CI/CD secrets.
What makes this particularly nasty is the payload. The modified actions aren't just scanning containers; they're actively scraping the GITHUB_TOKEN and other environment variables, sending them off to a remote C2 server. If you're relying on Trivy in your pipelines, you need to audit your workflow YAML files immediately.
The immediate remediation is pinning your actions to a specific commit SHA rather than using floating tags like @master or loose semver ranges. Here is a quick bash snippet to identify vulnerable usages in your repos:
#!/bin/bash
# Scans for unpinned or floating tag usage of Trivy actions
grep -rn "uses: aquasecurity/trivy-action" .github/workflows/ | grep -v "@"
And here is how you should be pinning the action in your YAML:
- name: Run Trivy Vulnerability Scanner
uses: aquasecurity/trivy-action@0.19.0 # Pin to a known safe version
with:
scan-type: 'fs'
scan-ref: '.'
Given the frequency of these attacks on core security tooling, are we reaching a tipping point where we need to mirror these critical tools internally? How is everyone handling third-party action validation in their CI/CD pipelines?
This is exactly why we moved away from floating tags entirely. We use a Renovate bot to manage our dependencies, but it's configured to require pull requests for action updates rather than auto-merging.
On the detection side, we've started implementing egress filtering on our GitHub runners. They shouldn't be talking to the open internet except for specific package registries. Blocking arbitrary outbound HTTP requests would have killed this C2 callback instantly.
The irony of a vulnerability scanner introducing a vulnerability is painful. We're switching to Grype by Anchore for the time being while Aqua sorts this out.
If you want to validate your current runners without scanning code, check the Actions runner logs for unexpected curl or wget commands executed by the trivy-action step. The malware typically tries to beacon out immediately after the checkout step.
We actually saw this in our SOC environment yesterday. An alert fired on an anomalous user agent string coming from our build runner. The payload was trying to POST JSON data to a non-corporate IP.
For anyone needing to rotate secrets, assume your GITHUB_TOKEN permissions were scoped to repo: write. You'll need to invalidate all PATs and review the audit logs for pushes to protected branches during the compromise window.
Pinning to a specific commit SHA is the only way to truly prevent this, rather than just avoiding floating tags. For those auditing their orgs, this simple grep helps identify workflows still using mutable refs:
grep -rn "uses:" .github/workflows/ | grep -v "@"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access