Two Arrests, 3,800 Repositories: The TeamPCP Supply Chain Attack

What Happened

Australian Federal Police arrested two individuals linked to TeamPCP, a cybercrime group that compromised at least 3,800 GitHub repositories. The group deployed Shai-Hulud, a self-propagating worm, through malicious code injected into open-source projects. Their most significant breach targeted LiteLLM, an open-source library for managing large language model APIs, harvesting cloud service keys from over 2,500 organizations.

TeamPCP didn't just attack systems. They ran a hacking contest offering $1,000 in virtual currency for whoever executed the largest supply chain operation, turning recruitment into a competitive sport.

Timeline

The full timeline isn't public, but the pattern is clear. TeamPCP operated long enough to compromise thousands of repositories and harvest credentials from thousands of organizations before law enforcement intervention. The LiteLLM attack alone affected major technology companies before detection.

Which Controls Failed

Dependency verification: Organizations pulled compromised packages without validating their integrity. There was no checksum verification, no signature validation, and no review of recent commits before updates.

Secrets management: Over 2,500 organizations had cloud service keys accessible through compromised dependencies. These credentials weren't rotated, weren't scoped with least privilege, and likely weren't monitored for unusual access patterns.

Repository monitoring: GitHub's 3,800 compromised repositories suggest organizations weren't tracking changes to their upstream dependencies. When maintainers unknowingly merged malicious pull requests or when repositories were directly compromised, downstream consumers had no alerting.

Code review for third-party updates: Teams treated dependency updates as routine maintenance rather than potential threat vectors. Pull requests that updated package versions sailed through without scrutiny of what changed in those packages.

Network segmentation: The Shai-Hulud worm propagated across systems, indicating insufficient network isolation. Once the malicious code executed in one environment, it found pathways to other systems.

What Standards Require

NIST 800-53 Rev 5 addresses supply chain risk through multiple controls:

• SR-3 (Supply Chain Controls and Processes): Establish processes to identify and document supply chain elements, assess risks, and implement controls. This includes maintaining a software bill of materials (SBOM) and monitoring for compromises.

• SR-4 (Provenance): Document, monitor, and maintain valid provenance of system components. For open-source dependencies, this means verifying package signatures and tracking the chain of custody from source to deployment.

• SR-11 (Component Authenticity): Implement anti-counterfeit measures including cryptographic verification of software components. Every package you pull from a registry should have its signature validated against known-good keys.

ISO/IEC 27001:2022 requires supply chain security through:

• Control 5.19 (Information Security in Supplier Relationships): Define and agree upon security requirements with suppliers, including open-source maintainers you depend on. Monitor their security practices.

• Control 8.30 (Outsourced Development): Supervise outsourced development, which includes your dependency chain. You don't write the code in your dependencies, but you're responsible for what they do in your environment.

OWASP ASVS v4.0.3 specifies dependency requirements:

• V14.2.1: Verify all components are up to date and that you're using a software composition analysis tool to identify vulnerable components. But "up to date" doesn't mean "blindly update" -- it means current AND verified.

• V14.2.3: Verify that all third-party components come from pre-defined, trusted, and continually maintained repositories. You need an approved list, not just "whatever's on npm."

PCI DSS v4.0.1 addresses this through:

• Requirement 6.3.2: An inventory of bespoke and custom software and third-party software components is maintained. Your SBOM isn't optional documentation -- it's a requirement.

• Requirement 6.4.3: All payment page scripts are managed with integrity and change detection controls. While this targets payment pages specifically, the principle applies: you must detect unauthorized changes to any code running in your environment.

Lessons and Action Items

Build your SBOM today: Use tools like Syft, CycloneDX, or SPDX generators to create a complete inventory of every dependency, including transitive dependencies three layers deep. Update it with every build. You can't protect what you don't know you're running.

Implement package signature verification: Configure your package managers (npm, pip, Maven, etc.) to reject unsigned packages or packages with invalid signatures. For packages without signatures, pin to specific hashes rather than version numbers. When you specify [email protected], you're trusting whatever the registry serves. When you pin to sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==, you're verifying the exact bytes.

Separate your dependency update process: Stop treating dependabot pull requests as auto-merge candidates. Create a review workflow:

1. Generate a diff of what changed in the dependency itself, not just your lock file.
2. Check when the maintainer's account was created and their commit history.
3. Run the new version in an isolated environment with network monitoring.
4. Wait 72 hours after a release before pulling it into production (let others be the canary).

Rotate and scope your credentials: Every cloud service key TeamPCP harvested should have been:

• Rotated every 90 days maximum.
• Scoped to the minimum required permissions.
• Tagged with metadata showing which system and which dependency uses it.
• Monitored for access from unexpected geographic locations or IP ranges.

Monitor your dependencies for compromise indicators: Set up alerts for:

• New maintainers added to packages you depend on.
• Packages transferred to new owners.
• Unusual release patterns (multiple releases in one day, releases at odd hours).
• Dependencies that suddenly add new dependencies of their own.

Network-isolate build and development environments: Shai-Hulud propagated because systems could reach each other. Your build servers shouldn't have network access to your production databases. Your development environments shouldn't be able to SSH to production systems. Segment, then segment again.

The TeamPCP arrests won't stop supply chain attacks. The next group is already running their contest, offering their prize, recruiting their talent. Your defense isn't hoping they get caught -- it's making your systems too hardened to be worth their time.