Supply Chain Governance Failure: Why Open-Source Compromise Exposes Contractual and Regulatory Gaps

Framing: The Liability Asymmetry in Transitive Dependencies

The TeamPCP threat actor campaign—targeting Trivy, KICS, LiteLLM, and Telnyx—reveals a structural governance failure that extends far beyond technical vulnerability management. When open-source infrastructure is compromised, downstream organizations face exposure without contractual notification obligations, without incident response SLAs, and without clear liability assignment. This is not a detection problem. It is a contractual and regulatory exposure problem. Organizations consuming these tools had no contractual right to demand integrity validation from maintainers, no obligation on maintainers to disclose compromise, and no mechanism to trigger incident response before attackers established persistent access. Under emerging frameworks like NIS2 and DORA, this asymmetry now creates direct regulatory liability for consuming organizations—yet vendor risk governance has not caught up.

The Attack Pattern: Credential Harvesting to Lateral Movement in Hours

According to Wiz Research's incident response analysis, the TeamPCP campaign followed a consistent post-compromise playbook: malware injection into binary releases and package repositories, immediate credential harvesting (AWS keys, SSH credentials, Kubernetes configs, CI/CD secrets), and rapid validation using open-source tools like TruffleHog. Within hours of initial compromise—in some cases within 24 hours—attackers began systematic AWS enumeration: IAM role discovery, EC2 instance mapping, ECS cluster identification, and Secrets Manager access. The speed and precision of this progression suggests either automated tooling or a well-resourced threat actor with deep cloud infrastructure knowledge. The governance implication is stark: organizations had no contractual basis to demand that open-source maintainers conduct post-release integrity validation, publish attestations of build provenance, or notify downstream consumers of infrastructure compromise. Maintainers had no obligation to provide such measures. Risk was transferred silently.

Post-Compromise Containment: The Hidden Vendor Risk Layer

The most revealing aspect of the TeamPCP campaign is not the initial compromise but what happened after credential theft. Attackers systematically abused stolen Personal Access Tokens (PATs) to execute malicious GitHub workflows, clone repositories at scale, and extract source code and embedded secrets. In AWS environments, they leveraged ECS Exec and SSM Agent to execute commands directly on running containers. They accessed S3 buckets, Secrets Manager, and databases for bulk data exfiltration. This progression indicates that consuming organizations lacked adequate network segmentation, credential isolation, or runtime monitoring to detect or contain lateral movement. Yet vendor risk assessments rarely extend to post-compromise scenarios. Contractual vendor terms typically address secure development practices and vulnerability disclosure but rarely include incident response protocols, forensic cooperation timelines, or customer notification obligations. Open-source maintainers are treated as outside formal governance scope, despite being critical infrastructure. Under NIS2 and DORA, this gap is now a regulatory liability.

The Integrity Verification Gap: Attestation and Provenance

Organizations consuming open-source dependencies do not systematically validate provenance or maintainer infrastructure security. There is no contractual mechanism requiring maintainers to publish build attestations, disclose infrastructure compromises, or validate release integrity before publication. This contrasts sharply with commercial vendors, where contractual terms typically mandate security incident notification within 72 hours, vulnerability disclosure processes, and supply chain integrity controls. The TeamPCP campaign exploited this governance vacuum: compromised binaries and packages were published to official repositories without any mechanism for downstream consumers to verify integrity or detect compromise. Wiz CIRT identified credential validation activity within hours, but organizations consuming these tools had no contractual basis to demand such rapid detection or notification. The absence of supply chain attestation standards—such as SLSA framework adoption or Software Bill of Materials (SBOM) requirements—means organizations cannot systematically verify that dependencies have not been tampered with.

Systemic Weakness: Liability Assignment and Regulatory Exposure

The TeamPCP campaign exposes a critical asymmetry: when open-source infrastructure is compromised, liability for downstream exposure remains undefined. Organizations consuming compromised tools face regulatory exposure under NIS2 (which requires assessment of supply chain risks) and DORA (which mandates third-party risk management and incident notification), yet they have no contractual mechanism to enforce security requirements on open-source maintainers. Maintainers, in turn, face no contractual obligation to conduct security assessments, publish attestations, or notify consumers of compromise. This creates a governance vacuum where risk flows downstream but accountability does not. The Wiz CIRT findings—that stolen credentials were validated and used for reconnaissance within hours—suggest that incident response timelines are measured in hours, not days. Yet most vendor risk frameworks assume 72-hour notification windows. For critical open-source dependencies, this is inadequate. Organizations should revise vendor risk questionnaires to explicitly address open-source supply chain integrity, including maintainer infrastructure security, build attestation practices, and incident notification timelines. Contractual terms should require maintainers of critical tools to publish SLSA attestations, maintain audit logs, and notify downstream consumers of infrastructure compromise within 24 hours.

Cybersol Editorial Perspective: What Organizations Overlook

Most vendor risk assessments treat open-source dependencies as outside formal governance scope, categorizing them as "community-maintained" and therefore exempt from contractual security requirements. This is a critical oversight. The TeamPCP campaign demonstrates that open-source infrastructure can be compromised with the same sophistication and impact as commercial vendors. The difference is that commercial vendors have contractual obligations to disclose compromise; open-source maintainers do not. Organizations consuming critical open-source tools—particularly those used in CI/CD pipelines, cloud infrastructure scanning, or security tooling—should treat maintainers as vendors subject to the same risk assessment and contractual governance as commercial suppliers. This includes: (1) assessment of maintainer infrastructure security and access controls; (2) requirement for build attestations and SBOM publication; (3) contractual notification obligations for security incidents; (4) incident response cooperation and forensic support; and (5) post-compromise containment protocols. NIS2 and DORA will force this alignment, but contractual frameworks must evolve now. Organizations should also implement runtime monitoring and network segmentation to detect post-compromise lateral movement—a layer that vendor risk assessments rarely address but that the TeamPCP campaign demonstrates is critical.

Original Source

Wiz Research. "Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild." Wiz Blog. https://www.wiz.io/blog/tracking-teampcp-investigating-post-compromise-attacks-seen-in-the-wild

The original research includes detailed indicators of compromise (IoCs), network forensics, and detection signatures. Organizations should review the full analysis to understand attack progression, credential validation techniques, and post-compromise enumeration patterns. This should inform immediate vendor risk assessments of open-source dependencies, with particular focus on tools maintained by individuals or small teams with limited security infrastructure. Revise vendor risk questionnaires to explicitly address supply chain integrity, incident notification timelines, and post-compromise containment—requirements now mandatory under NIS2 and DORA frameworks.