Five supply chain attacks in 48 hours exposed pipeline blind spots

At a glance

What this is: This is an analysis of a 48-hour supply chain attack wave that targeted multiple stages of software development and showed why single-point controls failed.

Why it matters: It matters because IAM, secrets, and access governance now extend into developer tooling, CI/CD runners, and package ecosystems where stolen credentials can move faster than review cycles.

By the numbers:

• Five distinct attacks targeted every layer of the development pipeline in just 48 hours.
• GitHub disclosed that approximately 3,800 internal source code repositories were exfiltrated.
• Microsoft's durabletask PyPI package was attacked with three malicious versions in 35 minutes.

👉 Read StepSecurity's analysis of five supply chain attacks in 48 hours

Context

Software supply chain security fails when organisations treat the pipeline as a single control plane. In practice, the attack surface spans developer machines, package registries, source control workflows, and ephemeral CI/CD runners, each with different trust assumptions and different visibility gaps. This article is about pipeline-wide compromise, and the primary keyword is supply chain security.

The identity angle is real because the attacks are credential-led. The objective was not just code tampering, but secret theft, token reuse, and persistence through trusted integrations. That makes this a governance problem for IAM, PAM, and NHI teams as much as for application security and platform engineering.

The starting position described here is not atypical, because many enterprises still depend on scanners, registry policy, and production monitoring to cover a threat that now lives inside build-time execution and developer tooling.

Key questions

Q: What breaks when software supply chain security relies only on SCA scanning?

A: SCA-only programmes generate visibility without decision quality. They identify vulnerable packages, but they do not tell teams whether a dependency is reachable, whether a finding is exploitable in context, or which issues matter most to the business. The result is alert fatigue, slow remediation, and a backlog that hides the exposures attackers are most likely to use.

Q: Why do compromised developer tools create identity risk as well as code risk?

A: Developer tools often hold the same credentials that access source control, cloud services, package registries, and password vaults. When a poisoned extension or local package is compromised, the attacker can harvest reusable secrets and replay them across systems. The result is identity compromise that starts on an endpoint but expands into the pipeline.

Q: How should security teams reduce the blast radius of compromised CI/CD tools?

A: Limit each pipeline to the minimum credentials it needs, separate build from deploy permissions, and remove long-lived secrets from execution environments. The goal is to ensure that a poisoned package or workflow can only reach a narrow identity scope, not cloud administration, repository control, or broad data access. Review service accounts as privileged identities, not generic automation.

Q: Who is accountable when a compromised package credential is used to spread malicious artefacts?

A: Accountability sits with the organisation that owns the publishing authority and the surrounding identity controls, not just the developer who used the tool. Publishing access is a privileged identity path, so governance must cover ownership, monitoring, and revocation with the same seriousness as other elevated access.

Technical breakdown

Why scanner-based supply chain security misses runtime abuse

Software composition analysis and source scanning are designed to find known vulnerabilities, not to observe behaviour inside ephemeral build environments. A compromised package can be clean at publication time, then become malicious after installation or during execution inside a runner. That is why a package that looks trusted in a manifest can still be used to harvest tokens, read process memory, or stage exfiltration from inside the pipeline. The control gap is visibility at runtime, where the abuse actually happens.

Practical implication: add runtime monitoring to CI/CD runners instead of assuming package and code scans can catch behavioural abuse.

How compromised GitHub Actions and npm worms use trusted execution paths

Trusted automation is the weakness here. GitHub Actions run with the permissions and network reach that teams grant to build and release workflows, while npm worms can spread by abusing stolen tokens and package update trust. Once an attacker hijacks tags, replaces commits, or leverages an action already embedded in workflows, every downstream run inherits that trust. The technical failure is not just malicious code, but malicious code running through sanctioned identity and deployment paths.

Practical implication: treat workflow references, tags, and package updates as privileged execution decisions, not routine maintenance events.

Why developer workstations are now part of the supply chain attack surface

Developer laptops are no longer just endpoints, they are credential aggregation points. IDE extensions, local package managers, cloud CLI tools, browser sessions, and password managers all coexist on the same device, which makes a single compromise valuable to attackers. A poisoned extension can steal tokens from multiple ecosystems at once, then use those secrets to pivot into source control and build systems. The architectural mistake is separating developer trust from pipeline trust when the same identity context flows across both.

Practical implication: inventory developer tooling and secrets exposure the same way you inventory production identities and service accounts.

Threat narrative

Attacker objective: The objective was to steal credentials, preserve trusted access, and use that access to broaden compromise across software delivery environments.

1. Entry began with compromised developer-facing and supply-chain components, including a poisoned VS Code extension, hijacked GitHub Actions, and trojanized package releases.
2. Credential access followed through token theft, runner process memory reads, and secret harvesting from developer tools, package configs, and CI/CD environments.
3. Escalation and propagation occurred when stolen credentials were reused to compromise more repositories, spread a self-replicating npm worm, and expand access across trusted pipelines.
4. Impact included source code exfiltration, widespread ecosystem exposure, and persistent compromise across development and delivery workflows.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pipeline security has become an identity problem as much as a code problem. The article shows that attackers are not just exploiting software defects, they are abusing trusted identities inside build and delivery systems. Once credentials are stolen from developer tools, runner memory, or package workflows, the attacker is operating as a trusted principal rather than a noisy intruder. Practitioner conclusion: governance must track where secrets flow, who can reuse them, and which identities remain trusted after compromise.

