Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Supply chain attacks and CI/CD credentials: what teams need to change


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 17031
Topic starter  

TL;DR: Supply chain attacks are now chaining compromised build tools, malicious packages, and stolen CI/CD credentials into faster downstream abuse, according to Boost Security’s analysis of the May 2026 campaign wave. The practical problem is not just package integrity but credential exposure inside developer and pipeline environments, where one compromise can fan out across repositories, signing, and production access.

NHIMG editorial — based on content published by Boost Security: Supply Chain Hunting Season, May edition

By the numbers:

Questions worth separating out

Q: Why do compromised CI/CD credentials make supply chain attacks much worse?

A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments.

Q: Why do developer workstations increase supply-chain risk so quickly?

A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place.

Q: What do security teams get wrong about identity provenance?

A: They often treat provenance as metadata instead of a control boundary.

Practitioner guidance

  • Inventory every credential-bearing software factory identity Map service accounts, GitHub tokens, signing keys, package manager tokens, and cloud credentials across developer endpoints, SCM, CI/CD, and release systems so owners can see where trust is actually concentrated.
  • Reduce runner privilege to single-job scope Issue short-lived credentials only for the specific build or release step that needs them, and block reuse across jobs, repositories, or environments.
  • Separate developer and release identities Keep workstation credentials, package publishing rights, and signing permissions in distinct identity paths so one compromised endpoint cannot immediately publish or sign software.

What's in the full article

Boost Security's full blog covers the operational detail this post intentionally leaves for the source:

  • Timeline details on the May 2026 supply chain attacks and the sequence of affected ecosystems.
  • Specific examples of compromised packages, CI platforms, and developer tooling mentioned in the article.
  • The article's own recommended defensive measures for pipeline hardening and secret exposure reduction.
  • The list of organizations named as early victims and what was compromised in each case.

👉 Read Boost Security's analysis of the May 2026 supply chain attack wave →

Supply chain attacks and CI/CD credentials: what teams need to change?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 16618
 

Supply chain security has become an identity problem disguised as a code problem. The article shows that attackers are not only poisoning packages, they are harvesting the machine identities that make software delivery possible. Once CI tokens, developer SSH keys, and cloud credentials are in play, the attack shifts from artifact integrity to identity governance. Practitioners should treat build identities as governed NHIs with lifecycle, scope, and offboarding requirements.

A few things that frame the scale:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

A question worth separating out:

Q: Who is accountable when a compromised build identity poisons downstream software?

A: Accountability usually sits with both platform owners and application owners because the failure spans identity governance, pipeline hardening, and release approval. The right control lens is to treat build identities as governed NHIs with explicit ownership, revocation paths, and audit coverage. If no owner can rotate or retire them, the risk is already unmanaged.

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



   
ReplyQuote
Share: