TL;DR: A single stolen personal access token helped TeamPCP spread across GitHub Actions, npm, Docker Hub, PyPI, and OpenVSX, exposing 54GB of data and showing how static credentials turn one workflow flaw into multi-ecosystem compromise, according to Defakto Security. The lesson is structural: as long as runtime access depends on durable secrets, supply chain hardening only narrows entry points, not the blast radius.
NHIMG editorial — based on content published by Defakto Security: Real-World Lessons Chain Reaction, how one stolen token tore through five ecosystems
Questions worth separating out
Q: What fails when static credentials are used in CI/CD pipelines?
A: Static credentials fail because they remain reusable during execution, so any compromise of a runner, workflow, or dependency can expose secrets that unlock other systems.
Q: Why do static service credentials increase supply chain blast radius?
A: Static service credentials increase blast radius because they create trust that survives beyond the specific action that needed it.
Q: How can teams tell whether secret rotation is actually reducing risk?
A: Teams should look at whether a rotated secret was ever exposed at runtime, whether it still works in downstream systems, and how quickly it can be revoked everywhere it matters.
Practitioner guidance
- Map every static credential path Build a complete inventory of personal access tokens, publish tokens, API keys, and cloud keys across CI/CD, developer machines, staging, and third-party integrations.
- Remove static secrets from privileged build paths Replace environment-variable injection in workflows with runtime-issued identity where the job proves itself at execution time.
- Harden workflow triggers and trust boundaries Review any GitHub Actions or similar automation that runs with elevated privileges on untrusted input.
What's in the full article
Defakto Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step reconstruction of the Trivy workflow misconfiguration and how the token was extracted
- The full ecosystem chain from GitHub Actions to npm, Docker Hub, PyPI, and OpenVSX compromise
- Details on the malicious Trivy releases, package tampering, and the observed payload progression
- Defakto's discovery and replacement model for static credentials across CI, developer machines, and production
👉 Read Defakto Security’s analysis of the TeamPCP static credential chain reaction →
Static credentials and supply chain blast radius: what teams missed?
Explore further
Static credentials are the failure condition, not just the attack surface. TeamPCP worked because every environment touched by the chain had a durable secret waiting to be read at runtime. That is a governance failure, not a tooling failure, because scanners and vaults still leave possession-based trust intact. The implication is that identity teams must stop treating secret storage as the control objective and start treating secret survivability as the risk.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: What should security teams do when a build token is stolen?
A: Security teams should first identify every system that accepted the token, then revoke trust at each downstream integration before the attacker can reuse it. The immediate goal is to stop replay across registries, workflows, and developer environments, not just to rotate one secret. That requires dependency mapping and ownership clarity.
👉 Read our full editorial: Static credentials turned one stolen token into a five-ecosystem breach