The Trivy Supply Chain Attack: A Wake-Up Call for Every Organization Running CI/CD Pipelines

By Rubi Arbel, Co-Founder, Resilience Cyber Security

Published: March 24, 2026

On March 19, 2026, a threat actor group known as TeamPCP executed one of the most significant software supply chain attacks of the year - compromising Aqua Security's Trivy vulnerability scanner, an open-source tool trusted by thousands of organizations worldwide to secure their CI/CD pipelines. The irony is unmistakable: a security tool designed to find vulnerabilities became the very weapon used to steal credentials, secrets, and cryptographic keys from the pipelines it was supposed to protect.

At Resilience Cyber Security, we have spent years helping organizations build defensible software supply chains through evidence-based security, continuous assurance, and zero-trust SDLC architectures. The Trivy incident validates every principle we have been advocating, and exposes the catastrophic consequences of trust-based security models that treat open-source dependencies as inherently safe.

This post breaks down the attack, explains what went wrong at every stage, and maps out how Resilience's approach to software supply chain security could have prevented or drastically contained the damage.

What Happened: Anatomy of the Attack

Phase 1 — Initial Foothold (Late February 2026)

The attack began in late February when TeamPCP exploited a misconfiguration in Trivy's GitHub Actions environment. An autonomous bot exploited a pull_request_target workflow to steal a privileged Personal Access Token (PAT). This token gave the attackers persistent access to Trivy's repository automation and release infrastructure.

On March 1, the Trivy maintainers disclosed the initial incident and executed a credential rotation. However, and this is the critical failure, the rotation was incomplete. The attacker retained residual access via credentials that were never revoked.

Phase 2 — Weaponization and Release (March 19, 2026)

With retained access, TeamPCP struck decisively on March 19. They carried out a multi-pronged attack across the entire Trivy ecosystem:

The Trivy binary itself (v0.69.4): The attacker pushed a commit that swapped the legitimate actions/checkout reference to an imposter commit spoofing a known contributor. This commit fetched credential-stealing code from a typosquatted domain (scan.aquasecurtiy[.]org) and triggered a release of backdoored binaries to GitHub Releases, Docker Hub, GHCR, and ECR. A --skip=validate flag was added to goreleaser to bypass binary validation.

GitHub Actions (trivy-action and setup-trivy): 76 of 77 trivy-action version tags and all 7 setup-trivy tags were force-pushed to point at malicious commits. Any pipeline referencing these tags by version (a common practice) would silently execute the TeamPCP credential stealer before running the legitimate scan, appearing completely normal in workflow logs.

Additional repository compromise: The aqua-bot service account was compromised, giving attackers the ability to push malicious workflows to other Aqua repositories including tfsec, traceeshark, and trivy-action. GPG keys and credentials for Docker Hub, Twitter, and Slack were exfiltrated to a Cloudflare Tunnel command-and-control server.

Phase 3 — Credential Harvesting at Scale

The malicious payload, self-labeled "TeamPCP Cloud stealer", was engineered for maximum damage. When executed on a GitHub Actions runner, it performed the following operations:

• Dumped Runner.Worker process memory by reading /proc/<pid>/mem and searching for secret patterns

• Harvested SSH keys, cloud provider credentials, database tokens, Kubernetes secrets, Docker configurations, and cryptocurrency wallet keys

• Encrypted the collected data using AES-256 and RSA-4096

• Exfiltrated it to a remote server, with a fallback mechanism that created a repository named tpcp-docs in the victim's GitHub account

On developer machines (detected by checking whether the GITHUB_ACTIONS environment variable was absent), the malware additionally deployed a Python-based persistence dropper.

Phase 4 — Cascading Compromise and Expansion

The attack did not stop with Trivy. Research from Sysdig revealed that stolen credentials from the Trivy compromise were used to poison additional GitHub Actions, including Checkmarx's AST Action - demonstrating a cascading supply chain effect where one compromised action yields tokens that enable poisoning of entirely separate tools.

Meanwhile, TeamPCP expanded operations into the npm ecosystem, deploying a self-propagating worm dubbed "CanisterWorm" that infected over 47 npm packages. The worm used a decentralized command-and-control infrastructure based on Internet Computer Protocol (ICP) canisters, making it resilient to traditional takedown efforts.

By March 22, the same attacker group defaced all 44 repositories in Aqua Security's internal GitHub organization, renaming them with "tpcp-docs-" prefixes — a brazen demonstration that the breach extended far beyond the open-source project.

