TeamPCP shows how supply chain attacks pivot through CI credentials

At a glance

What this is: This analysis shows how the TeamPCP supply chain campaign moved from CI misconfigurations into stolen tokens, poisoned releases, and trusted publishing channels.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat build pipelines and package publishers as high-value identity surfaces, not just software delivery mechanics.

👉 Read Semgrep's analysis of the TeamPCP supply chain campaign

Context

Supply chain security fails when trusted build and publishing paths become identity compromise paths. In this case, the primary issue is not software quality alone, but the misuse of GitHub Actions, package registries, and CI credentials as access conduits for attackers.

For identity teams, the interesting problem is how non-human identities inside CI, package publishing, and developer tooling can be chained together once one credential is exposed. That makes this a workload identity and secrets governance issue as much as a secure development issue.

The TeamPCP campaign is a strong example of how mutable references, broad token scope, and trusted automation can turn routine pipeline activity into an attacker-controlled distribution channel. The starting position is unfortunately typical in modern software environments.

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 CI and publishing systems create such a large identity risk?

A: Because they combine automation, secrets access, and downstream distribution rights in one place. A single compromised workflow can harvest tokens, publish malicious packages, and impersonate trusted releases across ecosystems. That makes CI a non-human identity problem with direct impact on secrets management and least privilege.

Q: What breaks when GitHub Actions are referenced by tag instead of SHA?

A: The trust target becomes mutable. If an attacker can move the tag or compromise the referenced repository, the consuming workflow runs code that was never actually approved. That defeats review-based controls because the identity of the action can change after the decision to trust it.

Q: Who is accountable when a workflow compromise leads to malicious package releases?

A: Accountability is shared, but it cannot be vague. Repository owners, platform engineering, security, and package maintainers all have control over workflow design, secret scoping, and publishing identity governance. In regulated environments, incident response and control ownership should be documented before the next compromise happens.

Technical breakdown

Mutable GitHub Actions references create a trust gap

When workflows reference actions by tag instead of immutable commit SHA, the build inherits whatever code the tag points to at execution time. That makes the workflow subject to tag force-pushes, repository compromise, and downstream package poisoning without any local change in the consuming repository. In supply chain terms, the identity of the action is no longer stable. The trust decision is deferred to an external repository state that can be rewritten after approval. This is why pinned references matter: they convert a moving target into a verifiable artifact.

Practical implication: pin critical workflows to commit SHAs and treat mutable tags as an unacceptable identity boundary.

OIDC exchange and publish tokens expand the blast radius

The Bitwarden CLI incident shows how modern publishing pipelines can combine ephemeral OIDC exchange with broad package publishing rights. OIDC is useful because it reduces static secret storage, but it does not remove the need to validate what the build is publishing or which job can request the token. Once an attacker controls the workflow, the token becomes a legitimate bridge into the package registry. That is a workload identity problem, not just a secrets problem, because the pipeline itself becomes the credential broker.

Practical implication: scope publish jobs tightly, isolate them from untrusted build steps, and review every OIDC-backed release path.

Credential harvesting turns one compromise into many

The campaign repeatedly used one compromised CI or package surface to collect the next set of tokens, keys, and environment secrets. That is the core mechanics of supply chain escalation: access to one trusted context yields the credentials needed to impersonate another. The attacker does not need to break every system directly. They only need enough visibility into build logs, package metadata, or developer environments to keep moving. This pattern is especially dangerous where CI systems touch secret managers, source control, and package registries in the same job.

Practical implication: assume any CI job with broad read access can become a credential collection point unless secrets are segmented by task.

Threat narrative

Attacker objective: The objective was to convert trusted CI and publishing infrastructure into a credential harvesting and software delivery pipeline that could compromise additional environments.

1. Entry began with a pull_request_target misconfiguration in a public repository workflow, giving the attacker a foothold through a trusted CI path.
2. Escalation followed as stolen tokens from one compromise were reused to publish malicious packages, overwrite tags, and seed further credential harvesting across npm, Docker, and developer extensions.
3. Impact was achieved by turning trusted software distribution into an exfiltration and propagation channel, exposing tokens, SSH keys, cloud credentials, and downstream build trust.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Mutable build references are a governance failure, not a convenience feature. The TeamPCP campaign succeeded because many pipelines still treat tags as stable identity, even though tags can be moved after review. That is a broken assumption in NHI governance, because the consuming system is not binding trust to an immutable artifact. Practitioners should see mutable references as identity drift in the supply chain.

