Team PCP’s supply chain campaign exposed CI/CD secrets at scale

At a glance

What this is: This is an analysis of Team PCP’s March 2026 supply chain campaign and its CI/CD secret-exfiltration pattern, with the key finding that build pipelines became the attack’s primary credential source.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat CI/CD runners as production-grade identity targets where secrets flow, persist briefly, and can be abused faster than traditional controls detect.

By the numbers:

• GitLab led the exposed platforms with 1,064 affected organizations in the Team PCP campaign.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read StepSecurity's analysis of Team PCP's 78,330-secret CI/CD campaign

Context

CI/CD pipelines are identity-rich execution environments, not just software delivery plumbing. They routinely load secrets into runners, let dependencies execute with broad privileges, and allow outbound connections that can turn one compromised package into hundreds of compromised organisations.

This article examines Team PCP’s supply chain playbook through that lens. The central issue is not only malware in open source components, but the governance gap that lets a build runner ingest, use, and exfiltrate production-grade credentials with too little runtime control.

For NHI and IAM programmes, the lesson is direct: pipeline identities, tokens, keys, and signing material need the same lifecycle governance, observability, and blast-radius controls that teams already expect from privileged production access.

Key questions

Q: What breaks when CI/CD workflows can run untrusted code with privileged tokens?

A: The trust boundary breaks. Once untrusted code runs with repository secrets or a write-capable token, attackers can steal credentials, alter branches, poison packages, or persist through workflow changes. At that point, the pipeline becomes a supply chain entry point rather than a control point.

Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?

A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Q: How do security teams know whether pipeline secret exposure is contained?

A: Containment is real only when exposed credentials have been revoked everywhere they were accepted and no automation still references them. Teams should confirm new tokens are in place, old ones are disabled, and dependent jobs no longer rely on the compromised secret.

Q: Who should be accountable for secrets hidden inside build and release pipelines?

A: Ownership should sit with the teams that operate the workflow and the identity controls that authorize it, not with the security team alone. If a pipeline can reach production systems, package registries, or internal repositories, its credential posture belongs in governance reviews, access recertification, and incident response planning.

Technical breakdown

How CI/CD runners become high-value identity targets

CI/CD runners often execute with secrets already loaded into environment variables, files, or process memory. That means a compromised dependency does not need to break production to be useful. It can read cloud keys, repository tokens, signing material, and webhook credentials inside the pipeline itself. Because runners are frequently ephemeral and lightly monitored, the attacker’s window is short but highly productive. The real architectural issue is that delivery systems are trusted to run code while also acting as secret-bearing identity brokers.

Practical implication: treat every runner as a privileged identity surface and remove secrets from any workflow step that does not strictly need them.

Why mutable dependencies and open egress are the core failure modes

Supply chain campaigns scale when trusted references are mutable and runners can call out freely. A tag, package version, or action can be repointed after approval, and an open outbound channel lets stolen credentials leave the environment immediately. Team PCP’s model depends on both conditions. First the compromised component runs. Then the payload harvests secrets. Then those secrets are exfiltrated over network paths that no one has constrained at the runner layer.

Practical implication: pin dependencies to immutable references and enforce outbound allow-lists for every CI/CD environment.

How secret reinvestment turns one compromise into many

The attacker’s objective is not just theft. It is credential reinvestment. Once a pipeline leaks one token, that token can unlock the next maintainer account, registry, or repository, which in turn exposes more secrets in the next pipeline. This is why supply chain incidents behave like flywheels. The harm compounds across organisations that trust the same ecosystem, especially when tokens are valid for long periods and are not quickly revoked or scoped to a single task.

Practical implication: build revocation and reauthentication into pipeline governance so one leaked secret cannot seed the next compromise.

Threat narrative

Attacker objective: The attacker wants to convert one trusted dependency compromise into reusable credentials that unlock the next set of pipelines, repositories, and cloud accounts.

1. Entry occurs when the attacker compromises a trusted open source component that is referenced by CI/CD pipelines, turning normal dependency execution into a delivery path for malicious code.
2. Escalation happens when the payload runs inside runners that already hold deploy keys, session tokens, and API credentials, allowing the attacker to harvest secrets from memory and environment variables.
3. Impact follows when stolen credentials are exfiltrated and reinvested into new maintainer accounts, repositories, or registries, creating a repeatable supply chain flywheel across organisations.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• 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

CI/CD pipelines have become NHI production systems. They hold deploy keys, repository tokens, signing material, and API credentials that behave like privileged non-human identities, even when security teams still treat them as build infrastructure. The governance mistake is to separate delivery from identity. Once the pipeline is allowed to execute untrusted code with secrets in scope, it becomes part of the credential estate, not an adjacent tool. Practitioners should govern CI/CD as a privileged NHI domain.

