Safe-version delivery

A virtual npm repository can hide versions that are known to be vulnerable, so a dependency range resolves to the next clean release without the developer changing anything. It is off by default.

Enable it

Per virtual repository, with a level:

Mode	Redirect allowed
off	never (default — packuments are served unchanged)
patch	to a clean version with the same major.minor
minor	to a clean version with the same major

Set it in the repository's detail page (safe-version card) or via PUT /api/admin/repos/{id}/safe-version with {"mode": "patch"}. Only virtual repositories accept a policy.

What changes

For GET /npm/<project>/<repo>/<package> on a virtual repo with the policy on:

• Versions that an advisory definitely affects are removed from versions, so ^1.2.0 with a vulnerable 1.2.3 and a clean 1.2.4 installs 1.2.4.
• dist-tags that pointed at a removed version move to its clean successor.
• A version is removed only if a clean replacement exists inside the configured level; otherwise the packument is left as is.
• The response carries X-OrbitalReg-Remediated-From: 1.2.3->1.2.4 and an audit event safe_version.remediate is written per response.

What never changes

An exact request for a blocked tarball is never rewritten. Pinning 1.2.3 still returns 403 with the hint from the block page, because silently serving different bytes than the lockfile names would break reproducibility and integrity checks.

PyPI and Maven virtual repositories apply the same rule: the PyPI simple index and Maven maven-metadata.xml leave out the affected versions (item 408). The filter also applies to the upstream index a virtual repository serves from a remote member. Upstream is only used when no local member holds the package (dependency-confusion rule).