On March 19, 2026, TeamPCP compromised Aqua Security's Trivy vulnerability scanner—a tool millions of developers rely on to find security flaws. The attackers didn't exploit a zero-day in the scanner itself. They exploited the CI/CD pipeline that builds and distributes it, turning a security tool into malware distribution infrastructure.
What Happened
TeamPCP gained unauthorized access to Aqua Security's GitHub Actions workflows. Once inside, they exfiltrated credentials stored in or accessible through the CI/CD environment. The group claims to have obtained 300 GB of compressed credentials—enough to compromise downstream projects that depend on Trivy or share infrastructure with Aqua Security's build systems.
The attackers modified the build pipeline to inject malicious code into Trivy releases. Because Trivy is a security scanner, it runs with elevated privileges in many environments. Organizations scanning container images, analyzing infrastructure-as-code, or checking dependencies for vulnerabilities were now executing attacker-controlled code with those same privileges.
Timeline
March 19, 2026: Initial compromise of Aqua Security's CI/CD pipeline. TeamPCP gains access to GitHub Actions workflows and begins credential harvesting.
[Timeline beyond this point requires additional facts from the source that were not provided]
Which Controls Failed
Credential Exposure in CI/CD
The 300 GB credential haul points to secrets stored where the CI/CD pipeline could access them. This violates multiple baseline controls:
PCI DSS v4.0.1 Requirement 8.3.2 requires that passwords and passphrases be protected with strong cryptography during transmission and storage. Storing credentials in environment variables, configuration files, or GitHub Actions secrets without additional controls fails this requirement.
NIST 800-53 Rev 5 IA-5(1) mandates that authenticators be encrypted in storage and in transit. CI/CD secrets must use external secret management systems, not embedded values.
Insufficient Workflow Permissions
GitHub Actions workflows that can modify releases or access production credentials need strict permission boundaries. The compromise suggests workflows ran with excessive permissions.
ISO 27001 Annex A.9.2.3 (Management of privileged access rights) requires that privileged access be restricted and controlled. CI/CD workflows should use least-privilege service accounts, not shared credentials with broad access.
SOC 2 Type II CC6.3 (Logical Access Controls) requires that access rights are restricted to authorized users. Your CI/CD service accounts need the same access reviews as human users.
Missing Pipeline Integrity Checks
The attackers modified build workflows without detection. This indicates absent or ineffective pipeline integrity monitoring.
NIST CSF v2.0 DE.CM-7 (Monitoring for unauthorized personnel, connections, devices, and software) applies to your build infrastructure. You need alerting when workflow files change, when new secrets are accessed, or when build artifacts deviate from expected signatures.
PCI DSS v4.0.1 Requirement 6.3.2 requires that security vulnerabilities are identified and addressed. This includes vulnerabilities in your build and deployment processes, not just application code.
Inadequate Supply Chain Verification
Organizations consuming Trivy didn't detect the compromise because they weren't verifying build provenance.
- NIST 800-53 Rev 5 SA-12 (Supply Chain Protection) requires verification of supply chain elements. For open-source tools, this means verifying signatures, checking SLSA provenance, and monitoring for unexpected binary changes.
What the Standards Actually Require
When you map this incident to compliance frameworks, three categories of controls should have prevented or detected it:
Secrets Management: Your CI/CD pipelines must use external secret stores (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) with short-lived credentials. GitHub Actions secrets alone don't meet PCI DSS v4.0.1 Requirement 8.3.2 for production systems.
Workflow Security: Every workflow file needs:
- Explicit permission declarations (read-only by default)
- Required reviews before execution
- Audit logging of all secret access
- Restrictions on which branches can trigger privileged workflows
This satisfies ISO/IEC 27001:2022 Annex A.9.4.1 (Information access restriction) and SOC 2 CC6.1 (Logical and Physical Access Controls).
Supply Chain Validation: Before you execute third-party code in your environment:
- Verify cryptographic signatures
- Check SLSA provenance attestations
- Compare checksums against known-good values
- Monitor for unexpected changes in release artifacts
NIST 800-53 Rev 5 SR-3 (Supply Chain Controls and Processes) and SR-4 (Provenance) detail these requirements.
Lessons and Action Items
For Your CI/CD Pipeline
Audit every GitHub Actions workflow for hardcoded secrets, overly broad permissions, or access to production credentials. Set
permissions: {}at the workflow level and grant only what each job needs.Migrate secrets to external stores. Use OIDC federation so your workflows authenticate to AWS, Azure, or GCP without long-lived credentials. Rotate any secrets that have been in GitHub Actions secrets for more than 90 days.
Enable required reviews for workflow changes. Treat
.github/workflows/as production code—no direct commits, mandatory peer review, separate approval for changes that access secrets.Implement runtime attestation. Use tools like Sigstore to sign your build artifacts and generate SLSA provenance. This creates a verifiable chain from source commit to deployed artifact.
For Your Supply Chain Risk Program
Inventory every security tool that runs in your environment with elevated privileges. Scanners, linters, SAST tools, and dependency checkers all need the same supply chain verification as application dependencies.
Pin versions and verify checksums. Don't use
@latesttags. Pin to specific commit SHAs or version numbers, verify signatures, and test updates in non-production before rollout.Monitor for unexpected changes. Set up alerts when the checksum of a tool you use changes between runs, even if the version number hasn't.
For Compliance Validation
If you're preparing for SOC 2 Type II or PCI DSS assessment, your auditor will now ask about CI/CD security. Document:
- How you restrict access to workflow files and secrets
- Your process for reviewing and approving pipeline changes
- Evidence that production credentials are never stored in repository secrets
- Your supply chain verification procedures for tools that run in production or have access to production data
The Trivy compromise proves that security tools are high-value targets. When your vulnerability scanner becomes the vulnerability, you need controls that treat your build infrastructure as the production system it actually is.
