Malicious versions of legitimate npm packages recently went live on the registry, but they were caught and removed within two hours. This incident led GitHub to introduce a three-day delay for Dependabot's non-security version updates.
This isn't just a hypothetical scenario. GitHub's Advisory Database logged over 6,500 npm malware advisories in the year ending May 2026. Your automated dependency updates could inadvertently introduce one of these packages into your production environment.
What Happened
GitHub implemented a three-day cooldown for Dependabot's automated version updates, affecting only non-security updates. Security patches still trigger immediate pull requests.
This change was prompted by incidents where malicious packages appeared on npm, were flagged by the community, and removed within hours. The two-hour detection window showed that rapid community scrutiny is effective, but only if you're not automatically adopting packages as soon as they're published.
Carlin Cherry, a GitHub product manager, pointed out that the delay has its limitations. It won't prevent slower-moving supply chain attacks where malicious code remains dormant for weeks or months. However, it does provide a buffer against the common pattern of compromised maintainer accounts pushing malicious updates that are quickly detected.
Timeline of a Typical Malicious Package Incident
T+0 minutes: Malicious version published to npm registry
T+15 minutes: Automated scanners flag suspicious code patterns
T+45 minutes: Community members report the package
T+90 minutes: npm security team begins investigation
T+120 minutes: Package removed from registry
Without a delay, Dependabot could create a pull request at T+5 minutes. If your CI pipeline auto-merges passing updates, you might adopt malicious code before the community even starts investigating.
Which Controls Failed or Were Missing
The core failure is temporal. Most dependency management strategies assume "latest" equals "safe," ignoring the lag between publication and verification.
Specific controls that were absent or insufficient include:
Human review gates: Many teams configure Dependabot to auto-merge non-security updates if tests pass, bypassing a manual checkpoint where someone might notice an unusual version bump or recent package activity.
Package vetting procedures: There's often no systematic check of package age, maintainer history, or community signals before adoption. The package exists, the tests pass, the merge happens.
Supply chain monitoring: Limited visibility into changes between versions beyond the changelog. No automated scanning of the actual code diff for suspicious patterns.
Rollback readiness: Slow incident response when a malicious dependency is discovered post-merge. The longer malicious code sits in your repository, the higher the chance it reaches production.
What the Standards Require
ISO/IEC 27001:2022 addresses software supply chain risk in Annex A.8.30 (Outsourced Development). You're required to establish controls for third-party code, including verification processes before integration. Auto-merging the latest version of any package without review doesn't meet this requirement.
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be reviewed prior to release to identify and correct security vulnerabilities. While this typically applies to your own code, dependencies become part of your application. If you're not reviewing what changed in a dependency update, you're not meeting the spirit of this control.
NIST Cybersecurity Framework v2.0 includes supply chain risk management in the Identify function (ID.SC-4): "Suppliers and third-party partners are assessed using a cyber supply chain risk management process." A three-day delay gives you time to perform that assessment. Immediate adoption doesn't.
SOC 2 Type II requires documented change management procedures (CC8.1). If your change management process is "Dependabot creates a PR, tests pass, auto-merge," you're missing the documented review and approval steps that auditors expect to see.
Lessons and Action Items for Your Team
Configure the delay properly. GitHub's three-day cooldown is now the default for non-security updates. Verify this setting in your Dependabot configuration. Don't override it unless you have compensating controls.
Disable auto-merge for dependency updates. Even with the delay, require human approval for version bumps. Your review doesn't need to be exhaustive, but someone should verify the package hasn't been flagged, the version increment makes sense, and recent issues don't show red flags.
Monitor package health signals. Before approving a dependency update, check the package's npm page for recent security advisories, unusual maintainer changes, or community reports. Tools like Socket or Snyk can automate some of this, but manual spot-checks catch things automated scanners miss.
Implement diff scanning. When Dependabot proposes an update, review the actual code changes between versions. Look for obfuscated code, unexpected network calls, or file system operations that don't match the package's stated purpose. This takes time but catches malicious code that passes automated tests.
Separate security patches from version updates. GitHub's delay doesn't apply to security updates, which is correct. But make sure your team treats these differently. Security patches should move faster, with a different approval workflow, while version updates get the full three-day wait plus review.
Document your vetting process. For SOC 2 and ISO 27001 compliance, write down how you evaluate dependency updates. Include the delay period, who approves updates, what signals you check, and how quickly you can roll back if a malicious package gets through. Auditors want to see this documented and followed consistently.
Test your rollback procedure. Assume a malicious dependency will eventually reach your main branch. How quickly can you identify it, remove it, and verify the removal? Run a tabletop exercise where a "malicious" test package gets merged and see how long recovery takes.
The three-day delay isn't a complete solution. It won't stop sophisticated attacks where malicious code waits weeks before activating. But it does stop the most common pattern: compromised accounts pushing obviously malicious updates that get caught within hours. Your job is to use that three-day window effectively, not just wait it out and auto-merge anyway.
