Trivy, a widely-used security scanner, was compromised through GitHub Actions tag manipulation, potentially exposing CI/CD secrets across thousands of repositories. This is the second Trivy compromise this month. The tools we use to check security are themselves being compromised, and most companies have no idea how exposed they are.

Socket Security reports that attackers compromised 75 out of 76 version tags in the official Trivy GitHub Action repository. This isn't a case of a developer making a mistake - it's sophisticated supply chain attack by a known threat actor tracked as TeamPCP (also known as DeadCatx3).

The attack mechanism is clever and hard to detect. Rather than modifying branches, which would trigger alerts and code review, the attackers rewrote historical version tags. They created new malicious commits, spoofed the metadata to match original commits, replaced only the entrypoint.sh file with malicious code, and force-pushed these altered commits to existing tags.

For workflows referencing those tags - "over 10,000 workflow files on GitHub" according to the report - nothing appeared to change. The tag name was the same. The commit hash changed, but who checks commit hashes on tags they're already using? The malware just silently started running.

What the infostealer collected is comprehensive and concerning: cloud provider credentials for AWS, GCP, and Azure; SSH keys and GitHub tokens; Kubernetes service account tokens; database credentials; cryptocurrency wallets, particularly Solana validator keypairs. On GitHub-hosted runners with passwordless sudo access, the malware dumped process memory to extract secrets directly.

This is the new attack surface. Not your code, but the automation that builds and deploys it. Not the software you write, but the tools you use to check if that software is secure. The supply chain isn't just dependencies anymore - it's the entire CI/CD pipeline.

The irony is brutal. Teams add Trivy to their workflows specifically to find security vulnerabilities. Instead, Trivy became the vulnerability. The scanner designed to protect you was actively stealing your credentials.

What makes this particularly dangerous is the trust model. When you add a security tool to your CI/CD pipeline, you give it access to everything. It needs to scan your code, check your dependencies, analyze your containers. That access is exactly what attackers want.

The only tag that remained uncompromised was version 0.35.0. For organizations using Trivy via GitHub Actions, the immediate fix is pinning to that specific version or switching to commit hash references rather than tags. But that's treating the symptom, not the disease.

The broader problem is how we think about supply chain security. Most security guidance focuses on your dependencies - use lock files, verify checksums, audit packages. But your CI/CD pipeline has dependencies too: GitHub Actions, container images, build tools. Those need the same scrutiny.

Organizations should be auditing what secrets their CI/CD pipelines can access and whether they actually need all that access. Principle of least privilege applies to automation too. Your security scanner probably doesn't need your production database credentials.

There's also the question of detection. How many organizations noticed this compromise before Socket Security published their report? My guess is close to zero. Most companies don't monitor what their CI/CD workflows are doing beyond "did the build succeed?" Outbound network connections from build containers rarely get scrutinized.

This was the second Trivy compromise in March. The first involved the OpenVSX extension marketplace. The pattern suggests these aren't opportunistic attacks - someone is systematically targeting the security tool supply chain. That's deeply concerning.

The attribution to TeamPCP/DeadCatx3 indicates this is an organized operation focused on cloud-native infrastructure. They're not after credit cards or personal information - they're after cloud credentials, Kubernetes tokens, crypto wallets. The targets are valuable and the attackers are sophisticated.

What's needed is defense in depth. Don't trust your security tools implicitly. Pin to specific commits, not tags. Monitor for unusual network activity in CI/CD environments. Rotate credentials regularly. Use ephemeral credentials when possible. Assume compromise and design accordingly.

The technology is impressive - both the security tooling and the attacks against it. The question is whether we understand the threat model well enough to defend against it. Right now, the answer is clearly no.