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

At a glance

What this is: This is a supply chain analysis of Team PCP’s campaign, which exposed 78,330 secrets from CI/CD pipelines across 2,186 organisations in five days.

Why it matters: It matters because CI/CD runners now sit inside the credential trust boundary, so IAM, PAM, and NHI programmes have to govern build-time access with the same seriousness as production access.

By the numbers:

• The victims included 92 public companies with a combined market capitalization above 6 trillion dollars, according to StepSecurity analysis of CloudSEK data.
• GitLab led the exposed CI/CD platforms with 1,064 affected organizations, according to StepSecurity analysis of CloudSEK data.
• Azure DevOps appeared in more than 230 affected organizations, according to StepSecurity analysis of CloudSEK data.

Context

CI/CD pipelines are the software delivery systems that compile, test, package, and deploy code. In this campaign, they also became credential collectors because secrets were loaded into runners during normal execution and then copied out by compromised dependencies.

The governance gap is not just technical exposure. Build systems often inherit high-value credentials without the controls that production systems usually receive, which leaves NHI governance, secrets management, and supply chain assurance fragmented across teams.

StepSecurity’s article uses CloudSEK’s published victim list to show the scale of the campaign and why organisations that treat pipelines as low-risk development plumbing miss the blast radius entirely.

Key questions

Q: What breaks when compromised CI/CD dependencies can read injected secrets?

A: The control boundary breaks because a trusted build step can become a credential collector. If a malicious dependency runs with access to environment variables, mounted files, or tokenized API calls, the pipeline stops being a delivery mechanism and starts acting as a theft mechanism. The practical failure is scope, not speed: one run can expose multiple downstream systems at once.

Q: Why do CI/CD secrets create more risk than many teams expect?

A: CI/CD secrets often have broad blast radius because they can authenticate to source control, cloud platforms, package registries, and deployment systems. If those secrets are long-lived or reused across repositories, one exposure can open several downstream paths. The risk is highest when secrets are stored in workflow contexts where third-party code can read them.

Q: How do security teams know a pipeline is leaking credentials?

A: Look for first-seen outbound destinations, unusual process activity inside runners, and jobs that touch secret classes they normally should not need. If a workflow begins contacting unfamiliar domains or shows credential-harvesting behaviour during execution, the job should be treated as compromised even if the build completes.

Q: What should organisations do immediately after a CI/CD secret exposure?

A: Prioritise revocation of cloud access keys, source control tokens, private keys, and session credentials that could be reused to pivot elsewhere. Then audit logs for use of those secrets, pin mutable dependencies, and restrict runner egress so the next compromise cannot exfiltrate the same classes of credentials.

Technical breakdown

Why CI/CD runners become credential harvesters

CI/CD runners are ephemeral execution environments, but they are often granted persistent access to secrets at runtime. That makes them ideal for an attacker who can compromise a dependency, because the malicious code runs inside a trusted workflow and can read environment variables, mounted files, and injected tokens before the job ends. The danger is not just execution of untrusted code. It is execution with production-grade access attached. Once a runner can reach package registries, cloud APIs, source control, or signing material, a single compromised action becomes a credential collection point rather than a normal build step.

Practical implication: Treat runner permissions, secret injection, and outbound network paths as part of the access control surface, not just the build toolchain.

Why supply chain compromise scales across platforms

The campaign worked across GitLab, GitHub Actions, Azure DevOps, Jenkins, and other systems because the underlying pattern was the same: trusted dependencies execute with secrets in scope, and most pipelines do not restrict what those dependencies can observe or exfiltrate. The attacker does not need platform-specific exploitation if the workflow itself grants broad access and unrestricted egress. This is why supply chain compromise scales faster than isolated host compromise. The platform changes, but the credential model does not. Mutable references, broad runner permissions, and opaque third-party actions turn each pipeline into a repeatable theft path.

Practical implication: Map every pipeline to the secrets it can see and the outbound destinations it can reach, then reduce both to the minimum required.

How stolen CI/CD secrets become the next compromise

The purpose of the campaign is recursive. Stolen cloud keys, source control tokens, private keys, and session credentials let the attacker move from one compromised build system into the next maintainer account, repository, or registry. That creates a flywheel: one trusted project compromise funds the next intrusion. This is why build-time secrets are not just data exposure. They are operational control plane credentials that can extend the attacker’s reach into production, registry publishing, and downstream open source ecosystems. The immediate harm is theft. The strategic harm is reuse.

Practical implication: Prioritise revocation and downstream access review for every secret class that could be reused to reach another pipeline or registry.

Threat narrative

Attacker objective: The objective was to turn trusted build automation into a repeatable credential supply line that could be reinvested into the next compromise.