Runtime control is the missing layer in most supply chain programmes. Scanners, registries, and source analysis all have value, but they do not govern live execution inside CI/CD or on developer endpoints. That gap explains why malicious actions, worms, and trojanized packages can move faster than remediation. Practitioner conclusion: if you cannot observe the runtime, you cannot claim supply chain containment.

Standing trust in developer and pipeline identities is the core failure mode. This wave exposed a model in which tokens, action tags, and package versions remain trusted longer than they should. The problem is not only exposure, but persistence of privilege after that exposure is known or suspected. Practitioner conclusion: reduce trust duration as aggressively in pipelines as you do for human sessions.

Secrets governance must now include developer experience and build automation. The article makes clear that secrets are not confined to vaults or production systems. They move through IDE extensions, local tools, CI runners, and package managers, which means an NHI governance model has to cover every place a machine credential can be stored or replayed. Practitioner conclusion: unify NHI inventory, rotation, and offboarding across developer and pipeline environments.

Supply chain consolidation does not remove risk, it concentrates blast radius. When widely used extensions, actions, or packages are compromised, the exposure multiplies through downstream dependencies and workflow reuse. That concentration makes governance assumptions brittle, especially where organisations assume trusted ecosystems are inherently safe. Practitioner conclusion: evaluate dependency trust as a first-class risk variable, not a procurement detail.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• For a deeper NHI lens: Review the 52 NHI Breaches Analysis for repeated patterns of secret exposure and reuse across real incidents.

What this signals

The programme-level signal is that supply chain security now depends on identity governance across developer endpoints, CI/CD runners, and package ecosystems. Organisations that cannot inventory where tokens live and how long they remain trusted will keep discovering compromise after the attacker has already moved on.

Pipeline trust debt: this article describes the accumulated risk created when tags, packages, and automation credentials remain trusted beyond their safe window. Teams should watch for mutable trust assumptions that have never been formally owned, reviewed, or revoked.

A practical next step is to align developer tooling governance with machine identity controls, then connect those controls to incident response playbooks and exposure searches. That is the difference between detecting a bad package and containing a pipeline-wide compromise.

For practitioners

• Inventory developer-side secrets exposure Map IDE extensions, package managers, cloud CLIs, and password manager integrations across developer endpoints so you can identify where a compromised tool could collect tokens or API keys.
• Add runtime controls to CI/CD runners Monitor process memory, outbound network destinations, and shell execution on ephemeral runners because attack detection at the manifest layer will not stop secret theft in runtime.
• Treat action tags and package versions as privileged inputs Block or review workflows that reference mutable tags, recently published packages, or unverified action commits so trusted automation cannot silently inherit malicious replacements.
• Unify NHI lifecycle governance across build tools Apply the same inventory, rotation, revocation, and offboarding discipline to CI/CD tokens, package tokens, and developer machine secrets that you use for production machine identities.
• Pre-build an exposure query for known compromises Maintain a rapid search process for affected extensions, actions, and packages so incident response can answer whether your environment is exposed before manual triage begins.

Key takeaways

• This incident wave showed that software supply chain compromise now spans developer tools, package ecosystems, and CI/CD execution.
• The most damaging failures were identity failures, because stolen credentials and trusted workflows turned isolated compromises into broader access.
• Organisations need runtime pipeline controls, tighter trust duration, and faster secret revocation to shrink blast radius.

Key terms

• CI/CD security testing: The use of automated security checks inside continuous integration and continuous deployment pipelines. This includes tools that evaluate code, running applications, and interactive behaviour so vulnerabilities can be found and blocked before deployment becomes irreversible.
• Trusted Execution Path: A trusted execution path is a system route that assumes the caller is already authorised once initial access is granted. In SAP, these paths often include RFC, web service, and legacy UI functions. If enforcement is inconsistent, the path becomes a control-plane weakness rather than a normal application feature.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
• Developer Endpoint Risk: Developer endpoint risk is the elevated exposure created when a workstation holds source code, signing material, tokens, and access to build or repository systems. A compromise can propagate beyond the device because the attacker can reuse those identities and trust relationships elsewhere.

What's in the full article

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

• Detailed attack timelines for the Nx Console extension, malicious GitHub Actions, Shai-Hulud, and Microsoft's durabletask compromise
• Environment-specific detection and blocking controls across Dev Machine Guard, Harden Runner, and Compromised Actions Policy
• The full incident matrix showing which StepSecurity control applies to each attack vector
• IOC and remediation detail for teams that need to confirm exposure or response steps

👉 StepSecurity's full post covers the attack timeline, control matrix, and runtime defence detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and IAM fundamentals. It is relevant for practitioners who need to extend identity controls into developer and automation environments.