TL;DR: Team PCP exfiltrated 78,330 secrets from the CI/CD pipelines of 2,186 organizations in five days, according to StepSecurity’s analysis of CloudSEK data, showing how trusted open source dependencies can turn build systems into credential harvesters. CI/CD governance now matters as much as production hardening because runners hold deploy keys, tokens, and signing material that attackers can reinvest immediately.
NHIMG editorial — based on content published by StepSecurity: Team PCP stole 78,330 secrets from 2,186 organisations in a CI/CD supply chain campaign
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.
Questions worth separating out
Q: What breaks when CI/CD workflows can run untrusted code with privileged tokens?
A: The trust boundary breaks.
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.
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.
Practitioner guidance
- 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.
- 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.
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.
👉 Read StepSecurity's analysis of Team PCP's 78,330-secret CI/CD campaign →
Team PCP and CI/CD secret exposure: what security teams missed?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Team PCP’s supply chain campaign exposed CI/CD secrets at scale