Package Minimum-Age Config Generator
A package published an hour ago has had no time to be reviewed. Choose your ecosystems and a delay, and get the setting (or the proxy pattern where no setting is certain) that stops builds from taking brand-new releases, plus lockfile discipline and a safe way to override it for an urgent fix. Everything runs in your browser.
Using 7 day(s). Jack Cable's guide suggests at least 7.
pnpm
Documented settingWhere: pnpm-workspace.yaml (pnpm's minimumReleaseAge setting, expressed in minutes)
# pnpm-workspace.yaml minimumReleaseAge: 10080 # 7 day(s) in minutes
The value is in minutes, so days are multiplied by 1440. pnpm also has an exclusion list for packages you must take immediately; check the exact name and the minimum pnpm version in the pnpm docs.
pnpm install --frozen-lockfile
npm
Verify in the vendor docsWhere: npm may offer a native release-age setting in recent versions; verify in the npm docs for your version before relying on it
If your npm version has no native setting, use a registry or proxy that enforces a cooldown, or let Renovate or Dependabot hold new versions back (see the dependency-bot section below). Do not copy a setting name from a blog post without finding it in the current npm documentation.
npm ci
npm ci installs exactly what package-lock.json says and fails if it disagrees with package.json.
uv (Python)
Documented settingWhere: pyproject.toml [tool.uv] exclude-newer, or the --exclude-newer flag: it takes a date/time, not an age
# uv takes a cut-off DATE, not "7 days". Compute it in CI each run: CUTOFF=$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ) # GNU date; on macOS: date -u -v-7d +%Y-%m-%dT%H:%M:%SZ uv lock --exclude-newer "$CUTOFF" # or, in pyproject.toml (a fixed date you bump on a schedule): # [tool.uv] # exclude-newer = "2026-11-01T00:00:00Z"
A fixed date in pyproject.toml goes stale unless something bumps it; computing it in CI keeps the window rolling. Newer uv releases may also accept a relative duration: verify in the uv docs.
uv sync --locked
uv sync --locked fails if uv.lock is out of date instead of silently re-resolving.
Dependency update bots
Both Renovate and Dependabot document a delay setting. Use the same number so the bot does not propose a release that is hours old.
// renovate.json
{
"packageRules": [
{ "matchPackageNames": ["*"], "minimumReleaseAge": "7 days" }
]
}# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
cooldown:
default-days: 7Where there is no native setting: the proxy or registry pattern
- Put a registry or proxy between your developers/CI and the public registry (a repository manager, or a registry mirror you run).
- Configure it, if it supports this, to hide or delay any version published less than N days ago. Verify the exact rule name in your product's documentation.
- Point every package manager at the proxy through its config file (never rely on each developer's local setting).
- Block direct egress to the public registries from CI so the proxy cannot be bypassed.
- Log which versions were served and when, so you can answer "did we install the bad release?" later.
CI checklist
- CI installs only from the lockfile, with the command shown for each ecosystem above.
- The lockfile is committed and reviewed like code; a lockfile diff in a pull request is read, not skimmed.
- The minimum-age setting is in a file in the repository (or the proxy), not in a developer's home directory.
- Dependency update bots (Renovate, Dependabot) have the same minimum age, so they do not propose a release that is hours old.
- Install scripts are reviewed or disabled where your package manager allows it; verify the option in its docs.
- Direct egress from CI to public registries is blocked if you use a proxy.
- There is a written override procedure (below) and someone who can approve it.
Urgent security fix override
- Name the advisory: the CVE or vendor notice that makes the new version urgent, and who confirmed it. Prefer a primary source (vendor advisory, CISA KEV entry).
- Read the release diff or changelog yourself or have a second person do it. The age window exists because the community has not yet had time to review this version.
- Allow only that package at only that version (an exclusion entry or a one-off proxy allow rule), not a global change to the window.
- Get a named approver to sign off, and record the ticket and the time.
- Install from the lockfile after the lockfile change is reviewed, then watch for unexpected network calls or new install scripts in the first builds.
- Remove the exception once the version is older than the window anyway.
Everything runs in your browser. Nothing is uploaded and nothing is checked against your registries.
TL;DRWhat this tool is
5 points
- Pick your package ecosystems and a minimum release age in days (the default is 7). You get the setting, or the proxy or registry approach, for each.
- Only settings the page is confident exist are printed. Everything else is labelled "Verify in the vendor docs" with a proxy fallback, and no setting name is invented.
- It also gives a lockfile command per ecosystem, a CI checklist, an override procedure for urgent security fixes, and a plain statement of the trade-off.
- Copy any block, or download the whole pack as Markdown.
- Advisory only. It runs in your browser and does not read or change your repositories or registries.
Let new releases age
In “A Practical Guide to Security in November 2026”, Jack Cable recommends setting a minimum package age of at least 7 days for npm, PyPI and other package managers, through configuration or a proxy or registry, because malicious releases are usually caught and pulled within that window. He pairs it with pinning versions, committing lockfiles and installing from the lockfile in CI. Those are the author's recommendations.
The guide was written against a backdrop of recent incidents. Per the article, a malicious Claude Code extension version for Cursor was disclosed by Cursor on 29 October, with fewer than 5,000 installs per Cursor. A delay on new versions is one cheap control against that class of problem.
Package-manager features change quickly. This page prints a setting only where it is confident the setting exists, and says “verify in the vendor docs” otherwise. It does not read your repositories or registries.
Sources
- Jack Cable, “A Practical Guide to Security in November 2026”, 4 Nov 2026 (X/@jackhcable). Recommendations on this page are attributed to the author.
- Vendor documentation for each package manager, Renovate and Dependabot. Confirm every setting there before you roll it out.
Frequently asked questions
Why wait a number of days before installing a new package version?
Jack Cable's guide, "A Practical Guide to Security in November 2026" (4 Nov 2026), recommends a minimum package age of at least 7 days for npm, PyPI and other package managers, because malicious releases are usually caught and pulled within that window. That is the author's claim. A malicious release can survive longer, so treat the delay as one layer.
Does my package manager support this natively?
Some do and some do not, and support depends on the version. This page prints a setting only where it is confident the setting exists. For the rest it says to verify in the vendor docs and offers a registry or proxy cooldown, or a Renovate or Dependabot delay, as the fallback.
Why does uv use a date and not a number of days?
uv's documented exclude-newer setting takes a cut-off timestamp. To get a rolling window you compute the date in CI (today minus N days) and pass it in. The page shows the command.
What about an urgent security fix?
Use an override: allow only that package at only that version, after someone has read the diff and a named approver has signed off, then remove the exception. The pack includes the steps.
Is a lockfile enough on its own?
No. A lockfile makes installs repeatable, but a malicious version you locked is still malicious. The age gate reduces the chance you lock a brand new bad release; the lockfile stops silent changes after that. Use both.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.