Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/preview/llms.txt
Full corpus: https://docs.registrystack.org/preview/llms-full.txt

# Security support window

> Which Registry Stack versions receive security fixes, how fixes are delivered, and what operators must do to stay covered.

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

## Supported versions

| Version line | Security fixes |
| --- | --- |
| Latest minor of the current stable major | All security fixes |
| Earlier minors of the current stable major | None; upgrade to the latest minor |
| Earlier major | Until the successor stable major is released, as described under [Major-line end of life](#major-line-end-of-life) |

Registry Stack uses a roll-forward security model.
Security fixes land on the current release line and ship in its latest minor or patch release.
Registry Stack does not promise backports to an earlier minor.

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

- Within a major line, upgrades are backward compatible per the
  [compatibility promise](../../reference/api-stability/), 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](../../operate/upgrade-and-rollback/) documents the upgrade and revert
  boundary. Stable release acceptance requires the procedure to pass against the exact candidate.

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.

## Major-line end of life

Registry Stack announces the end of support for a major line at least 90 days before the
successor stable major is released.
The announcement includes the exercised upgrade path.
The old major remains supported until the successor stable major is released, then security
maintenance moves to the successor's latest minor.

## How fixes are delivered

- A security fix ships as a release with signed artifacts and provenance, verifiable as
  documented in
  [SECURITY.md](https://github.com/registrystack/registry-stack/blob/v0.13.0/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](../../reference/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.

## Reporting and acknowledgment

Report suspected vulnerabilities privately through GitHub Security Advisories, as described
in [Report a vulnerability](../report-a-vulnerability/). Private reports are acknowledged
within 5 business days.

## Scope notes

- 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.

## Next

- [Report a vulnerability](../report-a-vulnerability/)
- [API stability and versioning](../../reference/api-stability/)
- [Upgrade and roll back a deployment](../../operate/upgrade-and-rollback/)