What Went Wrong: The Structural Failures

This attack is not simply a story of one stolen credential. It exposes deep structural weaknesses in how the industry approaches software supply chain security:

Mutable version tags as trust anchors. The entire GitHub Actions ecosystem relies on version tags that can be silently rewritten. When organizations reference aquasecurity/trivy-action@0.24.0 instead of pinning to an immutable commit SHA, they are placing unconditional trust in a mutable pointer - a trust assumption the attacker exploited to perfection.

Incomplete credential rotation. The initial incident was disclosed and partially remediated. But partial rotation is worse than no rotation - it creates a false sense of security while the attacker retains access. Without continuous verification that all credentials have been revoked, organizations are flying blind.

No integrity validation of released artifacts. The backdoored Trivy binary was published to GitHub Releases, Docker Hub, GHCR, and ECR. At no point in this distribution chain was there an independent integrity validation that could catch the fact that v0.69.4 contained unauthorized code. The attacker even added --skip=validate to goreleaser, and the release pipeline happily complied.

Trust-based, not evidence-based, security. Pipelines trusted that the Trivy action was safe because it came from a known publisher. There was no continuous verification of provenance, no attestation of what code was actually built, no policy gate validating the integrity of dependencies before execution.

No runtime monitoring of build environments. As Sysdig's research demonstrated, runtime detection was the only control that caught both the Trivy and Checkmarx waves, because it observed actual system-call behavior rather than relying on signatures, domain reputation, or tag-based trust.

How Resilience Cyber Security Addresses Every Stage of This Attack

At Resilience Cyber Security, we have built our entire practice around the principle that modern software supply chain security must be evidence-based, continuous, and zero-trust. Here is how our solutions and methodology map directly to the failures exposed by the Trivy attack.

1. Continuous Evidence Collection and Attestation

Resilience's core technology, inherited from Scribe Security's platform, generates signed attestations and machine-readable evidence at every stage of the software development lifecycle. Every build, every dependency resolution, every artifact publication produces a cryptographically signed record of what happened, when, and by whom.

In the context of the Trivy attack, this means:

• Every GitHub Action execution would generate an attestation recording the exact commit SHA that was checked out, the hash of the code that was executed, and the environment in which it ran.

• Any deviation, such as a version tag suddenly pointing to a different commit, or an action downloading code from an unknown domain, would be immediately visible in the evidence record, flagged by policy, and blocked by guardrails before the pipeline proceeds.

This is the difference between trust-based and evidence-based security. You don't trust that trivy-action@0.24.0 is safe. You verify, continuously, that the code it resolves to matches the expected provenance.

2. Guardrails-as-Code in CI/CD Pipelines

Resilience deploys policy gates directly into build pipelines — not as afterthoughts, but as enforceable guardrails that prevent unauthorized code from executing. These guardrails operate on the principle of "prove, don't assume."

For the Trivy scenario specifically:

• Commit SHA pinning enforcement: A Resilience guardrail policy would require all GitHub Actions to be pinned to full, immutable commit SHAs. Any workflow referencing a mutable tag would fail the policy gate before execution, completely neutralizing the tag-repointing attack vector.

• Domain allowlisting for build-time downloads: The malicious checkout fetched code from a typosquatted domain. Resilience's policy engine can enforce that build steps only access approved domains and registries, blocking outbound connections to unknown infrastructure.

• Binary validation gates: The attacker explicitly disabled goreleaser's validation (--skip=validate). Resilience's guardrails would enforce that all release artifacts pass integrity and provenance validation as a hard gate before publication to any registry.

  
  

3. Continuous Code Signing and Provenance Verification

Resilience's approach includes continuous code signing using in-toto attestations and provenance chains that track every artifact from source to deployment. This creates an unbroken chain of custody that makes tampering detectable.

Had the Trivy ecosystem been protected by Resilience's integrity framework:

• The backdoored v0.69.4 binary would lack a valid provenance attestation matching the expected build process. Any consumer verifying provenance before pulling the image from Docker Hub or GHCR would immediately see that the artifact's attestation was missing, invalid, or inconsistent with the expected build pipeline.

• Force-pushed tags would trigger provenance chain breaks — the new commits pointed to by the tags would not have valid attestations from the expected CI system, making the tampering immediately detectable.

  
  

4. SBOM-Based Risk Management and Impact Analysis

Resilience generates and manages Software Bills of Materials (SBOMs) as living documents, continuously updated as the software supply chain evolves. Our evidence graph models lineage across repositories, pipelines, registries, and environments.

