feat: set default min-release-age to 3 days

[sotanengel]

🛡️ Motivation: Recent Supply Chain Attacks

This change is motivated by a wave of confirmed supply chain attacks in 2025–2026:

Incident	Date	Impact
Shai-Hulud npm Worm	Sep 2025	200+ npm packages compromised via stolen GitHub tokens; secrets exfiltrated from CI/CD
Trivy GitHub Actions Compromise	Mar 2026	Build pipeline of the popular security scanner hijacked; malicious script injection risk
Polyfill.io Domain Hijack	Ongoing	Domain acquisition used to distribute malicious JS to 100,000+ websites
axios npm Compromise	Mar 2026	Maintainer account takeover; RAT-infected version published

Key finding: According to Andrew Nesbitt's research, 8 out of 10 recent supply chain attacks were detected and removed within 1 week of publication. A 3-day cooldown would have blocked most of them automatically.

🔧 What This PR Does

Sets the default value of min-release-age from null (disabled) to 3 (days).

• Before: packages are installable immediately after publishing
• After: packages must be at least 3 days old before they can be installed by default
• Opt-out: users can set min-release-age=0 in .npmrc to restore the previous behavior

📋 Compliance Alignment

• NIST Cybersecurity Framework (CSF) 2.0 — Emphasizes Supply Chain Risk Management (C-SCRM) as a core function
• CISA: Securing the Software Supply Chain — Official US government roadmap recommending proactive dependency vetting

🔗 References

• https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html
• https://zenn.dev/dely_jp/articles/supply-chain-kowai

[booniepepper]

LGTM, although for people/organizations with private repositories (or similar use cases), they'll need the ability to scope this value to specific registries

[sotanengel]

@booniepepper
Thanks for raising this — the security motivation makes sense!

Could you share what direction you’re considering for handling registry scoping? If there’s something specific I can help evaluate or test, I’d be happy to support.

[booniepepper]

I'm most familiar with private repositories in a corporate environment. Cloudsmith, GitHub packages, AWS CodeArtifact, etc

Generally the pattern I've seen is to use these for internal-only packages, either libraries specific to some internal details, or CLI tools specific to an organization's internal auth and opinionated tool stacks

[sotanengel]

@booniepepper
That matches my experience as well — private registries are usually used for internal libraries and tooling where immediate availability is often expected as part of the workflow!

Because of that, it might make sense to allow min-release-age to be configured per registry, rather than applying a single global default.

For example:

registry=https://registry.npmjs.org/
min-release-age=3

@internal:registry=https://npm.company.local/
min-release-age=0

Would this approach align with what you had in mind?