TeamPCP supply chain attacks expose CI/CD credential risk

At a glance

What this is: This is SafeBreach coverage of the FBI’s TeamPCP FLASH alert, showing how supply chain compromise can turn trusted developer tools into credential-harvesting entry points.

Why it matters: It matters because CI/CD, package registries, and build runners often hold the NHI credentials that give attackers fast lateral reach across cloud and repository environments.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read SafeBreach's coverage of the FBI TeamPCP supply chain alert

Context

TeamPCP’s supply chain activity is a CI/CD identity problem as much as it is a malware problem. The attack path starts when trusted packages, publishing workflows, or build tooling are altered so that the attacker inherits access through the organisation’s own developer trust model. In practice, that means secrets, tokens, and service-account credentials become the real prize.

The governance gap is that many programmes still treat software supply chain trust as a code-integrity issue rather than a credential-lifecycle issue. Once a package or runner can read publishing tokens, cloud credentials, or Kubernetes secrets, the blast radius extends well beyond the initial tool that was compromised.

This is typical of modern supply chain compromise, not an edge case. Attackers increasingly target the software organisations rely on to defend and deploy their environments, which means identity controls for build systems now sit on the same risk path as production workloads.

Key questions

Q: How should security teams reduce the impact of CI/CD supply chain compromise?

A: Treat build systems as privileged identity infrastructure, not just delivery tooling. Pin dependencies to immutable references, separate build from publish rights, and rotate every secret reachable from the affected pipeline. Then add runtime monitoring for runner behaviour and repository creation so compromise is detected as an identity event, not only as a malware alert.

Q: Why do hardcoded credentials in CI/CD pipelines create so much risk?

A: Hardcoded credentials create standing access that outlives the job, the team, and sometimes the project itself. If the secret is copied into code, logs, runners, or config files, revocation becomes slow and uncertain. That makes pipeline compromise easier to turn into broader access, especially when the same secret is reused across multiple environments.

Q: What do security teams get wrong about software supply chain risk?

A: They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software. Signed artifacts, build integrity, and separation of duties matter because attackers frequently abuse the pipeline rather than the package itself. Supply chain governance has to cover provenance, promotion, and update trust.

Q: Who is accountable when a CI/CD secret leak affects production systems?

A: Accountability usually sits with the teams that own the pipeline, the secrets lifecycle, and the downstream systems that trust those credentials. A mature programme maps each credential to an owner, a purpose, and a revocation path so leaks can be traced and contained before they become a production incident.

Technical breakdown

Compromised package trust in CI/CD pipelines

Supply chain compromise works by inserting malicious code into legitimate packages or dependencies that organisations already trust. In this case, trojanised updates to developer and security tools can execute inside build or security workflows without looking anomalous at the dependency level. The key technical issue is that the signed or expected package is no longer the same thing as trusted runtime behaviour. Once the package runs inside CI/CD, it can inherit access to repository credentials, cloud secrets, and publishing tokens that the pipeline itself has been allowed to use.

Practical implication: pin dependencies to verified commit SHAs and inspect runner behaviour, not just package provenance.

Credential harvesting from build and security tooling

Malware in the campaign focuses on harvesting cloud access tokens, SSH keys, Kubernetes ServiceAccount tokens, API keys, and environment variables. These are NHIs, not user identities, and they often sit in places build systems can access by design. The mechanism is simple: once the attacker gains code execution in a pipeline or developer environment, the malware enumerates local auth material and exports it for later use. That turns a single tool compromise into reusable identity material across AWS, GCP, Azure, and Kubernetes.

Practical implication: scope CI/CD secrets tightly and rotate any token reachable from an exposed pipeline or maintainer account.

Self-propagation through registry and repository trust

The most dangerous part of this campaign is propagation. Worm-style components can use stolen publishing tokens to push malicious updates, create repositories, or move across open-source registries, which means the compromise is no longer confined to one machine or one team. This is classic supply chain lateral movement: trust in one package or maintainer account is used to seed additional compromise across many downstream consumers. In identity terms, the attacker is abusing delegated publishing authority and the absence of lifecycle controls around it.

Practical implication: enforce least-privilege publishing rights and monitor for unexpected repository creation or package release activity.

Threat narrative

Attacker objective: The attacker wants durable access to developer and cloud environments by stealing the credentials that control publishing, build, and infrastructure workflows.

1. Entry occurred through compromise of trusted software distribution channels, including injected code in legitimate packages and development dependencies.
2. Escalation followed when trojanized updates installed credential-stealing malware inside developer environments and CI/CD systems, letting the attacker harvest cloud and registry identity material.
3. Impact came from stolen credentials being reused for exfiltration, extortion, and cross-environment propagation through downstream systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD trust is now an identity control surface, not just a software delivery concern. TeamPCP shows that build systems, package registries, and runner infrastructure can hold the credentials that matter most to attackers. Once those environments can read cloud tokens, publishing secrets, or Kubernetes ServiceAccount material, the compromise becomes an identity event with infrastructure consequences. Practitioners should treat pipeline trust as part of NHI governance.