When the Trivy compromise was disclosed, organizations protected by Resilience could immediately answer critical questions:

• Which of our pipelines reference trivy-action, and which specific versions?

• Which builds executed between March 19 and March 20?

• Which artifacts were produced by those builds, and where are they deployed?

• What secrets were accessible to those runner environments?

This is the difference between scrambling to audit hundreds of repositories manually and having instant, automated impact analysis across your entire software factory.

5. Anti-Tampering and Integrity Validation

Resilience's tooling performs integrity validation at the artifact level, generating signed SBOMs, provenance records, and continuous signing that detects unauthorized modifications. The anti-tampering controls operate on the principle that every artifact must prove its integrity before it is trusted.

The Trivy attacker published malicious images to Docker Hub tagged as versions 0.69.4 through 0.69.6, without corresponding GitHub releases. Resilience's integrity validation would catch this discrepancy: an image appearing in a registry without a matching, signed build attestation from the expected CI pipeline is a clear indicator of tampering.

6. AI-Powered Security Operations

Resilience's AI-agentic workflows act as a virtual security engineer embedded in the platform, providing natural-language querying, risk warnings, and prioritized remediation guidance grounded in the evidence graph.

In an active incident like the Trivy compromise, our agentic workflows could:

• Alert security teams the moment anomalous attestations or provenance breaks are detected

• Automatically correlate the compromised action versions with affected pipelines across the organization

• Generate prioritized remediation tasks, including which secrets need immediate rotation

• Create Jira tickets for each affected team with specific, actionable guidance

This transforms incident response from a manual, error-prone scramble into an AI-assisted, evidence-driven workflow.

The Broader Lesson: From Trust to Proof

The Trivy attack is not an isolated incident. It follows the tj-actions/changed-files compromise of 2025 and represents a growing pattern of CI/CD supply chain attacks that exploit the trust-based foundations of modern development infrastructure. As Sysdig's research noted, the rising frequency of these attacks makes continuous monitoring and evidence-based security more critical than ever.

The fundamental problem is not that Aqua Security failed — any organization maintaining widely-used open-source tooling faces this risk. The problem is that the ecosystem's security model is built on assumptions rather than evidence:

• We assume version tags are immutable. They are not.

• We assume credential rotations are complete. They often are not.

• We assume published artifacts match their source. Without verification, we cannot know.

• We assume our CI runners are clean. Without runtime monitoring, we cannot prove it.

Resilience Cyber Security exists to replace every one of these assumptions with verifiable evidence. Our approach: continuous attestation, guardrails-as-code, provenance verification, integrity validation, and AI-powered security operations, creates a defense-in-depth architecture where a compromise like the Trivy attack is detected, contained, and blocked at multiple independent points before it can cause damage.

Actionable Recommendations

For organizations responding to the Trivy incident or seeking to harden their software supply chains against similar attacks, we recommend the following immediate actions:

Audit your CI/CD pipelines for mutable action references. Any workflow referencing GitHub Actions by version tag rather than commit SHA should be updated immediately.

Verify that no Trivy versions between v0.69.4 and v0.69.6 were executed in your environment during the March 19–20 window. Check for the presence of repositories named tpcp-docs in your GitHub organization as an indicator of successful exfiltration.

Rotate all secrets that were accessible to any runner environment that may have executed a compromised version of trivy-action or setup-trivy.

Implement continuous integrity verification for all build-time dependencies, not just application dependencies. Your security tooling is part of your supply chain and must be treated accordingly.

Move from periodic audits to continuous assurance. If your security posture depends on point-in-time assessments, you are inherently vulnerable to attacks that occur between assessments.

About Resilience Cyber Security

Resilience Cyber Security provides tailored solutions for SDLC security and compliance, software supply chain assurance, and AI-driven development risk management. Our solutions and services, built on over 25 years of cybersecurity leadership in the Israeli cyber ecosystem, help CISOs, Product Security leaders, and DevSecOps teams move from trust-based security to evidence-based continuous assurance.

To learn how Resilience can help secure your software supply chain, visit https://www.resilience-sec.com/ or connect with us on LinkedIn.

-----------------------------------------------------------------------------------------

The information in this blog post is based on publicly available research from Wiz Research, CrowdStrike, Sysdig Threat Research, Socket Security, The Hacker News, SecurityAffairs, and Aqua Security's own incident disclosure. Resilience Cyber Security is not affiliated with any of these organizations.