Incident Overview
A threat actor compromised CI/CD pipelines by deploying malicious code through an open source security tool. This attack used an infostealer to exfiltrate cloud credentials, SSH keys, tokens, and other secrets from automated build and deployment workflows. The tool involved was Trivy, a widely-used vulnerability scanner integrated into pipelines to detect security issues in containers and dependencies.
The attacker did not exploit a vulnerability in Trivy itself. Instead, they exploited the trust organizations place in open source security tools to introduce malicious functionality into CI/CD environments where secrets are readily available.
Attack Timeline
While specific dates or duration for this incident are not provided, the attack targeted the CI/CD workflow phase where Trivy typically runs—during build, scan, or deployment stages when credentials are often exposed as environment variables or mounted secrets.
Failed or Missing Controls
Inadequate Tool Vetting and Provenance Verification
Organizations likely installed Trivy without verifying the integrity of the package or its source. CI/CD pipelines often pull tools from package registries, container repositories, or GitHub releases. If you're running docker pull or pip install without checksum verification, you're assuming the name matches the legitimate tool.
Overprivileged Pipeline Execution Contexts
The infostealer successfully exfiltrated cloud credentials and SSH keys, indicating that the CI/CD runner had access to these secrets. Many teams grant broad permissions to pipeline jobs because it's operationally simpler than implementing least-privilege access patterns.
Missing Egress Controls
For an infostealer to succeed, it must transmit data out of your environment. The fact that exfiltration succeeded indicates missing or ineffective network egress filtering on CI/CD runners. Your build agents shouldn't be making arbitrary HTTPS requests to external domains.
Absent Runtime Monitoring
Security tools running in your pipeline should behave predictably. A scanner that suddenly starts making network connections to unfamiliar endpoints or reading files outside its expected scope should trigger alerts. The absence of such detection suggests no runtime monitoring on CI/CD infrastructure.
Relevant Standards
PCI DSS v4.0.1 Requirement 6.3.2 mandates secure development of custom software, extending to third-party and open source components. You must maintain an inventory of all software, including tools in your CI/CD pipeline. If processing cardholder data, every component in your build chain is in scope.
NIST 800-53 Rev 5 control SA-12 (Supply Chain Protection) requires supply chain protection measures. SA-12(2) calls for supplier reviews and SA-12(5) requires limitation of harm from suppliers. Installing Trivy—or any tool—without verification fails to protect against supply chain compromise.
ISO 27001 control 8.30 (Outsourcing) addresses the security of services and products from suppliers. Your CI/CD tools are obtained services. The standard requires you to identify, assess, and manage information security risks associated with supplier relationships, including open source projects.
SOC 2 Type II CC6.6 (Logical and Physical Access Controls) requires logical access controls over assets to protect against threats. Your secrets are assets. Allowing an unverified tool to run with access to all pipeline secrets violates this control.
Action Items for Your Team
Implement Cryptographic Verification for All Pipeline Dependencies
Verify every tool you install. For container images, use Docker Content Trust or Sigstore cosign signatures. For language packages, verify SHA256 checksums against known-good values. For GitHub releases, validate GPG signatures when available.
Create a pipeline dependency manifest. List every scanner, linter, build tool, and deployment utility your CI/CD uses. Document the expected source repository, package registry, and verification method for each.
Apply Least Privilege to Pipeline Execution
Your CI/CD runners don't need access to every secret in your organization. Use pipeline-specific service accounts with narrowly scoped permissions. If a build job needs to push to ECR, give it only ecr:PutImage for that specific repository—not AdministratorAccess.
For secrets injection, use short-lived credentials. Tools like HashiCorp Vault, AWS IAM Roles for Service Accounts, or GitHub's OIDC token exchange let you issue time-limited credentials that expire after the job completes.
Deploy Egress Filtering on CI/CD Infrastructure
Your build agents should only communicate with known, necessary endpoints. Create an allowlist of domains your pipeline legitimately contacts: your artifact registry, your cloud provider APIs, your deployment targets. Block everything else.
Use a transparent proxy or network firewall to enforce these rules. Log all egress attempts. An unexpected connection from your scanner to an unfamiliar domain is a detection opportunity you're currently missing.
Monitor Tool Behavior at Runtime
Install eBPF-based monitoring or a runtime security agent on your CI/CD runners. Track which processes access which files and make which network connections. Establish baselines for normal behavior.
When Trivy runs, it should read your container images and write a scan report. It should not read .ssh/id_rsa or make HTTPS POST requests to domains unrelated to vulnerability databases. Deviations from expected behavior should generate alerts.
Establish a Tool Approval Process
Before any open source tool enters your pipeline, answer: Who maintains this? How is it distributed? Has it been audited? What permissions does it require? What network access does it need?
Document these answers. Update them when you upgrade versions. Treat CI/CD tooling with the same scrutiny you apply to production application dependencies.
Rotate All Secrets Accessible to Compromised Pipelines
If you suspect or confirm that a malicious tool ran in your CI/CD environment, assume all secrets accessible to that pipeline have been compromised. Rotate cloud credentials, SSH keys, API tokens, and any other secrets the runner could read. This is not optional—it's the only way to close the exposure window.
The Trivy incident demonstrates that your security tools can become your attack surface. The scanner you installed to find vulnerabilities became the vulnerability. That's the supply chain risk you need to design against.
