Join our Newsletter — 33% off our NHI Course

Are CI/CD credential exposures now the main supply chain risk?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 2 years ago
Posts: 19717
Topic starter  

TL;DR: Supply chain compromise is increasingly centered on stolen CI/CD credentials, not just malicious code, according to Boost Security. When pipeline identities can reach repositories and production systems, blast radius becomes the governing risk.

Editorial analysis by NHI Mgmt Group, based on content published by Boost Security: “Supply Chain Hunting Season - May edition”.

Key questions

Q: Why do stolen pipeline secrets create such a large blast radius?

A: Stolen pipeline secrets create a large blast radius because they often carry permissions that were designed for convenience, not containment.

Q: What are the signs that CI/CD trust is being misused?

A: Look for unexpected workflow changes, unfamiliar package sources, sudden token revocations, unusual publishing activity, and secrets appearing where they should never be visible.

Q: What fails when CI/CD credentials are exposed through the supply chain?

A: The failure is not just secret leakage, but identity reuse at scale.

Practitioner guidance

  • Map CI/CD identities as non-human identities Inventory every token, service account, OIDC trust, and signing credential used by build, test, release, and deployment workflows.
  • Reduce reusable credential exposure in pipelines Replace long-lived CI/CD secrets with short-lived, task-scoped credentials wherever possible, and remove credentials from logs, caches, and build-time environment variables.
  • Tighten what code can execute automatically Restrict package sources, marketplace actions, and developer extensions that can run inside trusted build environments.

Bottom line: Supply chain compromise now centers on stolen CI/CD credentials, not just malicious code, because pipeline identities can reach repositories, registries, and production systems.

Glossary terms: Blast Radius, CI/CD Credential Broker, Software Supply Chain Trust Boundary, Pipeline identity

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →


This topic was modified 2 days ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 6 months ago
Posts: 20207
 

CI/CD credentials are now part of the supply chain attack surface: once build systems authenticate to registries, repos, and cloud services, they become a standing identity layer that attackers can harvest and reuse. The article shows that supply chain compromise is no longer just about shipping bad code, it is about turning trusted pipeline identities into reusable access paths. Practitioners should govern pipeline credentials as high-value non-human identities.

A few things that frame the scale:

  • 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.

A question worth separating out:

Q: How should teams govern supply chain risk in CI/CD environments?

A: Use separate identities for build, sign, and deploy, and make credential scope as narrow as the task allows. Governance should cover what can execute, what can authenticate, and what can be reused after execution. If a workflow can both run untrusted code and reach production, the control boundary is too loose.

👉 Read our full editorial: Supply chain attacks are turning CI/CD credentials into blast radius


This post was modified 2 days ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.