Incident Overview
In the Shai-Hulud incident, attackers published malicious npm packages containing hidden exfiltration scripts. These packages bypassed initial security checks and infiltrated production environments, where the scripts executed and transmitted data to attacker-controlled infrastructure.
The attack exploited the gap between package publication and security review. Although traditional scanning tools eventually detected the malicious code, it was too late—organizations had already integrated the compromised dependencies.
Timeline of Events
T+0: Malicious packages published to npm registry
T+unknown: Organizations install packages via automated dependency updates
T+unknown: Exfiltration scripts execute in development and production environments
T+unknown: Security scanning tools flag packages as malicious
T+unknown: Organizations begin incident response and remediation
The critical issue was the time between installation and detection, allowing the malicious code to run unchecked.
Failed or Missing Controls
Dependency Vetting Process: Organizations did not implement a holding period between package publication and adoption. New packages moved directly from npm into build pipelines without an observation window for suspicious behavior.
Runtime Monitoring: The exfiltration scripts executed without triggering alerts, indicating missing or insufficient monitoring of:
- Outbound network connections from build environments
- Unexpected data access patterns during dependency installation
- Process execution during package installation hooks
Automated Upgrade Policies: Teams configured their tools to pull the latest versions immediately upon release, bypassing human review before new packages entered the codebase.
Code Review for Dependencies: Malicious scripts embedded in packages went uninspected. Teams relied on npm's ecosystem without verification.
Relevant Standards
PCI DSS v4.0.1 Requirement 6.3.2 mandates reviewing custom code before release to production. This principle extends to dependencies: code you didn't write but are releasing into your environment requires review.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires employing supply chain protection mechanisms, including analyzing the software supply chain to identify potential threats. You need visibility into what you're installing before it runs.
ISO/IEC 27001:2022 Control 8.30 (Outsourced Development) addresses security requirements for externally developed software. Your npm dependencies are externally developed software. The control requires supervising and monitoring supplier activity.
These standards require proactive assessment before software enters your environment.
Action Items for Your Team
Implement a Dependency Cooldown Period: Avoid installing packages immediately upon publication. Configure your dependency management to wait 21 days before accepting new versions, allowing the security community to identify and report malicious packages. Snyk employs this 21-day cooldown period for automatic dependency upgrades—consider adopting it.
Configure your package.json or dependency management policy to:
- Pin major and minor versions
- Accept patch updates only after the cooldown
- Require manual approval for dependencies less than 21 days old
Monitor Network Traffic in Build Environments: Your CI/CD pipeline should not make outbound connections to arbitrary hosts during package installation. Configure egress filtering to:
- Whitelist only your package registries and essential services
- Log all connection attempts
- Alert on any connection outside the whitelist
If a package installation script tries to connect externally, you'll detect it immediately.
Create a Dependency Review Checklist: Before approving any new dependency:
- Check package age (reject if under 21 days)
- Review install scripts and lifecycle hooks
- Verify the maintainer's identity and history
- Check for unusual permission requests or network activity
- Look for packages with names similar to popular libraries (typosquatting)
Use a Centralized Visibility Tool: Maintain a single source of truth for all dependencies across projects. Snyk provides a centralized Zero-Day Report to prioritize remediation efforts—consider building or acquiring a similar tool. When a malicious package is discovered, you need to know immediately which teams are affected.
Your tool should display:
- Every project using a specific dependency
- Version numbers across all environments
- Time since last security review
- Pending updates in the cooldown period
Separate Development and Production Registries: Avoid pulling directly from public npm in production. Mirror packages to an internal registry after they pass your cooldown and review process, creating a controlled entry point for your environment.
Test in Isolated Environments First: Run new dependencies in sandboxed build environments before deploying to production. Configure your CI/CD to:
- Use disposable containers for initial builds with new dependencies
- Monitor resource usage and network activity
- Require security team sign-off before promoting to production pipelines
The Shai-Hulud incident succeeded because organizations prioritized speed over verification. Your dependency management process should assume any package could be malicious until proven otherwise. The 21-day cooldown isn't about being slow—it's about allowing the security community to perform initial vetting while you focus on building features.
Start with the cooldown period. It's the most impactful change you can implement this week and requires no new tools. Update your dependency management policies to wait 21 days before accepting new versions. This one change could have prevented Shai-Hulud entirely.
