Third-party package dependencies · Release age & quarantine

Wait a minimum age before installing a new package version

When it fails: Package versions can be installed minutes after they are published. A compromised or malicious release is installed before the community or registry has had time to detect and remove it.

CB-DEP-AGE-001highdraftpartialprofile baseline

Status draft: not part of any release yet, may still change.

Description

A package version can only be resolved once it has been public for at least {{ min_release_age_hours }} hours. The rule applies to direct and transitive dependencies, on workstations, in pipelines and in automated update proposals. Older versions stay selectable.

Enforce the rule where it cannot be bypassed: in the registry proxy if possible, otherwise in the package manager configuration. A rule that only applies to update proposals does not protect against a developer adding a fresh release by hand, nor against transitive dependencies.

Rationale

Most malicious releases, including those pushed from hijacked maintainer accounts, are detected and removed within hours to a few days. A short quarantine turns most of these attacks into a non-event for the organization, at almost no cost.

Impact

New features and fixes arrive a few days later. Urgent security fixes need the exception process in CB-DEP-AGE-003. Some package managers resolve to an older version or fail when only a too-recent version satisfies the constraints.

Setting

Value
LocationRegistry proxy policy, or package manager configuration (see CB-DEP-SRC-006)
DefaultNo minimum age
RecommendedAt least {{ min_release_age_hours }} hours since publication

Parameters

ParameterBaselineHardenedBoundsDescription
min_release_age_hoursinteger48 hours72 hours24 to 720Minimum time between publication of a version and its first install.

The value used is your override, else the profile's, else the default. Bounds limit what an override may set.

Audit

  1. Find where the release-age rule is enforced (proxy, package manager, both).
  2. Check that the configured age is at least {{ min_release_age_hours }} hours and that it covers transitive dependencies.
  3. Try to install a version published less than {{ min_release_age_hours }} hours ago: it must be refused.

Automated: every check must pass. Scanners report each check by its id.

postmortem

release-age setting per package manager; --online: installed versions younger than the window

command: postmortem harden --json
control: CB-DEP-AGE-001
coverage: auto

Remediation

  1. Configure a minimum release age of {{ min_release_age_hours }} hours in the registry proxy, or in committed package manager configuration for each ecosystem.
  2. Apply the same delay to automated update proposals.

References

Mappings

FrameworkIDRelationNote
NIST SP 800-53 Rev. 55.1.1SR-3related
NIST SP 800-53 Rev. 55.1.1SR-11related

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

  • related CB-DEP-AGE-002 Wait a minimum age before adopting a new package
  • related CB-DEP-AGE-003 Grant release-age exceptions explicitly and for a limited time
  • related CB-DEP-UPD-001 Propose dependency updates automatically

People and lifecycle

AuthorsAlice
Introduced inv1.0.0
Created, updated2026-10-16, 2026-10-16