Skip to content
Registry StackDocsLatest

Security support window

View as Markdown

This page states which Registry Stack versions receive security fixes and how those fixes reach a deployment. It complements the vulnerability reporting process, which covers how to report, what is in scope, and how reports are acknowledged.

Version lineSecurity fixes
Latest release line (highest released minor of the highest major)All security fixes
Earlier releasesNone

Registry Stack’s roll-forward model is a draft policy (GH#203): security fixes land on main and ship in the next release of the latest line, with no long-term support branches and no backports to earlier minor lines.

The rest of the lifecycle policy is designed to make rolling forward cheap:

  • Within a major line, upgrades are backward compatible per the draft compatibility promise, so moving to the fixed release does not require migration work beyond reading the release notes.
  • Patch releases contain fixes only, so a security patch is a minimal, low-risk step.
  • The upgrade procedure is documented and exercised, including the revert path if a fixed release misbehaves in your environment.

What this means for an institution: plan to apply patch releases of your deployed line promptly. A deployment pinned to an old minor does not receive fixes in place; the fix is always in a newer release.

  • A security fix ships as a release with signed artifacts and provenance, verifiable as documented in SECURITY.md.
  • Release notes identify security-relevant changes. When a fix required tightening covered surface, the notes say so explicitly, per the security exception in the deprecation policy.
  • Dependency advisories are enforced through cargo deny check in the CI rust job, which runs on every push that touches Rust code (the job is path-filtered). An advisory without an upstream fix carries a scoped, documented ignore in deny.toml with a review trigger; a newly published advisory fails CI until it is fixed or receives its own documented ignore.

Report suspected vulnerabilities privately through GitHub Security Advisories, as described in Report a vulnerability. Private reports are acknowledged within 5 business days.

  • This policy is stack-wide. This page supersedes the narrower statement in products/manifest/SECURITY.md that security fixes target the current main branch.
  • Pre-1.0 releases (v0.x) are technical releases for evaluation and pilots. They receive fixes only in the latest v0.x release, under the same roll-forward model.