Your package manager trusts every update it receives. That trust just became your biggest vulnerability.
Between September 14th and 18th, the Shai-Hulud worm altered more than 500 package versions on npm without a single compromised maintainer account. The follow-up attack, ChainDrop, compromised more than 400 packages in less than four hours using legitimate, cryptographically signed release pipelines. If you're still treating package registries as trusted infrastructure, you're operating with a broken threat model.
This checklist helps you redesign your dependency management to assume compromise, not trust.
Prerequisites
Before implementing these controls, verify you have:
- Inventory of direct and transitive dependencies across all production applications
- CI/CD pipeline access with the ability to modify build steps and approval gates
- Artifact repository (Artifactory, Nexus, or similar) with write access
- SBOM generation capability in your build toolchain
- Monitoring/alerting system that can track package update events
Package Registry Security Checklist
1. Implement private registry mirroring
What to do: Configure your package manager to pull from an internal mirror, not directly from public registries.
How to verify: Run npm config get registry (or equivalent for your package manager). The URL should point to your internal infrastructure, not registry.npmjs.org.
Good looks like: Every developer and CI/CD agent pulls from https://registry.yourcompany.internal. Your mirror syncs on a controlled schedule, not in real-time. You can freeze the mirror completely during an incident investigation.
2. Enable package version pinning with hash verification
What to do: Lock every dependency to an exact version and cryptographic hash in your lockfiles. Reject any package that doesn't match the recorded hash.
How to verify: Check your package-lock.json, yarn.lock, or equivalent. Every entry should include an integrity hash (starts with sha512-). Run your build with --frozen-lockfile or ci mode to ensure strict matching.
Good looks like: A compromised package version can't silently replace your dependency because the hash won't match. Your build fails loudly rather than installing malware.
3. Separate credential scopes for read vs. publish
What to do: Create distinct tokens for package installation (read) and package publishing (write). Never give your CI/CD runners publish credentials unless they're specifically part of your release pipeline.
How to verify: Audit your CI/CD environment variables. Build jobs should only have read tokens. Publish jobs should use time-limited tokens that expire within hours, not permanent credentials.
Good looks like: An attacker who compromises your build environment can't publish malicious packages to your internal registry because those runners lack write permissions. This addresses PCI DSS v4.0.1 Requirement 8.6.3 (application and system accounts are managed and authenticated).
4. Require human approval for dependency updates
What to do: Configure automated dependency update tools (Dependabot, Renovate) to create pull requests, not auto-merge. Add a mandatory review step before any dependency version changes reach production.
How to verify: Check your repository settings. Auto-merge should be disabled for dependency PRs. Your branch protection rules should require at least one approving review.
Good looks like: When a dependency update PR appears, someone on your team reviews the changelog, checks for unexpected behavioral changes, and verifies the package maintainer before approving. Automated updates can't propagate through your codebase without human oversight.
5. Scan packages before mirroring them internally
What to do: Run static analysis on packages before they enter your private registry. Check for suspicious install scripts, unexpected network calls, and known malware signatures.
How to verify: Your registry proxy should log scan results for each package version. Failed scans should block the package from entering your mirror.
Good looks like: Tools like Snyk, Sonatype, or Socket.dev scan every package version. Packages with postinstall scripts that spawn shells or make network requests get flagged for manual review before you'll mirror them.
6. Monitor package update frequency and blast radius
What to do: Set up alerts when a package you depend on releases multiple versions in a short timeframe, or when an update would affect more than a threshold number of your applications.
How to verify: Your monitoring system should track package version changes across your SBOM inventory. Configure alerts for patterns like "5+ versions released in 24 hours" or "update affects 10+ services."
Good looks like: When Shai-Hulud-style automation starts publishing rapid-fire updates, you get alerted before those versions enter your mirror. You can investigate before any of your teams pull the compromised code.
7. Implement SBOM diffing in your pipeline
What to do: Generate SBOMs at each build and compare them against the previous production SBOM. Flag any unexpected dependency additions or version jumps that skip intermediate releases.
How to verify: Your CI/CD pipeline should fail if a new transitive dependency appears without explanation, or if a direct dependency jumps from version 1.2.0 to 1.2.5 without passing through 1.2.1-1.2.4.
Good looks like: You maintain SBOM history in version control. Unexpected changes trigger a review workflow. This supports ISO 27001 Annex A 8.31 (separation of development, test and production environments).
Common Mistakes
Trusting cryptographic signatures alone: ChainDrop proved that attackers can compromise legitimate signing keys. Signatures verify authenticity, not safety. You still need behavioral analysis and human review.
Assuming transitive dependencies are someone else's problem: Your direct dependencies pull in hundreds of packages you've never reviewed. Map your full dependency tree and apply the same scrutiny to transitive dependencies.
Relying on registry-provided malware scanning: Public registries scan for known threats, but novel attacks like Shai-Hulud won't match existing signatures. You need defense in depth.
Treating all packages equally: Not every package deserves the same scrutiny. Prioritize packages with install scripts, network access, or filesystem operations. These are your highest-risk dependencies.
Next Steps
Start with items 1, 2, and 4 this week. Private mirroring, hash verification, and human approval gates stop automated propagation immediately. Add scanning and monitoring (items 5 and 6) within the next sprint. SBOM diffing (item 7) provides long-term visibility but requires more infrastructure investment.
Document your incident response plan for a compromised dependency. When (not if) a malicious package enters your supply chain, you need a tested process to identify affected systems, roll back versions, and verify integrity across your fleet.
The attacks on npm demonstrated that automation and cryptographic trust aren't enough anymore. Your security model needs to assume that any package could be compromised at any time. Build your controls accordingly.