Mutable dependencies create a runtime trust problem, not just a software risk. Team PCP succeeded because trusted references could be repointed after approval and then executed inside environments with broad secret access. That is a control-plane failure in identity terms, because authorisation was granted to a label, not to a stable artefact. The practical conclusion is that provenance and immutability are identity controls, not merely supply chain hygiene.

Secret reinvestment is the real blast-radius model in supply chain attacks. Once one pipeline leaks a token, the attacker can pivot into the next maintainer, registry, or repository without needing a fresh intrusion. This is why long-lived credentials and broad-scoped tokens remain structurally dangerous in build systems. The field needs to stop measuring compromise as a single event and start measuring how far one leaked secret can propagate.

Identity blast radius is the right named concept for this campaign. The relevant question is not how many secrets were exposed in isolation, but how many downstream systems those secrets could unlock before rotation and revocation caught up. In CI/CD, blast radius expands through reuse, trust inheritance, and delayed offboarding of compromised credentials. Practitioners should evaluate every pipeline identity by its downstream reach, not by its role name alone.

OWASP NHI Top 10 remains directly relevant here. The campaign maps to overprivileged secrets, weak rotation, and third-party dependency risk, all of which are identity governance failures before they are malware problems. That makes supply chain defence a lifecycle issue across NHI provisioning, rotation, revocation, and monitoring. Teams that only scan code are looking in the wrong place.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, and those incidents are 13% more likely to be categorised as critical than code-based leaks.
• The next step is to connect rotation policy to lifecycle governance with Guide to the Secret Sprawl Challenge and map your exposed credential classes before the next disclosure wave.

What this signals

Identity blast radius is now a pipeline metric. When build systems can load secrets, execute untrusted dependencies, and call out over open network paths, the question is no longer whether a secret leaked. It is how far that secret can travel before revocation, and which 52 NHI Breaches Analysis patterns it resembles. Teams should baseline the downstream reach of every runner credential and tie that reach to an explicit owner.

The operational gap is that most CI/CD programmes still separate delivery monitoring from identity governance. That separation fails when pipelines hold production-grade tokens. Security teams should align build telemetry, secret revocation, and access review workflows so that a compromised workflow is treated like a privileged identity incident, not just a failed job.

Secret reinvestment is the control failure to watch. Once one exposed token can unlock the next repository or registry, a supply chain incident stops being local. Mapping that propagation path against the OWASP Non-Human Identity Top 10 helps teams prioritise immutable references, egress controls, and rapid revocation before the next campaign lands.

For practitioners

• Classify CI/CD runners as privileged NHI assets Assign owners, lifecycle rules, and approval boundaries to every runner that can load secrets or publish artefacts. Map each pipeline to the credentials it can reach, then remove standing access that exceeds the job’s task scope.
• Pin every dependency to an immutable reference Replace mutable tags and floating package versions with commit SHAs or equivalent immutable identifiers, and block builds that resolve compromised or too-fresh releases.
• Restrict outbound network paths from runners Apply egress allow-lists so a workflow can only reach destinations it genuinely needs. That prevents stolen secrets from leaving the runner even when malicious code executes.
• Automate revocation for exposed pipeline secrets Rotate cloud keys, source control tokens, signing keys, and registry credentials as soon as exposure is confirmed, then verify whether the credentials were used after the disclosure window.

Key takeaways

• Team PCP turned CI/CD into a credential harvesting system by abusing trusted dependencies and runner access.
• The exposed secret count and organisation count show that supply chain compromise scales through identity reuse, not just code execution.
• Immutable references, egress control, and rapid revocation are the controls that reduce blast radius when build pipelines are the target.

Key terms

• CI Runner Identity: A CI runner identity is the set of credentials and permissions a build or test runner uses while executing pipeline tasks. In NHI terms, it is a machine identity with real authority, often able to read secrets, access repositories, and publish artefacts if controls are too broad.
• Secret Reinvestment: Secret reinvestment is the attack pattern where one stolen credential is used to gain the next foothold, which then exposes more credentials. It turns a single supply chain compromise into a repeating chain of access across repositories, registries, and cloud environments.
• 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.
• Mutable Dependency Risk: Mutable dependency risk arises when a trusted tag, package version, or action reference can be changed after approval. That makes the security decision unstable because the thing that was reviewed is no longer necessarily the thing that executes.

What's in the full analysis

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

• The ten-layer defence breakdown across prevention, detection, and response for CI/CD runners.
• The platform-by-platform exposure analysis across GitLab, GitHub Actions, Azure DevOps, Jenkins, Bitbucket Pipelines, and CircleCI.
• The workflow-level examples showing how Harden-Runner, Secure Registry, and GitHub Checks stop the attack at different stages.
• The searchable victim-list context and the practical first-response sequence for organisations that appear in the dataset.

👉 StepSecurity's full post covers the attack chain, platform exposure breakdown, and layered controls in detail.

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 building or maturing an IAM programme, it is worth exploring.