Delay new versions

Add a delay rule that keeps newly published package versions out of your builds until they have aged.

A compromised release is usually reported and pulled some time after it is published, but automated dependency updates and loose version ranges can pull it into a build minutes after it goes live. A delay rule closes that window: versions younger than a set age are filtered out, so your builds only see releases that have been public long enough for problems to surface.

It is a good first rule. It needs no vulnerability data, no tuning, and it applies to every package equally.

Add the rule

In the dashboard, open the firewall, go to Rules, and select Add Rule:

Execution phase: filter versions (called versions in config, API, and CLI)
Selector, max age: 7 days (presets range from 1 to 90 days; a custom value is also possible)
Effect: block and log

As JSON:

{
  "executionPhase": "versions",
  "selector": { "maxAgeHours": 168 },
  "ruleEffect": { "block": true, "log": true },
  "description": "Block versions younger than 7 days"
}

maxAgeHours is a whole number of hours. 168 is 7 days. The selector matches versions whose publish date is more recent than the max age, and the block effect filters them.

To apply the JSON without the dashboard: export the config with bsfw config export, add the rule to the rules array, and import it back. See config import.

Why the versions phase

A delay rule belongs in the versions phase (filter versions in the dashboard): clients resolve against the filtered version list and quietly land on an older version.

The same max-age selector in the download phase leaves the metadata untouched, so the client resolves to a version inside the window and then fails to fetch it. An install of an actively maintained package fails outright that way, because some dependency deep in the tree is usually younger than the window. Use the versions phase to delay, the download phase for hard gates. Execution phases covers the difference in depth.

Choose a window

7 days is a reasonable default. Long enough that a bad release has time to be reported, short enough that ordinary updates are not held up much.
14 to 30 days suits stability-focused teams that update on a monthly cadence anyway.
1 day still blocks the worst case, an install seconds after a hostile publish, at almost no cost.

What developers see

Version ranges, which is what dependency declarations normally are, keep working and resolve to the newest version older than the window. Nothing changes for lockfile versions older than the window, which is the normal case.

What a request inside the window gets depends on its shape:

An exact pin of a filtered version fails as not found, and so does a named tag or label that points at one.
An install without a stated version generally resolves to the newest remaining version.
A client that skips resolution and fetches the artifact directly, such as a lockfile install of a version inside the window, gets the blocked-download error with a request ID.

The exact behavior and error messages differ per package manager; each ecosystem page documents them under "What a blocked install looks like".

Verify

Install a package version published within your window, then confirm the rule fired:

bsfw logs --firewall <firewall-id>

The log entry shows the rule match and the filtered version. For the client-side check with your package manager, see your ecosystem page.

When you need a fresh version anyway

A security patch you want immediately, or a release you have verified yourself: do not widen the rule, add an exception scoped to that package and version, with an expiry.

Concept: Rule evaluation
Reference: Rules and selectors
Ecosystem behavior: Ecosystems