Supply-Chain Attack on Trivy: When the Security Scanner Itself Becomes a Weapon

8 min Reading Time

On March 19, 2026, the popular vulnerability scanner Trivy itself became an attack vector. 75 out of 76 version tags in the GitHub repository were compromised, and a manipulated binary stole SSH keys, cloud credentials, and Kubernetes secrets from CI/CD pipelines. The attack reveals a pattern that intensified in 2026: attackers are no longer targeting applications – they’re targeting the tools meant to secure them.

According to the BSI (Federal Office for Information Security) 2025 situation report, supply-chain attacks in Germany have doubled. The average detection time stands at 287 days – nearly ten months during which compromised code runs undetected in production environments. Anyone developing, purchasing, or operating software must recognize their own supply chain as an attack surface. This article uses recent cases to show what happens, which patterns repeat, and what actually helps.

TL;DR

• Trivy attack, March 2026: 75 version tags compromised, a three-stage infostealer extracted CI/CD secrets to a typosquatting domain. Affected: thousands of DevSecOps teams worldwide (Aqua Security, CrowdStrike, Wiz).
• 156% more malicious open-source packages year-over-year. Since 2019, over 704,000 malicious packages have been identified (Sonatype 2024).
• 74% of all codebases contain high-risk open-source vulnerabilities (Synopsys OSSRA 2024).
• SBOM becomes mandatory: The EU Cyber Resilience Act requires manufacturers to provide a machine-readable software bill of materials. Core obligations take effect December 2027, reporting requirements begin September 2026.
• BSI: 119 new vulnerabilities per day – a 24% increase. 48% of KRITIS operators lack attack detection (BSI Situation Report 2025).

The Trivy Attack: When the Scanner Becomes a Trojan

Trivy is one of the most widely used open-source vulnerability scanners in DevSecOps. It checks container images, filesystems, and IaC templates for vulnerabilities – and runs in thousands of CI/CD pipelines as a GitHub Action. That’s exactly where the attackers struck.

The group “TeamPCP” first compromised GitHub Actions credentials for the Trivy project in late February 2026. Aqua Security’s initial response was incomplete – the credential rotation didn’t cover all access points. On March 19, the second wave hit: 75 out of 76 version tags in the aquasecurity/trivy-action repository were force-pushed to redirect to malicious code. All seven tags in aquasecurity/setup-trivy were also affected.

The injected code operated in three stages. First: harvesting environment variables and credentials from the CI/CD runner’s memory. Second: encrypting sensitive data – SSH keys, cloud credentials, database tokens, Kubernetes secrets. Third: exfiltrating the data to the typosquatting domain scan.aquasecurtiy[.]org – a deliberately misspelled domain name.

The irony: a tool designed to find vulnerabilities became one itself. The attack could have been largely prevented through SHA-based pinning of GitHub Actions. Those who referenced a specific commit hash instead of trivy-action@v0.35.0 would not have been affected by the tag poisoning.

The Pattern: XZ Utils, 3CX, and the Long-Term Strategy

Supply-chain attacks increasingly follow a pattern: build trust, compromise infrastructure, spread widely.

The most extreme example is the XZ Utils backdoor from March 2024 (CVE-2024-3094, CVSS 10.0). An attacker using the pseudonym “Jia Tan” spent three years building trust with the maintainer of the widely used compression library. In the end, they implanted a backdoor that enabled remote code execution via OpenSSH – on a component running on practically every Linux server. The attack was discovered by chance: PostgreSQL developer Andres Freund noticed an unusual delay during SSH logins.

In the 3CX attack (March 2023), Mandiant documented the first “double supply chain compromise”: the Lazarus Group first compromised the trading software X_Trader, infected a 3CX employee through it, and then manipulated the build environments. The signed desktop app was delivered to 600,000 companies with 12 million users.

The common pattern in all three cases: the attack vector wasn’t the application – it was the infrastructure behind it. Build systems, code repositories, dependency registries. Those who secure only their own application but blindly trust their tools and dependencies leave an open flank that is increasingly exploited. Gartner predicted in 2022 that by 2025, 45% of all organizations would experience attacks on their software supply chains. A BlackBerry survey in 2024 found: it’s already 75%.

“Managing supply chain risks remains one of the biggest challenges for CISOs.”
– Philip Reitinger, CEO Global Cyber Alliance, paraphrased (SecurityWeek Cyber Insights 2024)

The Numbers: Why the Problem Is Growing Exponentially

