350 GB Stolen Through a Vulnerability Scanner: The Europa.eu Supply Chain Breach

What Happened

CERT-EU confirmed that 350 GB of data was stolen from Europa.eu, the European Commission's web platform. The stolen data included personal names, email addresses, and internal messages from Commission entities. The breach wasn't a direct attack on Europa.eu's infrastructure—it was a supply chain compromise targeting Aqua Security's Trivy vulnerability scanner.

The attack group TeamPCP compromised Trivy's distribution mechanism, then used the altered scanner to harvest cloud credentials from organizations running it in their CI/CD pipelines. Those credentials gave them access to AWS environments, including the one hosting Europa.eu data. The attack affected at least 1,000 SaaS environments beyond the Commission.

Timeline

The exact timeline remains incomplete, but the sequence is clear:

1. Initial compromise: TeamPCP gains access to Trivy's distribution or build infrastructure.
2. Credential harvesting: Modified Trivy versions exfiltrate AWS credentials from CI/CD environments running security scans.
3. Lateral access: Attackers use harvested credentials to access AWS environments, including Europa.eu infrastructure.
4. Data exfiltration: 350 GB extracted from Commission systems.
5. Public disclosure: CERT-EU identifies the supply chain vector and attributes the breach.
6. Data leak: Stolen data appears online.

Organizations were running Trivy specifically to find vulnerabilities. Ironically, the tool meant to protect them became the attack vector.

Which Controls Failed or Were Missing

No integrity verification for third-party tools: The compromised Trivy versions entered CI/CD pipelines without cryptographic verification. Organizations trusted the tool by reputation rather than validating each version's provenance.

Excessive credential scope: The AWS credentials accessible to Trivy had enough permissions to read 350 GB of production data. CI/CD service accounts should never need read access to production databases or storage containing customer data.

Missing credential rotation: Long-lived credentials in the CI/CD environment gave attackers an extended window. Once harvested, these credentials remained valid long enough to exfiltrate hundreds of gigabytes.

No anomalous access detection: The exfiltration of 350 GB apparently didn't trigger alerts. Either monitoring wasn't configured to detect unusual data transfer volumes, or the thresholds were set too high for production environments.

Insufficient network segmentation: CI/CD pipeline components could reach production data stores. Build environments should operate in isolated network segments with explicit, minimal access to production.

What the Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates that "bespoke and custom software are developed securely" and specifically calls out supply chain risks. While Trivy isn't bespoke software, the requirement's intent covers your build toolchain: you must verify the integrity of all software components in your development and deployment pipeline.

NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires organizations to "employ integrity verification applications for detecting unauthorized changes to software." For tools in your CI/CD pipeline, this means verifying signatures, checksums, and using dependency pinning with hash verification.

ISO 27001 Control 5.19 (Information security in supplier relationships) requires you to "define and agree information security requirements with each supplier." When you pull Trivy—or any scanner—into your pipeline, you're entering a supplier relationship. You need documented security requirements for that relationship, including how you'll verify tool integrity.

NIST 800-53 Rev 5 Control AC-6 (Least Privilege) directly addresses the credential scope problem. Your CI/CD service accounts need the minimum permissions required for their function. A vulnerability scanner never needs read access to production databases.

PCI DSS v4.0.1 Requirement 8.3.2 requires that "authentication credentials are protected during transmission and storage on all system components." Credentials stored in CI/CD environments must be encrypted and rotated. The fact that harvested credentials remained valid long enough for a 350 GB exfiltration suggests rotation policies weren't enforced.

Lessons and Action Items for Your Team

Verify every tool in your pipeline. Create a manifest of every third-party tool that runs in your CI/CD environment. For each one:

• Pin to specific versions using cryptographic hashes, not just semantic versions.
• Verify signatures when available (Trivy itself supports Cosign signature verification—use it for Trivy and everything else).
• Document the business justification for each tool's presence.

Audit CI/CD credentials immediately. List every service account, API key, and IAM role your build pipeline uses. For each credential:

• Document what it can access and why.
• Remove any permissions that aren't actively used.
• Implement 90-day maximum rotation for all CI/CD credentials.
• Use temporary credentials (like AWS STS assume-role) instead of long-lived keys wherever possible.

Segment your build environment. Your CI/CD pipeline should not have network access to production data stores. Create explicit network policies:

• Build environments in isolated VPCs/networks.
• Use one-way deployment mechanisms (build pushes artifacts out, doesn't pull production data in).
• Require explicit approval workflows for any pipeline job that touches production.

Instrument data exfiltration detection. Configure alerts for:

• Data transfer volumes exceeding baseline by 3x in any 24-hour period.
• Access to data stores from CI/CD network ranges.
• Credential usage from unexpected geographic locations.
• API calls to export or backup operations initiated by service accounts.

Test your supply chain incident response. Run a tabletop exercise: "A security researcher reports that one of our pipeline tools is compromised. What do we do?" Your playbook should include:

• How to identify all systems that ran the compromised tool.
• How to rotate all credentials those systems touched.
• How to audit what those credentials accessed.
• How to notify affected parties if data was exposed.

The Europa.eu breach demonstrates that your security tools are part of your attack surface. Every scanner, linter, and test framework in your pipeline is a potential supply chain vector. Treat them with the same security rigor you apply to your production code—because in your CI/CD environment, they effectively are production code.