Secret sprawl makes supply chain compromise persist long after the first malicious package is removed. The FBI’s warning that exfiltrated credentials remain useful over time reflects a basic governance truth: detection does not equal revocation. If the stolen material is a token, key, or service account credential, its lifecycle determines the blast radius. The practical conclusion is that exposure windows, not just compromise events, must drive response prioritisation.

Least privilege fails when publishing authority is broader than the workflow that actually needs it. Many CI/CD systems grant registry or repository permissions that exceed the narrow task being performed. TeamPCP weaponises that mismatch by turning publishing access into propagation access. The implication is that identity scope in pipelines must be designed around the smallest reproducible action, not the convenience of broad automation.

Identity blast radius is the right named concept for this campaign. A single compromised maintainer account, package, or runner can fan out into cloud credentials, downstream repositories, and persistent backdoors. That is not a code-quality issue; it is a delegation problem where one trusted identity can legitimately trigger many others. Practitioners should measure how far one pipeline identity can reach before they assume the environment is resilient.

Weaponising the protectors exposes a structural assumption failure in modern DevSecOps. Security and build tools are often treated as if they are safer than the workloads they protect, but TeamPCP turns that assumption inside out. The result is that trust anchors become attack anchors. Security teams should revisit whether their most privileged CI/CD components are governed with the same scrutiny as production-admin identities.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• GitGuardian also found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why exposure management must include revocation, not just detection.
• For the broader supply chain picture, see Guide to the Secret Sprawl Challenge for how hardcoded credentials and CI/CD exposure change remediation priority.

What this signals

The programme lesson is that CI/CD is now part of the identity perimeter, so build and release systems need the same governance discipline as privileged admin paths. With 64% of valid secrets leaked in 2022 still valid and exploitable today, the operational question is no longer whether a leak exists, but whether it has been revoked.

Identity blast radius: this campaign shows how one compromised workflow can reach cloud tokens, repository publishing rights, and downstream systems in a single chain of delegated trust. Teams should map which runners, maintainer accounts, and package credentials can fan out across environments before they assume their current controls are sufficient.

If your programme still treats supply chain risk as a software assurance problem, you are probably under-scoping the response. The better model is identity-led exposure management, supported by runtime monitoring and secret lifecycle control across every build and publish path.

For practitioners

• Pin pipeline dependencies to immutable references Require verified commit SHAs for GitHub Actions and other build dependencies instead of floating tags or branch references. Treat every update path that can reach secrets, publishing tokens, or runners as a privileged supply chain channel.
• Rotate any credential exposed in a build or registry path Immediately rotate cloud credentials, publishing tokens, SSH keys, and Kubernetes secrets that were reachable during the exposure window. If a CI/CD runner, maintainer account, or package workflow could read it, assume it is compromised.
• Restrict publishing authority to the minimum workflow scope Separate build, test, and publish privileges so a compromised runner cannot push packages, create repositories, or move laterally across projects. Use dedicated CI/CD service accounts with narrow token scoping and monitored approval points.
• Monitor for malicious repository and runner artefacts Search for attacker-created repository names, unexpected outbound connections from runners, and stale maintainer recovery channels. Pair repository scanning with runtime behavioural monitoring so you can detect both package tampering and post-compromise propagation.

Key takeaways

• TeamPCP demonstrates that CI/CD compromise is fundamentally an identity and secrets problem, not only a malware problem.
• The evidence is consistent with a large and persistent exposure surface, where stolen credentials can remain useful long after the initial compromise.
• The control that matters most is blast-radius reduction through immutable dependencies, tight publishing rights, and rapid secret revocation.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Publishing Authority: Publishing authority is the right to make content, pricing, or other customer-visible data live. It should be separated from creation and review rights so that no single compromised account can author and publish trusted signals without oversight.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
• Supply Chain Trust Anchor: A package, maintainer account, workflow, or registry permission that downstream systems assume is safe. When the trust anchor is compromised, every dependent system inherits risk, which is why identity governance must cover the trust relationship, not only the code artifact.

What's in the full article

SafeBreach's full article covers the operational detail this post intentionally leaves for the source:

• Specific FBI FLASH indicators of compromise, including attacker-created repository names and malicious infrastructure.
• SafeBreach simulation mappings for the TeamPCP techniques across the affected developer and cloud workflows.
• Step-by-step platform actions for running the TeamPCP scenarios, Attack Playbook filters, and Known Attack Series report.
• The advisory-based mitigation list for pinning workflows, rotating exposed secrets, and hardening publishing access.

👉 SafeBreach's full post covers the TeamPCP TTP mapping, IOCs, and simulation guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.