Software supply chain security matured from alerts to enforcement

At a glance

What this is: StepSecurity's year-in-review argues that software supply chain security has moved from passive detection to real-time enforcement across CI/CD and package ecosystems.

Why it matters: This matters because identity, trust, and execution controls now have to be applied before workflows run or packages are consumed, especially where CI/CD runners and maintainer accounts can be abused.

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.

Context

Software supply chain security is the set of controls that govern how code, packages, build systems, and developer tooling are trusted before they are allowed to run or ship. In this article, the primary governance gap is not visibility alone but the delay between compromise and enforcement, especially in CI/CD pipelines and package ecosystems.

StepSecurity frames 2025 as the year that alert-only controls stopped being enough because attackers were operating inside trusted build paths and package release flows. The identity angle is real here: maintainer tokens, workflow permissions, and CI/CD runner trust are all non-human access paths that need lifecycle governance, not just detection.

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. Enforcement shifts the decision to the point of use, so unsafe actions, recent packages, and non-compliant builds can be blocked before they run.

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. Their tokens and service accounts are non-human identities, so poor scoping, weak rotation, or missing offboarding can let an attacker move from a build system into production systems with legitimate credentials.

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. If compromised actions can still execute or fresh packages can still be used immediately, the control is not working as intended.

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.

Technical breakdown

Why alert-only supply chain controls fail in CI/CD

Alerting tells teams that a workflow, package, or maintainer credential has already been abused. In modern CI/CD environments, that is often too late because the runner has already executed, secrets may already have been exposed, and the malicious step can complete in seconds. Enforcement changes the control point from post-event review to pre-execution policy. That matters when third-party actions, package installs, and build jobs all inherit trust before they are evaluated. The security question is not whether compromise can be detected eventually, but whether the pipeline can be prevented from running unsafe components at all.

Practical implication: Apply pre-execution controls to stop risky workflows before they consume secrets or reach build execution.

How CI/CD runner identity becomes a supply chain attack path

CI/CD runners are not just infrastructure; they are execution identities with access to source code, secrets, and deployment permissions. When attackers compromise a workflow, a runner, or a maintainer token, they are often abusing a non-human identity with more reach than a normal user session. That is why the trust boundary must include credential scope, runner provenance, and workflow policy. If runners can access secrets by default or execute unverified third-party actions, the build system becomes a privilege bridge rather than a control plane. The identity problem is therefore inseparable from supply chain security.

Practical implication: Treat runners, workflow tokens, and build credentials as governed identities with explicit scope and revocation paths.

Why package ecosystems need time-based and reputation-based controls

The article shows why package compromise is difficult to catch with static allowlists alone. Attackers can publish malicious versions quickly after account takeover, which means risk is concentrated in the release window immediately after a maintainer compromise. Controls such as cool-down checks, package search, and threat intelligence work because they narrow the trust window and make recent releases suspect until they are validated. This is a governance problem as much as a malware problem: if dependency trust is assumed at publish time, the organisation is relying on the attacker not to move faster than the review process.

Practical implication: Use release-age checks and package intelligence to delay trust in freshly published dependencies.

Threat narrative

Attacker objective: The attacker objective is to turn trusted build and dependency paths into a mechanism for stealing secrets, hijacking workflows, and propagating compromise across downstream environments.

1. Entry occurred through compromised maintainer credentials, poisoned workflows, or malicious package publishing in trusted ecosystems.
2. Credentialed access was then used to alter build steps, exfiltrate secrets, or trigger malicious execution inside CI/CD runners.
3. Impact followed as thousands of repositories and downstream workflows inherited the compromised trust path.
4. In the Nx case, malicious package execution also extended the attack surface onto developer machines and local tooling.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

CI/CD runners are effectively non-human identities and must be governed that way: they authenticate, inherit privilege, and access sensitive assets without human supervision. That makes runner identity, workflow tokens, and third-party actions part of the identity governance surface, not just the DevOps toolchain. Practitioners should treat execution trust as lifecycle-managed access.

Supply chain risk is moving from single-compromise events to repeatable trust-pattern failures: the same weak assumptions keep appearing around maintainer access, package freshness, and workflow inheritance. This is not just an alerting gap but a governance debt problem, where the organisation has not defined where trust starts, how long it lasts, or what breaks it. The practical conclusion is to govern trust windows explicitly.

Trusted developer tooling is now part of the attack surface: the article's mention of local tooling abuse shows that supply chain defence no longer stops at the repository boundary. Build systems, endpoints, and package registries form one continuous trust graph, which means identity and execution controls must follow the developer wherever code can be built or installed. For practitioners, segmentation of trust domains matters more than tool count.

Trust-window enforcement: recent package publication, workflow changes, and runner execution all need short-lived trust assumptions before they are allowed into production pipelines. That concept is central to 2026 supply chain governance because the compromise window is now shorter than many review processes. The practitioner takeaway is to reduce implicit trust duration wherever software enters the build path.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Trust-window enforcement will become the default language for supply chain governance: teams can no longer assume that a package, action, or runner is safe simply because it is trusted upstream. The operational shift is to shorten the interval between publication, evaluation, and execution so compromised components have less room to move.

CI/CD identity is now a governance domain, not just an engineering concern: once build runners, workflow tokens, and maintainer accounts are treated as identities, lifecycle controls become unavoidable. This is where NHI governance and supply chain security meet most clearly, because the trust decision sits at the moment of execution.

Pipeline controls need to follow the same model as zero standing privilege: anything that can execute with secrets should do so only under explicit, short-lived policy. That reduces the blast radius of compromised actions and makes the build path harder to abuse at scale.

For practitioners

• 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.
• Treat maintainer-token compromise as a pipeline event Assume a compromised maintainer account can poison packages and workflow steps, then revoke downstream trust paths rather than reviewing only the affected artefact.
• Expand controls beyond Linux runners Plan for Windows and macOS build coverage so policy enforcement is consistent across heterogeneous developer and CI/CD environments.

Key takeaways

• Software supply chain attacks now hinge on whether organisations can stop unsafe code, actions, and packages before they execute.
• StepSecurity's article shows that pipeline enforcement, not after-the-fact detection, is becoming the practical baseline for build security.
• CI/CD runners and maintainer credentials should be governed as identities with scope, revocation, and trust-window controls.

Key terms

• Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Trust window: The period during which an identity, request, or credential remains believable enough to trigger action and cause impact. Shortening that window is a containment strategy because it limits how long a deceptive actor can reuse access, chain prompts, or move from one step of the attack to the next.
• Pipeline Enforcement: Pipeline enforcement is the mechanism by which security and governance rules are applied automatically during build and release. For CI/CD, it matters because controls only create trust when they run by default across every workflow, not when teams remember to apply them.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and IAM practitioners connect identity controls to the broader systems that rely on them.