Runtime monitoring exposed the Sha1-Hulud npm supply chain attack

At a glance

What this is: This is a supply chain attack case study showing how runtime monitoring identified compromised npm packages by detecting anomalous CI/CD behaviour.

Why it matters: It matters to IAM and security teams because CI/CD runners often hold privileged tokens and secrets, turning workflow identities and their permissions into high-value attack paths.

By the numbers:

• The npm ecosystem experienced one of its largest coordinated supply chain attacks, compromising over 780 packages.

👉 Read StepSecurity's analysis of the Sha1-Hulud supply chain attack in Backstage

Context

Supply chain attacks against CI/CD pipelines succeed when trusted build and test workflows execute malicious dependencies before traditional controls can inspect behaviour. In this case, the identity risk sits with the workflow runtime, the runner token, and the permissions granted to automation, not just with the package itself.

For IAM and NHI practitioners, CI/CD runners behave like non-human identities with delegated access to code, registries, and sometimes production systems. That makes runtime monitoring, least privilege, and egress control central governance concerns, especially when packages install from the latest version without a lock file.

Key questions

Q: What breaks when dependency confusion is allowed in CI/CD pipelines?

A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft. The failure is not only malware execution. It is the loss of control over where code comes from and what identity-bearing material the runner exposes during install.

Q: Why do build servers and CI runners increase supply chain risk?

A: Build servers and CI runners often contain reusable secrets, access to artifact repositories, and permissions that ordinary endpoints do not need. That makes them high-value identity targets. When package code runs there, attackers can pivot from software compromise into credential theft, signing abuse, or downstream pipeline manipulation.

Q: How do security teams know if a workflow is behaving outside its intended boundary?

A: They compare observed behaviour against a known baseline for the workflow, including destinations, processes, and registration activity. If a job suddenly contacts unfamiliar domains, downloads new binaries, or creates a runner, that is a governance signal rather than a harmless variation.

Q: What should teams do when a CI/CD workflow attempts persistence through runner registration?

A: Contain the workflow, revoke the affected runner credentials, and review whether the repository can register additional runners or access shared secrets. Then verify whether the registration API call was isolated or part of a broader compromise chain that touched other jobs or repositories.

Technical breakdown

How compromised npm packages execute inside GitHub Actions

The attack began when workflow jobs resolved and installed dependencies during test execution, allowing compromised packages to run malicious preinstall scripts immediately. That matters because npm package installation is not passive. It can execute code with the same context as the workflow runner, including network access and any attached credentials. In this case, the malicious payload used the package lifecycle to pivot from dependency resolution into runtime execution without requiring a separate exploit chain.

Practical implication: treat dependency installation inside CI/CD as executable code, not just software retrieval.

Why baseline network monitoring catches supply chain attacks

Harden Runner built a per-workflow baseline of expected outbound destinations and flagged connections that had never appeared in Backstage’s test history. The key signal was not a known bad hash or signature. It was new behaviour, specifically downloads from bun.sh and oss.trufflehog.org, which were outside the normal pattern for E2E jobs. This is the same logic EDR uses on endpoints, applied to GitHub Actions runners.

Practical implication: define expected network destinations for each workflow and alert on any new external endpoint.

How runner registration creates persistence in CI/CD environments

The malware attempted to register a self-hosted GitHub Actions runner named SHA1HULUD through GitHub API calls, which would have created a reusable execution foothold. Persistence in CI/CD is especially dangerous because a registered runner can receive future jobs and inherit repository trust. That turns a one-time package compromise into a durable control-plane problem, especially where runner lifecycle and approval are weakly governed.

Practical implication: monitor for unexpected runner registration and enforce approval controls on self-hosted runners.

Threat narrative

Attacker objective: The attacker aimed to harvest credentials, establish persistence in CI/CD, and reuse compromised workflow access for broader supply chain compromise.

1. Entry occurred when trusted npm packages were updated during CI/CD execution and malicious preinstall scripts ran inside GitHub Actions workflows.
2. Escalation followed as the payload downloaded external tooling, scanned for secrets, and attempted to expand its access within the runner context.
3. Impact would have included credential theft and persistent repository access through self-hosted runner registration, although Backstage’s read-only token limited the blast radius.

NHI Mgmt Group analysis

Runtime behaviour is now the decisive control plane for CI/CD supply chain defence. Static scanning still matters, but it does not stop a trusted package from executing malicious code after installation. The Backstage case shows why baseline anomaly detection is stronger than assumption-based trust in build-time artefacts. Teams should treat workflow telemetry as a primary control, not an optional supplement.

