Popular Security Scanner Trivy Weaponised Against UK DevSecOps Teams in Supply Chain Attack

Executive Briefing: On March 19th, attackers successfully compromised Aqua Security's Trivy vulnerability scanner, one of the most trusted open-source security tools in enterprise DevSecOps pipelines. The sophisticated attack injected credential-stealing malware into official releases and GitHub Actions, affecting the core scanner, trivy-action GitHub Action, and setup-trivy GitHub Action. This represents the second compromise of the widely-used security tool within weeks, exposing UK organisations to supply chain risks through their most trusted security infrastructure.

Trivy is an open-source vulnerability scanner that automatically detects security issues in container images, filesystems, and Git repositories during the software development lifecycle. According to reporting from Wiz, Socket's analysis revealed that attackers force-pushed 75 out of 76 version tags in the aquasecurity/trivy-action repository, effectively turning trusted version references into malware distribution mechanisms.

Key Facts:
- Attackers compromised three critical Trivy components: the core scanner, trivy-action GitHub Action, and setup-trivy GitHub Action on March 19, 2026
- Socket identified that 75 out of 76 version tags were force-pushed in the aquasecurity/trivy-action repository, replacing legitimate releases with malicious code
- This marks the second compromise of Trivy within weeks, indicating persistent targeting of the popular security tool
- The malware specifically targets credential theft, compromising the very security infrastructure organisations rely upon

What Makes This Attack Particularly Dangerous

The compromise of Trivy represents a paradigm shift in supply chain attacks. Rather than targeting generic dependencies, attackers have weaponised a security tool specifically designed to protect against vulnerabilities. When organisations run their automated security scans—a routine part of modern DevSecOps practices—they inadvertently execute malicious code that steals credentials and potentially provides persistent access to development environments.

The NCSC's Supply Chain Security Guidance emphasises that organisations must treat their security toolchain with the same rigour as production systems. This attack demonstrates why: when security tools become attack vectors, the traditional defence-in-depth model collapses. UK organisations using Trivy in their CI/CD pipelines may have unknowingly provided attackers with privileged access to their most sensitive development infrastructure.

The TeamPCP Connection and Attribution Challenges

Security researchers have linked this attack to TeamPCP, a threat actor with a track record of targeting developer toolchains. The group's methodology involves compromising trusted repositories and maintaining persistence through version tag manipulation—a technique that exploits how developers reference specific tool versions in their automation pipelines.

This approach proves particularly effective because DevSecOps teams typically pin their security tools to specific versions for consistency and compliance requirements. When attackers force-push malicious code to existing version tags, organisations continue using what they believe are trusted, tested releases. The attack bypasses traditional dependency scanning because the malicious code appears to come from legitimate, signed repositories.

UK Regulatory Implications for Affected Organisations

Under the UK GDPR and Data Protection Act 2018, organisations that suffer data breaches through compromised development tools face significant regulatory scrutiny. The ICO's guidance on security measures requires organisations to implement appropriate technical measures to protect personal data—including securing the tools used to build and deploy systems that process such data.

For FCA-regulated firms, this incident poses additional challenges. The FCA's operational resilience requirements mandate that firms identify and protect critical business services, including the development infrastructure that supports customer-facing systems. A compromise of security scanning tools could constitute a breach of these operational resilience obligations, particularly if customer data or trading systems are subsequently affected.

Boardroom Questions

• Can our CISO provide assurance that our DevSecOps toolchain receives the same security scrutiny as our production systems, including regular security reviews of third-party scanning tools?
• Do we have controls in place to detect when trusted development tools are compromised, and can we rapidly isolate affected systems from production environments?
• What is our exposure if our automated security scanning infrastructure is compromised, and do we have alternative verification methods for software deployment?

Quick Diagnostic

• Do you maintain an inventory of all security tools used in your CI/CD pipelines, including version numbers and update schedules?
• Can you rapidly identify and isolate development infrastructure from production systems if a security tool becomes compromised?
• Do you have processes to verify the integrity of security tools before they access sensitive development environments or credentials?