TL;DR: Open source supply chain attacks reached 56 distinct incidents in 12 months, with the pace accelerating to roughly one incident every three days and several worm-like campaigns spreading through trusted packages, GitHub Actions, and CI/CD runners, according to StepSecurity. The pattern shows that build systems now need stronger identity, secrets, and egress controls because compromise often happens before production ever sees the code.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “The State of Open Source Supply Chain Attacks”.
By the numbers:
- StepSecurity tracked 56 distinct supply chain attacks in 12 months.
Key questions
Q: What breaks when malicious packages reach build pipelines unchecked?
A: Unchecked packages can execute before conventional controls inspect them, which means secrets, environment variables, and internal tokens can be exposed during install or runtime.
Q: Why do trusted packages and actions create such a large supply chain risk?
A: Because attackers do not need to invent trust, they hijack existing trust.
Q: How should security teams govern credentials used by CI/CD pipelines?
A: Security teams should treat CI/CD credentials as production-grade machine identities and apply least privilege, short lifetimes, and continuous monitoring.
Practitioner guidance
- Lock down build-time token scope Issue the minimum permissions needed for runners, actions, and publishing accounts, and separate read, write, and release paths so stolen credentials cannot pivot across environments.
- Make GitHub Action tags and package versions immutable Pin dependencies and workflows to commit SHAs or trusted release artefacts, and reject mutable references that let a maintainer compromise retarget existing workflows.
- Block outbound exfiltration from CI/CD runners Apply egress controls so malicious code cannot ship secrets to attacker-controlled endpoints after it executes inside the pipeline.
Bottom line: Open source supply chain attacks now routinely exploit the identities trusted by build systems, not just the software those systems produce.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Build-time identity has become the real control plane: supply chain attackers increasingly target the identities trusted by pipelines, not the applications those pipelines eventually produce. When package maintainers, GitHub Actions tags, or runner tokens are the access path, the decisive question is who can execute inside automation and what secrets are already present there. Practitioners should treat CI/CD identity as production-grade privilege, not development convenience.
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: Should organisations treat package maintainers as privileged identities?
A: Yes. Maintainers can change what thousands of downstream systems execute, which is functionally privileged access. They should be governed with the same seriousness as other high-impact roles, including stronger authentication, tighter recovery controls, separation of duties, and rapid revocation when compromise is suspected.
👉 Read our full editorial: Open source supply chain attacks are now a daily build risk