Key Takeaways

  • Package managers like pnpm popularized package cooldown periods, but pausing installs gives developers a false sense of safety while delaying critical security fixes.
  • Centralized registries like npm cannot ban non-JavaScript assets or disable post-install scripts without breaking standard tooling like browser binaries and HTML templates.
  • Modern attackers split malicious behavior across multiple packages and files rather than running a single obvious payload in a post-install hook.
  • Modern supply chain defense requires tracking developer endpoints and behavioral changes across commits instead of relying on static registry boundaries.

The False Safety of Package Cooldowns

Many engineering teams configure their package managers to ignore any release published in the last few days. The thinking sounds logical: let someone else be the guinea pig, wait for the community to spot malware, and pull the release only after it proves benign. Package managers like pnpm helped popularize this cooldown rule in JavaScript workflows.

Ahmad Nassri spent years as CTO of npm, and he sees the flaw in this tactic immediately. Cooldown periods create artificial delays without solving the underlying threat. Worse, they break incident response when your team needs a fix right away.

As Nassri points out: “What about CVEs? What about, you know, productions critical security issues that you need to solve? If you're now blocking yourself from that latest version of the package, now you're either enforcing your development team to go through like a much larger kind of exception workflow” (play from 45:29) or staying vulnerable to a known exploit. When an attacker can compromise a project and deploy malicious code within hours, a 48-hour delay just stops your engineers from shipping critical emergency patches. You trade protection for administrative overhead and messy bypass procedures.

Why Registries Cannot Simply Lock the Front Door

When malicious packages slip through, founders often ask a simple question: why does npm allow arbitrary code execution during installation in the first place? Why not restrict uploads to plain JavaScript?

The answer is historical and structural. JavaScript packages rarely contain just clean application code. They pull down pre-built native binaries, download headless browser engines, compile C++ extensions, and distribute interface assets like CSS and HTML templates. Restricting packages to pure JavaScript would break modern web tools.

Nassri explains the trade-off that defined the registry from the start: “if npm at the early days decided to say, you know what, only going to be JavaScript files, nobody else can publish anything other than JavaScript files, then all of a sudden you don't have the capability of, you know, doing front-end components with it, or front-end systems, or HTML files, or CSS and so on.” (play from 35:11) Post-install scripts exist because modern web development demands dynamic setup steps, like pulling down Chromium for end-to-end tests. That same mechanism gives malicious packages an open door to execute arbitrary commands the second an engineer runs an install.

To make matters worse, attackers no longer drop loud, single-file payloads that static linters catch. Nassri notes that attackers assemble attacks across distributed modules: “A big An interesting theme that we're starting to see now is this, you know, multiple packages coming together to actually form a compromise, as opposed to just the one package and the one file that's actually doing the bad thing in a post-install step.” (play from 27:24) One module provides innocuous helper utilities, another reads local environment variables, and a third transmits tokens to a remote server. Individually, each package passes registry checks.

Static gates at the registry level fail because the danger lives at the edges. Nassri argues that true security requires tracking every step: “So unless you actually own everything about the software development process from the registry itself, the publishing mechanisms, the CI/CD environment, the GitHub repo in which is managed, maybe all the kind of code commits that are going in from third parties and from contributors, to even like the developer machines, where the compromises are actually happening nowadays, it's at that at the end point level.” (play from 24:54)

What to Do With This

Audit your local package installation settings this week. If you rely on blanket cooldown rules or simple blocklists, turn on behavioral monitoring that inspects what post-install scripts execute on developer machines and in CI. Flag any dependency that requests network access, reads disk paths outside its project directory, or touches environment secrets during installation.