The Cybersecurity Infrastructure and Security Agency recently offered some guidance in response to a widespread software supply chain compromise involving the world’s largest JavaScript registry, npmjs.com. A self-replicating worm—publicly known as “Shai-Hulud”—has compromised over 500 packages.
After gaining initial access, the cyber actor deployed malware that scanned the environment for sensitive credentials. The cyber actor then targeted GitHub Personal Access Tokens (PATs) and application programming interface (API) keys for cloud services, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. The malware then:
- Exfiltrated the harvested credentials to an endpoint controlled by the actor.
- Uploaded the credentials to a public repository named Shai-Hulud via the GitHub/user/repos API.
- Leveraged an automated process to rapidly spread by authenticating to the npm registry as the compromised developer, injecting code into other packages, and publishing compromised versions to the registry.
CISA urges organizations to implement the following recommendations to detect and remediate this compromise:
- Conduct a dependency review of all software leveraging the npm package ecosystem.
- Check for package-lock.json or yarn.lock files to identify affected packages, including those nested in dependency trees.
- Search for cached versions of affected dependencies in artifact repositories and dependency management tools.
- Pin npm package dependency versions to known safe releases produced prior to Sept. 16, 2025.
- Immediately rotate all developer credentials.
- Mandate phishing-resistant multifactor authentication (MFA) on all developer accounts, especially for critical platforms like GitHub and npm.
- Monitor for anomalous network behavior, blocking outbound connections to webhook.site domains and monitoring firewall logs for connections to suspicious domains.
- Harden GitHub security by removing unnecessary GitHub Apps and OAuth applications, and auditing repository webhooks and secrets.
- Enable branch protection rules, GitHub Secret Scanning alerts, and Dependabot security updates.
Offering additional perspective on the attack were David Linder, CISO at Contrast Security, and Tom Pace, CEO of software supply chain cybersecurity firm NetRise.
"The CISA recommendations are a fantastic starting point, but to truly get ahead of the next threat, you need to build on them with a more proactive defense," offers Linder. "A key part of this is using runtime SCA, which goes beyond predeployment scans by giving you a live, real time view of what third party code is actually executing in your production environment.
"This provides the ground truth of what's running. Even with that advanced visibility, I can't recommend version pinning enough. It is the most powerful and direct line of defense you have.
"A critical part of this strategy includes establishing an incubation period, meaning you should intentionally wait before adopting the very latest package updates. This buffer period gives the community time to discover issues, so you're not the first to find a malicious package.
"By combining an incubation period with explicitly locking in trusted versions, you effectively lock your project's 'front door'. As a final safety net, ensure strong network controls are in place to prevent any code from reaching out to unknown or untrusted locations, containing the potential damage if a compromise ever occurs."
Pace continues, "CISA’s recent alert on the Shai-Hulud compromise in the npm ecosystem captures the evolving nature of software-supply-chain risk. What began as a JavaScript package infection quickly escalated into a credential-harvesting operation.
"This incident reinforces a critical point: software risk extends far beyond vulnerabilities in code. Misconfigurations, embedded secrets, and insecure cryptographic material are just as dangerous—and often far more easily exploited.
"We believe the npm compromise illustrates why visibility must extend into the compiled software itself, not just the source repositories that describe it. Most SBOMs today are created from source-code manifests. These files capture intent—what developers planned to include. But during compilation and linking, a series of well-understood build-time changes can alter that reality:
Dependency resolution: Build tools may choose older or cached versions of libraries based on local environments.
Static linking and vendoring: Packages often embed third-party code directly, bypassing dependency managers.
Transitive inclusions: Build systems automatically pull in secondary or tertiary packages not listed in manifests.
Build-specific flags and optimizations: Compiler options can inline or modify code, introducing functional divergence.
"The result is that source-derived SBOMs often diverge from the software actually shipped and executed. That gap can conceal vulnerabilities, untracked components, or even malicious payloads inserted earlier in the supply chain.
"CISA’s 2025 Minimum Elements for a Software Bill of Materials (SBOM) draft takes important steps toward closing this gap. New elements—Component Hash, Generation Context, and Coverage—move SBOMs closer to describing artifacts rather than aspirations. These changes recognize that the software an organization deploys is not the same as the software defined in source control.
"In our formal comments to CISA, we urged the agency to go one step further: require validation of every SBOM against the compiled binaries or containers they represent. Only then can agencies or enterprises confirm that a declared SBOM actually matches the operational software.
"Equally important, the npm incident demonstrates that a complete SBOM must describe more than just known vulnerabilities (CVEs). CISA’s alert highlighted how attackers exploited credentials and API keys rather than exploiting a specific CVE. This kind of non-CVE risk—hard-coded secrets, exposed certificates, or weak encryption—rarely appears in conventional SBOMs. Yet these often represent the entry points adversaries use to escalate privileges or move laterally.
"The npm compromise is yet another example of how attackers need not exploit source vulnerabilities when credentials, misconfigurations, and opaque build processes offer easier access. To meet that challenge, the security community must ensure that SBOMs reflect the software we run, not merely the software we write."