CI pipelines now behave like privileged non-human identities. Once a workflow can publish packages, mint tokens, read secrets, and trigger downstream automation, it functions like an NHI with high-value standing privilege. That means the governance model has to move from “is the repo trusted” to “what can this pipeline identity do, and for how long.” The implication is tighter entitlement scope and explicit lifecycle control for release jobs.

Credential reuse across ecosystems is the real attacker advantage. The campaign moved from GitHub Actions to npm, Docker, PyPI, and developer extensions because each trust boundary exposed a new credential set. This is the identity blast radius problem in practice: one compromised non-human identity becomes a broker for many others. Security teams need to model where one token can reach, not only where it originated.

Secrets-bearing developer tooling belongs in the same control plane as production NHI. Bitwarden CLI mattered because it sat near publishing workflows and could expose GitHub, npm, SSH, and cloud credentials in one compromise path. That is not a niche developer concern. It shows that developer-side non-human identities can carry the same operational risk as production service accounts when they touch release infrastructure.

Immutable publishing and lifecycle offboarding should be treated as the same control family. A poisoned tag, a stale publish token, and an uncleared workflow permission are all forms of access that outlive the trust decision that created them. The practical conclusion is that identity lifecycle governance must include build identities, not just human access reviews and classic service accounts.

What this signals

The practical signal for IAM and AppSec teams is that release automation is now part of the privileged identity estate, not just the software delivery estate. A pipeline that can mint tokens or publish packages needs the same entitlement scrutiny you would apply to a sensitive service account.

Identity blast radius: one compromised workflow can expose several ecosystems at once when source control, package registries, and secret-bearing developer tools share trust paths. Teams should map those paths explicitly and reduce the number of places where one credential can reach.

For programmes mature enough to act, the next step is to align CI governance with NHI lifecycle management. That means reviewing publish jobs, rotating exposed tokens quickly, and treating third-party workflow dependencies as identities with revocation and offboarding requirements.

For practitioners

• Pin release workflows to immutable commit SHAs Replace mutable action tags in release and deployment pipelines with commit SHA references, especially where the workflow can publish packages or access secrets. Review all external actions used in high-trust jobs and block tag-based references where downstream credential exposure is possible.
• Separate build steps from publish authority Split untrusted build or test stages from the job that requests publish tokens or registry credentials. Keep the OIDC exchange and package publication in a narrow, isolated release path with minimal permissions and explicit approval boundaries.
• Treat CI jobs as credential collection points Inventory which workflows can read environment variables, access secret managers, or echo tokens into logs. Reduce secret scope per job and assume that any pipeline with broad access can become a credential harvesting point if one dependency is compromised.
• Add cooldowns before consuming new packages Delay automatic adoption of newly published packages and actions so malicious versions can be identified before they enter production builds. Use this especially for namespaces that publish under your trust boundary or that your CI references by name.

Key takeaways

• TeamPCP shows that supply chain compromise often starts with identity and workflow trust, not with a single vulnerable application.
• The campaign demonstrates how one CI foothold can cascade into token theft, malicious publishing, and cross-ecosystem propagation.
• The strongest controls are immutable references, narrow publish authority, and lifecycle governance for build identities.

Key terms

• Mutable reference: A mutable reference is a tag, branch, or alias that can point to different code over time. In GitHub Actions, mutable references increase supply chain risk because the code you trusted yesterday may no longer be the code you execute today.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.

What's in the full article

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact package and workflow windows for Trivy, Checkmarx, LiteLLM, and Bitwarden CLI exposure
• Semgrep detection rule examples for insecure pull_request_target workflow patterns
• Step-by-step guidance for pinning GitHub Actions to SHAs and setting package cooldowns
• File-level and hash-level indicators that security teams can use to triage affected environments

👉 Semgrep's full post covers the attack chain, affected packages, and recommended CI hardening steps

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.