The Sonatype State of the Software Supply Chain Report 2024 documents a 156% year-over-year increase in malicious open-source packages. Since 2019, over 704,000 malicious packages have been identified in registries like npm, PyPI, and Maven – more than 512,000 of them since November 2023 alone.

The Synopsys OSSRA Report 2024 adds: 96% of examined codebases contain open-source components. 84% contain at least one known vulnerability. 74% contain high-risk vulnerabilities – a 54% jump from the previous year. And 91% use components that are ten or more versions out of date.

A new phenomenon has emerged: “slopsquatting” – attackers exploit the tendency of AI code assistants to hallucinate non-existent package names. They register these names and fill them with malicious code. If a developer uncritically accepts the AI’s suggestion, the malware is automatically installed.

The “slopsquatting” problem is particularly insidious because it grows with the adoption of AI coding assistants. According to ReversingLabs, 14 out of 23 crypto-related malware campaigns in 2024 targeted npm packages. In September 2025, 20 compromised npm packages collectively had over two billion weekly downloads. The attack surface isn’t expanding linearly – it grows with every new package a developer installs, with every new dependency a build system automatically resolves. And in 95% of cases where developers use a vulnerable component, a patched version already exists, according to Sonatype. The problem isn’t the availability of fixes – it’s the lack of attention to updates.

The costs are measurable: according to the IBM Cost of a Data Breach Report 2024, the average cost of a data breach is $4.88 million – an all-time high. Supply-chain compromises were slightly higher, according to IBM’s analysis, and were the second most common attack vector.

For German companies, the situation is exacerbated by two parallel developments. First: the NIS2 directive makes supply-chain security a legal obligation for around 29,500 companies – including personal liability for executives in case of negligence. Second: the IT security skills shortage means many companies don’t have enough staff to systematically review their dependencies. The BSI reports that while 80% of KRITIS operators have established information security management systems, there are significant gaps in business continuity management. When a critical dependency is compromised and there’s no incident response plan, those 287 days until detection become particularly painful.

Why Traditional Security Tools Aren’t Enough

Most enterprise security is based on a model that doesn’t cover supply-chain attacks: perimeter protection, endpoint detection, network segmentation. These tools detect malware coming from outside – but not malicious code infiltrated through trusted channels.

In the Trivy attack, the malicious code came through a tool explicitly deployed as a security measure. No antivirus would have raised an alarm, no firewall log would have shown an anomaly. The attack exploited the normal CI/CD pipeline – the same paths used to deliver legitimate code. To intrusion detection systems, everything looked like business as usual.

That’s why traditional penetration tests also fail against supply-chain risks. A pentest examines your own infrastructure – not the build systems of the open-source projects you depend on. And an audit of your own codebase won’t find a backdoor in an upstream dependency buried 50 versions deep.

What’s needed instead: shift left in the supply chain – security checks not just at the end of the pipeline, but for every single dependency. That means: every package is vetted when it enters the codebase, not just at deployment. Every GitHub Action is pinned by SHA, not referenced by tag. And every build process is cryptographically signed and verified – before a single byte goes into production.

The paradigm shift is comparable to the adoption of Zero Trust in networks: no longer “everything inside the perimeter is trusted,” but “nothing is trusted until verified” – and that includes your own development tools.

Germany: 119 Vulnerabilities Per Day and the SBOM Mandate

The BSI’s 2025 situation report documents 119 new security vulnerabilities per day during the reporting period – a 24% increase. 461 data leaks with German institutions as victims. And 48% of KRITIS operators lack any system for attack detection.

The EU Cyber Resilience Act (in force since December 10, 2024) requires all manufacturers of products with digital elements to provide a machine-readable SBOM. Core obligations take effect December 11, 2027, with reporting requirements beginning September 11, 2026. Violations can result in fines of up to 15 million euros or 2.5% of global annual revenue.

The BSI has defined concrete SBOM requirements in TR-03183-2 (August 2025). Recommended formats: SPDX and CycloneDX. For NIS2-regulated companies, supply-chain security is explicitly part of legal requirements.

In the U.S., Executive Order 14028 has been in effect since 2021: every software vendor supplying the federal government must provide an SBOM. The deadline for implementation was September 2023. Europe is following suit with the CRA – and goes even further with reporting requirements starting September 2026. For German SMEs supplying both the U.S. and EU, SBOMs aren’t optional – they’re a market access requirement on both sides of the Atlantic.

