Notifications
Clear all
Topic starter
19/08/2026 4:01 pm
TL;DR: More than 10,000 open-source repositories and more than 13 million builds weekly were secured in 2025, while major supply chain compromises were detected early and controls for GitHub Actions and npm were expanded, according to StepSecurity. The pattern is clear: real-time enforcement, not post-incident alerting, is becoming the baseline for supply chain resilience.
NHIMG editorial — based on content published by StepSecurity: Product 2025 in Review, the evolution of supply chain security and what is next
By the numbers:
- StepSecurity says it now secures over 13 million builds every week, showing how much of the software delivery pipeline is in scope for enforcement.
- StepSecurity reports that Harden Runner community adoption doubled from 5,000 to 10,000 public repositories in a single year.
Questions worth separating out
Q: How should security teams block compromised actions and packages before they run?
A: Use pre-execution policy to validate source, provenance, and behaviour before a workflow or package is allowed to execute.
Q: Why do maintainer account compromises create such a large supply chain blast radius?
A: Because the maintainer identity often has publish authority, release automation access, and trust by downstream consumers.
Q: What breaks when developer machines are not governed as part of supply chain security?
A: When developer machines are left outside the control model, attackers can use trusted local installs to steal credentials before the pipeline ever sees malicious code.
Practitioner guidance
- Block untrusted workflow execution paths Apply pre-execution policy to third-party GitHub Actions, reusable workflows, and other external build components so compromised references cannot run before review.
- Add cool-down checks to package releases Prevent immediate use of newly published package versions when maintainer compromise is plausible, especially in npm and other fast-moving ecosystems.
- Extend supply chain controls to developer endpoints Treat developer workstations as privileged build assets.
What's in the full article
StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:
- A blow-by-blow account of the tj-actions detection path, including the anomalous network call that triggered the investigation.
- Implementation detail on GitHub Actions security, including workflow run policies and StepSecurity-maintained replacement actions.
- The npm cool down check and npm search mechanics that reduce the window between package compromise and detection.
- Product roadmap detail for securing developer machines, including Windows and macOS coverage plans.
👉 Read StepSecurity's review of 2025 supply chain security evolution and 2026 priorities →
Software supply chain enforcement is replacing alert-only controls?
Explore further
19/08/2026 4:37 pm
Real-time enforcement has become the defining control shift in software supply chain security. Alerting after compromise is now structurally too late when malicious packages can be published within minutes and workflow abuse can begin immediately. The article shows that organisations need controls that evaluate trust before execution, not only after detection. For practitioners, this means supply chain security must be treated as a pre-execution governance problem.
A question worth separating out:
Q: Who is accountable when compliance failures happen across CI/CD workflows?
A: Accountability sits with the owners of the workflow, not the individual tool. Teams need clear responsibility for testing, approvals, remediation, exceptions, and record retention across DevSecOps handoffs. Without workflow ownership, evidence gaps appear exactly where audits are most likely to probe.
👉 Read our full editorial: Software supply chain security matured from alerts to enforcement
