Notifications
Clear all
Topic starter
02/08/2026 12:16 pm
TL;DR: The Shai-Hulud worm has reemerged through a malicious bun_environment.js package, and several npm accounts, including @asyncapi and @posthog, appear compromised, underscoring how dependency trust can be weaponised across the SDLC, according to Veracode. Software supply chain security now depends on faster package verification, blocking, and policy enforcement, not just after-the-fact detection.
NHIMG editorial — based on content published by Veracode covering the Shai-Hulud npm worm: Return of the “Shai-Hulud” Worm
Questions worth separating out
Q: What breaks when malicious npm packages execute during CI/CD installs?
A: The main failure is that package installation becomes code execution inside a trusted build context.
Q: Why do compromised package publisher identities matter for supply chain security?
A: Because the publisher identity is often the trust anchor for accepting updates.
Q: How do security teams know whether dependency controls are actually working?
A: Look for blocked install attempts, reduced exposure of secrets during package installation, and fewer unapproved packages reaching build and runtime environments.
Practitioner guidance
- Enforce pre-install package controls Block unknown, newly modified, or suspicious packages before they enter CI/CD, and require policy checks at the repository boundary rather than relying on post-install alerts.
- Separate build trust from dependency trust Run package installation in constrained environments that do not expose long-lived credentials, cloud tokens, or developer secrets during dependency resolution.
- Review publisher and maintainer identity Treat package maintainer accounts, publishing tokens, and automation identities as governed assets with rotation, revocation, and offboarding controls.
What's in the full analysis
Veracode's full post covers the operational detail this post intentionally leaves for the source:
- The known affected package list and how it changes as new malicious releases are identified.
- Package Firewall and SCA handling details for organisations that need execution-time control decisions.
- Veracode's ongoing detection and blocking approach for anomalous publishing behaviour and obfuscated code.
- The threat-research update cadence for tracking new npm campaign variants.
👉 Read Veracode's analysis of the Shai-Hulud npm worm and affected packages →
Shai-Hulud in npm: what this worm means for SDLC controls?
Explore further
02/08/2026 1:18 pm
Shai-Hulud is a dependency trust failure, not just a malware variant. The central issue is that software delivery still assumes package ecosystems are trustworthy until proven otherwise, which leaves a large window for malicious publishing. For identity and NHI governance, that same trust model applies to publisher accounts, automation tokens, and build identities. Practitioners should treat package trust as an access-control problem, not only a malware-scanning problem.
A few things that frame the scale:
- 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.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a malicious package reaches production systems?
A: Accountability usually sits across security, engineering, and platform operations. Engineering controls the dependency choices, security defines the detection and response requirements, and platform teams govern build pipelines and package trust policies. Frameworks such as NIST CSF, NIST 800-53, and MITRE ATT&CK support shared ownership of prevention, detection, and response.
👉 Read our full editorial: Shai-Hulud’s return shows npm supply chain risk is still spreading
