Skip to main content
Two Major Breaches, One Supply Chain FailureIncident
5 min readFor Security Engineers

Two Major Breaches, One Supply Chain Failure

On January 15, 2025, GitHub disclosed that attackers accessed internal repositories and exfiltrated source code. Days later, Grafana Labs confirmed a similar breach. Both incidents traced back to a supply chain compromise in the TanStack npm ecosystem, allowing threat actor TeamPCP to inject malicious code into developer tools.

Here's what happened, which controls failed, and what you need to do differently.

What Happened

TeamPCP compromised 42 npm packages in the TanStack ecosystem, injecting code designed to steal credentials and tokens from developer environments. The malicious code infiltrated Nx Console, a VS Code extension with 2.2 million installs used for monorepo management.

When developers at GitHub and Grafana Labs installed or updated the compromised extension, the malicious code executed in their local environments. It harvested credentials, including CI/CD tokens with repository access. TeamPCP used these tokens to authenticate to internal systems and access private repositories containing source code and configuration data.

Both organizations detected the breach through anomalous authentication patterns—logins from unexpected geographic locations using valid credentials.

Timeline

Early January 2025: TeamPCP compromises TanStack maintainer accounts and injects malicious code into 42 npm packages.

January 10-12: Compromised packages propagate through the npm registry. Nx Console publishes an update that includes the malicious dependency.

January 13-14: Developers at GitHub and Grafana Labs install or auto-update the compromised Nx Console extension. Malicious code executes, harvesting credentials and tokens from local environments.

January 14-15: TeamPCP uses stolen tokens to access internal repositories at both organizations.

January 15: GitHub detects anomalous authentication patterns and begins incident response.

January 16-17: Grafana Labs confirms similar unauthorized access. Both organizations revoke compromised tokens and begin forensic analysis.

January 18: TanStack maintainers identify and remove malicious code from affected packages.

Which Controls Failed or Were Missing

Dependency verification: Neither organization enforced cryptographic verification of npm packages before installation. Teams installed dependencies based on package name and version alone, with no validation of package integrity or publisher identity.

Token scope limitation: The stolen CI/CD tokens had broad repository access rather than being scoped to specific repositories or operations. A single compromised token provided access to multiple internal systems.

Extension vetting: VS Code extensions installed through the marketplace received no security review. The organizations trusted the marketplace's reputation system rather than implementing their own approval process for development tools.

Local environment monitoring: Developer workstations lacked endpoint detection and response (EDR) capable of identifying suspicious outbound connections or credential access patterns. The malicious code executed undetected.

Token rotation: Long-lived tokens remained valid indefinitely. The organizations had no automated rotation policy for CI/CD credentials, allowing stolen tokens to remain useful to attackers for days.

What the Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates that organizations maintain an inventory of bespoke and custom software and third-party software components. This includes identifying security vulnerabilities and applying patches. The requirement extends to development tools—if your IDE extensions access cardholder data environments, they're in scope.

NIST 800-53 Rev 5 SA-12 (Supply Chain Protection) requires organizations to employ integrity verification mechanisms to detect unauthorized changes to software and firmware. For npm packages, this means verifying package signatures and checksums before installation, not just downloading whatever the package manager fetches.

ISO/IEC 27001:2022 Annex A.8.30 (Outsourced Development) requires security requirements for outsourced development activities, including controls over development tools. VS Code extensions that execute in your development environment and access your repositories qualify as outsourced development tools.

SOC 2 Type II CC6.6 requires logical access controls that restrict access to information assets. CI/CD tokens with repository access are information assets. They should follow least-privilege principles and have defined expiration periods.

Lessons and Action Items for Your Team

Implement package signature verification. Configure your package managers to verify cryptographic signatures before installation. For npm, use npm config set verify-signatures true and maintain a list of trusted signing keys. If a package isn't signed or the signature doesn't match, the installation fails.

Scope your CI/CD tokens tightly. Review every service account and CI/CD token. Ask: does this token need access to all repositories, or just three? Does it need write access, or is read-only sufficient? Create separate tokens for separate pipelines. GitHub's fine-grained personal access tokens and GitLab's project access tokens make this straightforward.

Establish an approved tools list. Create a security review process for development tools before they're deployed organization-wide. This includes IDE extensions, CLI tools, and build plugins. Your review should check: who maintains it, how many users it has, when it was last updated, whether it requests network access, and what permissions it needs. Document your decisions in a tools registry that developers can reference.

Deploy EDR on developer workstations. Your developers' laptops are part of your attack surface. Deploy endpoint detection and response that can identify suspicious behavior: unexpected outbound connections to unfamiliar domains, attempts to read credential files, or processes executing from temporary directories. Configure alerts for credential access patterns.

Rotate tokens automatically. Set maximum lifetimes for all CI/CD tokens—30 days for high-privilege tokens, 90 days for read-only tokens. Use your secrets management platform (Vault, AWS Secrets Manager, Azure Key Vault) to rotate tokens automatically before they expire. Update your pipelines to fetch tokens from the secrets manager rather than storing them in configuration files.

Monitor authentication patterns. Implement anomaly detection for authentication events. Alert on: logins from new geographic locations, logins outside normal working hours, rapid authentication from multiple IP addresses, or authentication followed immediately by bulk data access. Your SIEM should correlate these signals.

Audit your current dependencies. Run npm audit and equivalent commands for your package managers. Check the output not just for known vulnerabilities but for packages with small maintainer teams, recent ownership changes, or unusual dependency graphs. If a package suddenly adds dependencies it didn't need before, investigate.

The GitHub and Grafana Labs breaches demonstrate that supply chain attacks target the tools you trust most—the ones you install without a second thought. Your security model must account for the fact that "legitimate" software can become an attack vector overnight. Supply Chain Security

Topics:Incident

You Might Also Like