1. Entry began when Team PCP compromised a trusted open source project or package that was executed inside CI/CD workflows.
2. Credential harvesting occurred inside the runner because injected secrets were available in memory, environment variables, or files during normal job execution.
3. Exfiltration followed over outbound network connections from the runner to attacker-controlled infrastructure, allowing stolen secrets to leave the build environment.
4. Impact came from reusing those stolen tokens and keys to pivot into additional repositories, maintainers, registries, and organisations.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD has become a credential domain, not just a build domain: The article shows that pipelines now carry deploy keys, registry tokens, signing material, and cloud credentials at the same time they execute third-party code. That changes the governance question from build reliability to credential stewardship. Teams that still segment CI/CD away from IAM and secrets governance are leaving the most valuable credentials in the least inspected environment.

Ephemeral runners do not create ephemeral risk: A short-lived job can still expose durable access if the job loads reusable secrets. The control failure is not runtime duration alone but credential scope, because a few minutes of execution can unlock days or weeks of downstream access. Practitioners should read this as a warning that build-time privilege is functionally production privilege when the same tokens can reach cloud and source control systems.

Secret sprawl in pipelines is the real blast-radius multiplier: The campaign succeeded because many organisations allowed multiple secret classes to flow into runners with little compartmentalisation. Once session tokens, cloud keys, and private keys coexist in the same execution context, compromise of one dependency can expose several trust domains at once. The implication is that pipeline design now needs identity segmentation, not only dependency hygiene.

Runtime controls must sit inside the delivery path: Static scanning and code review do not see what a malicious dependency does after it starts executing. The campaign validates the need for outbound network control, workflow policy enforcement, and behavioral baselining on runners. For practitioners, the lesson is that supply chain defence fails if it stops at artifact admission and never watches live execution.

CI/CD secret exposure is now an identity governance problem with supply chain symptoms: CloudSEK’s disclosure and StepSecurity’s analysis make clear that this is not a narrow DevOps issue. It is a lifecycle and accountability problem for non-human identities that are issued into pipelines, used once, and then forgotten. The field should treat build credentials as governed identities, not disposable implementation detail.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Pipeline identity is now part of the credential perimeter: The article shows that CI/CD jobs can expose the same kinds of secrets that production systems depend on, which means build workflows need identity controls, not just developer tooling oversight. Teams should assume that any pipeline with reusable secrets is already inside the trust boundary and govern it accordingly.

Secret sprawl inside runners is the hidden blast-radius multiplier: When cloud keys, source control tokens, and signing material coexist in a single workflow, compromise of one dependency can cross multiple identity domains in one execution. That is why the next control conversation is not only about rotation, but about reducing which secrets are ever loaded into the runner at all.

CI/CD governance should borrow from NHI lifecycle discipline: If a secret exists only to let a workflow perform a task, its ownership, use, and revocation should be explicitly managed rather than left to platform defaults. The operational signal is simple: any secret that can be reused outside its intended job has already outlived its safe purpose.

For practitioners

• Inventory every secret exposed to CI/CD runners Map cloud keys, source control tokens, signing keys, and session tokens to the workflows that can load them, then mark where each secret is injected and whether it is reusable.
• Reduce runner egress to approved destinations Block outbound connections from CI/CD jobs except to known package, registry, and API endpoints so compromised dependencies cannot send secrets to command and control infrastructure.
• Pin dependencies and actions to immutable references Replace mutable tags with commit SHAs or equivalent immutable references so an attacker cannot silently repoint a trusted action after compromise.
• Rotate and revoke exposed credentials in priority order Start with cloud access keys, source control tokens, private keys, and any session credentials that could be reused to reach other projects or registries.
• Add runtime detection to pipeline execution Baseline normal process and network behaviour per workflow so secret-harvesting activity and first-seen destinations are flagged during the job, not after the fact.

Key takeaways

• Team PCP’s campaign shows that CI/CD pipelines can be used as high-yield credential harvesters when trusted dependencies execute with secrets in scope.
• The exposure was large enough to affect thousands of organisations and include high-value commercial targets, which turns pipeline security into an enterprise risk issue.
• The most effective limiters are secret minimisation, immutable dependency references, runner egress control, and rapid revocation of exposed credentials.

Key terms

• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Supply chain attack path: A supply chain attack path is any route by which a trusted external tool, dependency or partner becomes the mechanism for compromise. It matters because attackers often abuse legitimate integrations instead of exploiting the core system directly, which makes detection and containment harder.
• Immutable Reference: An immutable reference is a fixed pointer to code or workflow content, such as a commit SHA, that cannot be silently repointed like a mutable tag. It reduces the risk that a trusted dependency can be changed after approval and then executed in a pipeline.

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.