A release that was live for three hours
In one incident, two versions of axios were published with a stolen maintainer token. npm removed them about three hours later. A build that resolved a fresh axios in between installed a remote access trojan.
That is the usual course of a compromised release: it is found and removed, some time after it went live. A delay rule keeps versions younger than a set age out of your builds, so they do not install a release during those first hours.
Builds get the newest version that has aged
Before a package manager installs lodash ^4.17.0, it asks which versions exist. Dependency Firewall passes the question to the public registry and filters the answer. With a delay rule on, versions inside the window are left out.
The package manager picks the newest version on the list it was given. It never learns that 4.17.23 exists, so nothing fails and nothing is retried. The same happens for every dependency in the tree, including the ones nobody chose by name.
Why the same check at download breaks builds
An age check can also run when the file is downloaded. The version list is then untouched, the client picks the newest version and the fetch fails. An active dependency tree almost always has something younger than the window, so those installs fail often.
A rule on the version list steers the install to another version. A rule on the download can only stop it. Use the first to delay, and the second for what must never be served, such as malware.
The window is set in hours. 168 hours is 7 days.
Where an install still fails
| What is installed | Result |
|---|---|
| An exact pin of a version inside the window | Not found |
| A tag that points at a filtered version, such as a canary tag | Not found |
| A lockfile install of a version inside the window | Blocked |
| A lockfile install of a version older than the window. This is the normal case. | Served |
The same delay rule in every ecosystem
A delay rule is defined the same way in every ecosystem: a window in hours. Point your package managers at the firewall, and it enforces that window for every client, on every machine and in every environment that installs through it.
npm, pnpm, Yarn, Bun and uv each have their own setting for a delay, counted in days, minutes or seconds depending on the client. A setting covers only the machine or the repository it is written in, so each one has to be configured and kept the same.
Choose a window
You set the window per firewall. 7 days gives a bad release time to be reported without holding ordinary updates back for long. 14 to 30 days suits teams that update monthly. 1 day would already have kept the axios release out.
Let fixes through
An exception with the Vulnerability Fixes condition lets a version published as a fix for a known vulnerability skip the delay. For any other release you need early, add an exception for that package and version with an expiry date.