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.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “2025 in Review: The Evolution of Supply Chain Security & What's Next”.
By the numbers:
- StepSecurity says it secures over 13 million builds every week.
- StepSecurity says Harden Runner community adoption grew from 5K to 10K public repositories.
Key questions
Q: What breaks when supply chain security relies on alerts instead of enforcement?
A: Alerts arrive after the workflow or package has already been trusted, which is too late to protect secrets, prevent execution, or stop downstream propagation.
Q: Why do CI/CD systems increase identity risk in software delivery?
A: CI/CD systems increase identity risk because they often hold broad access to code, infrastructure, and deployment targets.
Q: How do teams know if supply chain enforcement is actually working?
A: Effective enforcement shows up as blocked unsafe workflows, fewer unreviewed package updates reaching production, and shorter time between a threat being published and a control reacting.
Practitioner guidance
- Implement pre-execution workflow blocking Block non-compliant GitHub Actions workflows before they run, especially when they reference unapproved or compromised third-party actions.
- Govern CI/CD runners as identities Inventory runner types, token scope, and secret access so build infrastructure cannot inherit broad privileges by default.
- Add release-age checks for dependencies Delay trust in newly published package versions during the highest-risk post-compromise window, then allow only validated dependencies into builds.
Bottom line: Software supply chain attacks now hinge on whether organisations can stop unsafe code, actions, and packages before they execute.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:37 pm
Enforcement has become the decisive control plane for software supply chain security: visibility alone no longer protects build pipelines once compromised components are allowed to execute. The article reflects a broader market shift from incident detection to policy enforcement at the point of use. For practitioners, the question is now whether unsafe workflows can be blocked before they touch secrets or deploy artefacts.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: How should organisations respond when a package they trust is suddenly compromised?
A: Block the affected package immediately, identify every environment that installed it, and verify whether any secrets, tokens, or browser sessions were exposed. Then review publishing identities, CI permissions, and any downstream systems that could have inherited the compromise.
👉 Read our full editorial: Software supply chain security matured from alerts to enforcement