Topic starter
18/08/2026 2:10 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “Team PCP Stole 78,330 Secrets From 2,186 Organizations. CloudSEK Just Published the List.”.
By the numbers:
- 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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Team PCP’s supply chain campaign exposed CI/CD secrets at scale