The financial stakes are significant: according to the IBM Cost of a Data Breach Report 2024, the average cost of a supply-chain incident is nearly $5 million. For a mid-sized company with 500 employees, this can be existential – especially when detection takes nearly ten months and additional systems are compromised during that time. Regulatory consequences add to the burden: under NIS2, inadequate supply-chain security can result in fines of up to 10 million euros and personal executive liability. Under the CRA, an additional 15 million euros in fines can be imposed. The cost of prevention – SBOM tooling, dependency scanning, half an FTE for supply-chain security – is in the low five figures per year. The ratio of investment to potential damage justifies every one of these measures.

What Actually Protects: Six Evidence-Based Measures

1. SHA-based dependency pinning. Instead of referencing GitHub Actions by tag (e.g., @v1), pin the specific commit hash. Tags can be overwritten by attackers; SHA hashes cannot. The entire Trivy attack would have been neutralized.

2. Create and maintain an SBOM. If you don’t know which dependencies are in your software, you can’t respond when the next CVE is announced. Tools like Syft automatically generate SBOMs from container images.

3. Implement SLSA Level 2. The Supply-chain Levels for Software Artifacts framework secures build integrity. Level 2 – digitally signed build provenance – can be achieved in a few weeks with cosign and GitHub OIDC.

4. Dependency scanning in the CI/CD pipeline. Automated review of every dependency with every build. Tools: Dependabot, Snyk, Grype. No push without a green security check.

5. Code signing with Sigstore. Free, open-source, enables cryptographic signatures for binaries and packages. Tampering becomes provable.

6. Regular vendor risk assessments. Don’t just audit your own software – also review your suppliers. If you use a vulnerability scanner, you should know whether its CI/CD pipeline is hardened.

The combination of these six measures forms the minimum for robust supply-chain security. No single measure is sufficient alone. SHA pinning without dependency scanning won’t detect known vulnerabilities. An SBOM without vendor assessment shows your dependencies but not their security status. And code signing without SLSA only proves who signed – it doesn’t confirm whether the build process was clean. The strength lies in the combination: transparency (SBOM), integrity (SLSA + signing), verification (scanning + assessment), and hardening (pinning).

The crucial point: supply-chain security isn’t a one-time project. It’s a continuous process that must be integrated into every build, every deployment, and every procurement decision. The Trivy attack demonstrated that even tools meant to guarantee security can be compromised. Those who understand this build their defenses not on trust – but on verification.

“Attacks on the software supply chain of our global ICT infrastructure are becoming more frequent, more aggressive, and more consequential.”
– CISA, Defending Against Software Supply Chain Attacks, paraphrased

The lesson from 2024, 2025, and the first quarter of 2026 is clear: software supply chains are the new primary attack surface. Ignoring them means relying on trust in a world that demands verification. The Trivy case is particularly instructive – not because it was technically novel, but because it shows that even defensive tools are vulnerable. The answer isn’t distrust of open source. It’s systematic verification: every dependency checked, every build signed, every change traceable. It’s labor-intensive. But the alternative – 287 days with compromised code in production – is far worse.

Frequently Asked Questions

What was the Trivy supply-chain attack?

In March 2026, the group TeamPCP compromised the open-source vulnerability scanner Trivy from Aqua Security. 75 out of 76 version tags in the GitHub repository were redirected to malicious code. The injected code stole CI/CD secrets such as SSH keys, cloud credentials, and Kubernetes tokens.

What is an SBOM, and why is it becoming mandatory?

A Software Bill of Materials is a machine-readable inventory of all software components in a product. The EU Cyber Resilience Act makes it mandatory starting December 2027. Common formats include CycloneDX and SPDX.

How can I protect myself against supply-chain attacks?

The most important measures: SHA-based pinning of dependencies, automated dependency scanning in the CI/CD pipeline, creating and maintaining an SBOM, code signing with Sigstore, and regular vendor risk assessments.

What is SHA-based pinning?

Instead of referencing a GitHub Action by version tag (e.g., @v1), you use the specific commit hash. Tags can be overwritten by attackers; SHA hashes cannot.

How long do supply-chain attacks remain undetected?

According to the BSI’s 2025 situation report, the average detection time is 287 days. In the case of the XZ Utils backdoor, the preparation took three years.

Which German companies are affected?

Every company that uses or operates software. Particularly exposed: companies under NIS2 regulation (around 29,500 in Germany) and KRITIS operators.

What is SLSA?

Supply-chain Levels for Software Artifacts – a tiered model for build integrity. Level 2 can be implemented in a few weeks using cosign and GitHub OIDC.

Header Image Source: Pexels / Tima Miroshnichenko (px:5380603)

About the author: Benedikt Langer

More articles by Benedikt Langer