CI/CD runners are non-human identities with temporary but highly privileged authority. They inherit access through tokens, secrets, and repository permissions, which means compromise can convert a single workflow into a lateral movement path. This is exactly the kind of delegated machine access that OWASP-NHI and the OWASP Non-Human Identity Top 10 aim to govern. Practitioners should manage runner credentials with the same discipline applied to other sensitive NHIs.

Persistent runners expose a governance gap that many teams still under-model. The malware’s attempt to register a self-hosted runner shows how persistence can be created through control-plane abuse rather than endpoint exploitation. That gap sits at the intersection of GitHub Actions security, secrets governance, and runtime authorization. Security teams should audit runner registration and lifecycle controls as part of CI/CD identity governance.

New endpoint destinations are a reliable named concept for supply chain detection: baseline deviation exposure. In this case, the anomalous calls to bun.sh and oss.trufflehog.org were the signal that separated malicious behaviour from ordinary test activity. The principle generalises across GitHub Actions, container builds, and other automation where expected network paths are knowable. Teams should build detections around baseline deviation exposure, not just known bad indicators.

Least privilege reduced the outcome, but it did not prevent the attack path. Backstage’s read-only token limited damage, yet the workflow still executed malicious code and attempted persistence. That distinction matters because many programmes stop at access restriction and ignore runtime observability. Practitioners should pair restricted permissions with behavioural controls, otherwise limited impact will be mistaken for effective prevention.

What this signals

Baseline deviation exposure is becoming the practical signal for pipeline compromise. The more automation depends on implicit trust in dependencies, the more teams need runtime controls that can distinguish normal test activity from malicious tool download and secret scanning. The relevant standard lens here is MITRE ATT&CK Enterprise Matrix, because the attack chain moved through credential access, collection, and persistence behaviours rather than a single exploit.

CI/CD identity governance now has to account for both delegated access and persistence attempts. A runner that can register itself, fetch external binaries, or inherit secrets is already operating as a privileged machine identity. That makes lifecycle controls, credential scope, and egress policy part of the identity programme, not just DevOps hygiene. The OWASP Non-Human Identity Top 10 is a useful reference point for that governance layer.

The next control gap is not whether a workflow can run, but whether its runtime behaviour can be constrained, observed, and reversed before a compromised package becomes a durable foothold. Teams should assume trusted automation can be repurposed and design for detection latency, not perfect prevention.

For practitioners

• Instrument workflow runtime with baseline anomaly detection Establish expected outbound destinations for each GitHub Actions workflow and alert on any new network target, especially during dependency install and test steps. Use this to catch supply chain payloads that evade CVE and lock-file checks.
• Treat CI/CD runners as privileged non-human identities Inventory runner tokens, repository permissions, and attached secrets as part of NHI governance, then reduce standing access to the minimum needed for each pipeline stage. Review runner permissions separately from application service accounts.
• Block unexpected external downloads during package execution Apply egress policy enforcement so workflows cannot fetch runtimes, scanners, or other executables from unapproved domains such as bun.sh or similar endpoints that never belong in routine builds.
• Monitor self-hosted runner registration as a persistence indicator Alert when workflows register new self-hosted runners or create runner names that do not match your normal provisioning process. Treat runner registration API calls as a high-signal control-plane event.

Key takeaways

• This case shows that supply chain attacks now succeed inside the workflow runtime, not just at the package registry.
• The strongest evidence was behavioural, with unfamiliar outbound connections and runner-registration activity exposing the compromise path.
• CI/CD security must combine least privilege, baseline monitoring, and runner lifecycle controls or automation will remain a persistence target.

Key terms

• Baseline Anomaly Detection: A detection method that compares current behaviour to an established normal pattern and alerts when activity deviates. In CI/CD, this often means tracking network destinations, process execution, and credential use so malicious package behaviour stands out quickly.
• Self-hosted runner: A CI/CD execution environment managed by the organisation rather than the platform vendor. It often has broad access to source, secrets, and deployment targets, which makes it a high-value persistence and exfiltration point if workflow controls are weak.
• Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
• Egress Policy Enforcement: A control that restricts where systems can send network traffic. In CI/CD environments, it prevents malicious code from downloading tooling, calling command-and-control infrastructure, or exfiltrating secrets to destinations that are not explicitly approved.

What's in the full article

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

• Interactive detection traces for the Backstage workflow runs that show exactly which network destinations were flagged as anomalous.
• Enterprise-tier visibility into HTTPS requests, process trees, and command-line arguments, which helps teams move from alerting to root-cause analysis.
• Evidence of how the malware attempted self-hosted runner registration through the GitHub API, showing the persistence path in more detail.
• Step-by-step recommendations for open source and enterprise teams that need to operationalise runtime monitoring across CI/CD.

👉 StepSecurity's full post covers the network baseline evidence, runner persistence attempt, and incident response detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into operational rules for workflows, runners, and other automation.