docs(security): address GTR review — rolling supported-versions policy, CODEOWNERS, SCA and CI links

Review feedback on the GTR questionnaire flagged two factual errors and a set
of unresolved markers that the repository can in fact answer.

The supported-versions table in SECURITY.md pinned concrete version numbers
and had drifted five minor releases behind the latest release. Restate it as a
rolling policy relative to the latest release so it cannot go stale, and cite
the Releases page as the authoritative list instead of repeating numbers in
prose.

The contributor-ladder answer referenced a top-level OWNERS file, which the
project does not have; promotions go through .github/CODEOWNERS for the
area-scoped Reviewer role and MAINTAINERS.md for the Maintainer roster.

Close the markers that repository evidence settles: e2e and CI workflow links,
the Renovate configuration, the organization-wide Trivy CVE-scanning pipeline
and its triage SLAs, and the real state of artifact signing, SBOM and SLSA
provenance. Replace the vague item count in the draft banner with the seven
substantive gaps that genuinely need measurement or a maintainer decision.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>

GENERAL_TECHNICAL_REVIEW.md

@@ -1,15 +1,19 @@
 # General Technical Review - Cozystack / Incubation
 
 - **Project:** Cozystack
-- **Project Version:** v1.x (current stable line; latest documented release v1.6 — see [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md) supported-versions table). `[maintainers: pin the exact release tag being submitted]`
+- **Project Version:** v1.x (current stable line). The authoritative list of releases is the [GitHub Releases page](https://github.com/cozystack/cozystack/releases); which release lines receive security fixes is defined in [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md). `[maintainers: pin the exact release tag being submitted]`
 - **Website:** https://cozystack.io
-- **Date Updated:** 2026-08-06
+- **Date Updated:** 2026-08-10
 - **Template Version:** v1.0
 - **Description:** Cozystack is a free, Apache-2.0 open-source platform and framework for building clouds. It turns a set of bare-metal servers into a system with a native Kubernetes REST API for spawning Kubernetes clusters, Databases-as-a-Service, virtual machines, load balancers, HTTP-caching and other services. It is a CNCF Sandbox project and a Certified Kubernetes distribution.
 
-> **Status: DRAFT — work in progress.** This questionnaire is being actively completed and reviewed; roughly seven items still require maintainer input (marked inline as `[maintainers: confirm]`) and version-specific links/tags should be pinned before it is treated as final. It is kept in-repo as a living document per the template guidance.
+> **Status: DRAFT — work in progress.** This questionnaire is being actively completed and reviewed. Everything that can be sourced from the repository has been answered and verified against it; the remaining `[maintainers: …]` markers are of two kinds, and only the first kind blocks submission.
 >
-> Notes for reviewers: answers cover **Day 0** and **Day 1** (required for Incubation, cumulative) plus **Day 2** where it already applies. Doc links are pinned to the versioned `/docs/v1.6/` tree; repo links are on `main` and should be pinned to the submitted tag before final submission. Items only the maintainers can quantify (formal load-test numbers, published SLOs, exact SBOM/SLSA status, security-team rotation policy) are marked `[maintainers: confirm]`.
+> **Substantive gaps — need measurement or a decision, cannot be sourced from the repo:** (1) load/scale test results and tested maximums (nodes, tenants, VMs, PVs) with methodology; (2) whether the project publishes reference SLOs/SLIs or treats them as adopter-defined; (3) measured baseline resource overhead of the platform components; (4) the upgrade→downgrade→upgrade CI matrix and its results; (5) whether platform upgrades trigger Talos node reboots; (6) the security-response-team rotation and diversity policy, which is not documented anywhere today; (7) how much of the organization-wide CVE-scanning pipeline is exposed for TOC review, given that the repository holding it is private by design.
+>
+> **Editorial markers** — the rest are requests to link an existing document or confirm a detail, and are resolved as the corresponding docs are located or written.
+>
+> Notes for reviewers: answers cover **Day 0** and **Day 1** (required for Incubation, cumulative) plus **Day 2** where it already applies. Doc links are pinned to the versioned `/docs/v1.6/` tree; repo links are on `main` and should be pinned to the submitted tag before final submission. Version numbers are deliberately not restated in prose where a canonical source exists — the [Releases page](https://github.com/cozystack/cozystack/releases) and [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md) are cited instead, so the document does not drift with each release.
 
 ---
 
@@ -17,7 +21,7 @@
 
 ### Scope
 
-* **Roadmap / scope / maintainer ladder.** Scope for mid-to-long-term features is managed in the open on the public [GitHub Project board](https://github.com/orgs/cozystack/projects/1), GitHub Issues/Discussions, the CNCF Slack `#cozystack` channel, Telegram, and the regular Cozystack community meetings. Roles and decision-making are defined in [GOVERNANCE.md](https://github.com/cozystack/cozystack/blob/main/GOVERNANCE.md): four roles — **Users, Contributors, Directors, Maintainers** — decide by consensus, falling back to a simple-majority vote (one vote per Maintainer and Director). The promotion path is defined in [CONTRIBUTOR_LADDER.md](https://github.com/cozystack/cozystack/blob/main/CONTRIBUTOR_LADDER.md): **Community Participant → Contributor → Reviewer → Maintainer**, with concrete criteria (Reviewer: ≥15 PRs/yr, ≥20 reviews, ≥6 months, two sponsors from different employers; Maintainer: ≥6 months as Reviewer, ≥10 h/month), promotions done via PRs to `OWNERS`/`MAINTAINERS.md`.
+* **Roadmap / scope / maintainer ladder.** Scope for mid-to-long-term features is managed in the open on the public [GitHub Project board](https://github.com/orgs/cozystack/projects/1), GitHub Issues/Discussions, the CNCF Slack `#cozystack` channel, Telegram, and the regular Cozystack community meetings. Roles and decision-making are defined in [GOVERNANCE.md](https://github.com/cozystack/cozystack/blob/main/GOVERNANCE.md): four roles — **Users, Contributors, Directors, Maintainers** — decide by consensus, falling back to a simple-majority vote (one vote per Maintainer and Director). The promotion path is defined in [CONTRIBUTOR_LADDER.md](https://github.com/cozystack/cozystack/blob/main/CONTRIBUTOR_LADDER.md): **Community Participant → Contributor → Reviewer → Maintainer**, with concrete criteria (Reviewer: ≥15 PRs/yr, ≥20 reviews, ≥6 months, two sponsors from different employers; Maintainer: ≥6 months as Reviewer, ≥10 h/month), promotions are done by pull request against the roster files in the repository root and `.github/`: [`.github/CODEOWNERS`](https://github.com/cozystack/cozystack/blob/main/.github/CODEOWNERS) records the area-scoped Reviewer role and gates merges on the matching paths, and [`MAINTAINERS.md`](https://github.com/cozystack/cozystack/blob/main/MAINTAINERS.md) records the project-wide Maintainer roster (Active and Emeritus sections). The two sets are deliberately different: a Reviewer owns a code area, a Maintainer is responsible for the whole project.
 * **Target personas.** (1) Platform/infrastructure engineers and SRE/DevOps teams building private or public clouds; (2) service providers / hosting companies / data centers offering IaaS, DBaaS and Managed-Kubernetes; (3) enterprises consolidating workloads on bare metal and seeking a self-hosted public-cloud alternative or a VMware replacement.
 * **Primary use case.** Turn bare-metal servers into a multi-tenant cloud exposing a Kubernetes-native REST API for self-service provisioning of tenant Kubernetes clusters, VMs, managed databases, load balancers and caching.
 * **Additional use cases.** Private/hybrid cloud; managed-services platform for providers; dev/test environments; AI-ready GPU infrastructure; on-prem VMware/vSphere replacement.
@@ -60,15 +64,15 @@
 
 * **Security self-assessment.** Cozystack has completed a **Security Self-Assessment** submitted with the Incubation application ([cncf/toc#1916](https://github.com/cncf/toc/issues/1916)), reviewed with TAG Security. `[maintainers: link the versioned SSA document in the repo / tag-security assessments]`
 * **Cloud Native Security Tenets.**
-  * *How satisfied:* secure-by-default (RBAC, per-tenant NetworkPolicies, isolated tenant API servers, immutable Talos nodes with no SSH/shell, minimal host attack surface); defense-in-depth via network segmentation (Cilium/Kube-OVN); automated TLS via **cert-manager**; secret management via **External Secrets Operator**/**OpenBao**; least-privilege service accounts for controllers; supply-chain hygiene via **CodeQL** and **OpenSSF Scorecard**.
+  * *How satisfied:* secure-by-default (RBAC, per-tenant NetworkPolicies, isolated tenant API servers, immutable Talos nodes with no SSH/shell, minimal host attack surface); defense-in-depth via network segmentation (Cilium/Kube-OVN); automated TLS via **cert-manager**; secret management via **External Secrets Operator**/**OpenBao**; least-privilege service accounts for controllers; supply-chain hygiene via **CodeQL**, **OpenSSF Scorecard** and organization-wide **Trivy** CVE scanning of dependencies and container images.
   * *Loosening defaults:* adopters can relax tenant isolation (shared/flat networking), disable specific NetworkPolicies, or grant broader RBAC for single-tenant/lab use. `[maintainers: link docs on loosening tenant-isolation/network-policy defaults]`
 * **Security Hygiene.**
-  * Practices ([SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md)): GitHub review with required approvals; CI on every PR; **CodeQL** static analysis on PRs and weekly (blocks merge on new error-severity alerts); **OpenSSF Scorecard** weekly (published at scorecard.dev); OpenSSF Best Practices badge; component versions pinned per release.
+  * Practices ([SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md)): GitHub review with required approvals; CI on every PR; **CodeQL** static analysis on PRs and weekly (blocks merge on new error-severity alerts); **OpenSSF Scorecard** weekly (published at scorecard.dev); OpenSSF Best Practices badge; organization-wide **Trivy** scanning of dependencies and container images on a 6-hour cycle for CRITICAL findings and weekly for the rest, with per-CVE triage tracked as issues (see Day 2 → Dependencies); **Renovate** for automated dependency updates; component versions pinned per release.
   * Unmaintained-feature risk: components are curated and version-pinned per release; the Helm-packaged, swappable building-block design makes replacing a risky/unmaintainable component tractable. `[maintainers: describe the formal process for retiring/replacing a risky component]`
 * **Cloud Native Threat Modeling.**
   * *Least privilege:* controllers run with scoped RBAC; elevated privileges are limited to and documented for infrastructure components that genuinely need them (KubeVirt/CDI for virtualization, Piraeus/LINSTOR for block devices, Cilium/Kube-OVN for CNI). `[maintainers: link a privileges/threat-model doc if published]`
   * *Certificate rotation:* automated via **cert-manager** (issuance/renewal/rotation) for platform TLS; Talos/Kubernetes-managed PKI for cluster components; tenant control-plane certs managed by **Kamaji**.
-  * *Secure software supply chain:* **in place today** — CodeQL SAST + OpenSSF Scorecard + pinned dependencies + private vulnerability reporting with defined CVSS response targets. **On the roadmap / not yet:** signed release artifacts (cosign), SBOMs, SLSA provenance. `[maintainers: confirm current signing/SBOM/SLSA status and link the supply-chain roadmap items on the GitHub Project board]`
+  * *Secure software supply chain:* **in place today** — CodeQL SAST (PRs + weekly, gating merges), OpenSSF Scorecard (weekly), continuous dependency and container-image CVE scanning with **Trivy** across the whole organization (see Day 2 → Dependencies → SCA), Renovate-managed dependency updates, component versions pinned per release, and private vulnerability reporting with defined CVSS response targets. **Not implemented today:** signed release artifacts (cosign) and SLSA provenance — neither is currently produced by any release workflow (`build-release`, `cut-prerelease`, `build-main`, `promote-rc`) and neither is yet tracked by an issue. SBOM generation is tracked as part of the CI image-build rework in [cozystack#2937](https://github.com/cozystack/cozystack/issues/2937), under the CI/build/release tracking issue [cozystack#3278](https://github.com/cozystack/cozystack/issues/3278).
 
 ---
 
@@ -82,12 +86,12 @@
 
 * **Enable/disable in a live cluster.** Cozystack is the distribution rather than an add-on toggled inside a foreign cluster, so "enablement" = installing the operator bundle on the management cluster. Individual bundles/components and each tenant application are enabled/removed independently (create/delete the corresponding resource); removing a tenant application affects only that tenant, with no downtime to unrelated workloads. `[maintainers: confirm whether any core component change requires control-plane restart]`
 * **How enablement changes default cluster behavior.** Installing Cozystack sets the CNI (Cilium/Kube-OVN), default StorageClass (LINSTOR), ingress, cert-manager, and the aggregated API as cluster defaults for subsequently created workloads. Cozystack expects to own the cluster, so a clean install does not disturb pre-existing unrelated workloads.
-* **Testing enablement/disablement.** CI installs Cozystack end-to-end in ephemeral environments and provisions/destroys sample tenants and applications to validate create→ready→delete flows. `[maintainers: link the e2e/CI workflow]`
+* **Testing enablement/disablement.** CI installs Cozystack end-to-end in ephemeral environments and provisions/destroys sample tenants and applications to validate create→ready→delete flows. Workflows: [`pull-requests.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/pull-requests.yaml) (per-PR checks), [`e2e-tag.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/e2e-tag.yaml) (tag/release e2e), [`nightly.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/nightly.yaml) (scheduled full run) and [`ui-test.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/ui-test.yaml) (dashboard). Test conventions are documented in [`docs/agents/e2e-testing.md`](https://github.com/cozystack/cozystack/blob/main/docs/agents/e2e-testing.md).
 * **Resource cleanup incl. CRDs.** Deleting an application resource triggers Flux/Helm to remove its HelmRelease and owned objects; finalizers ensure dependent resources (PVCs, VM disks, LB IPs) are released. `[maintainers: confirm CRD-cleanup behavior on full uninstall and any manual steps]`
 
 ### Rollout, Upgrade and Rollback Planning
 
-* **Compatibility with Kubernetes & frequency.** Cozystack ships a curated, tested Kubernetes version per release; tenant clusters are Certified Kubernetes following upstream skew/support. Platform upgrades are delivered as new Cozystack releases; supported versions are tracked in [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md) (currently the v1.x line, with security fixes for v1.0.x and critical-only for v0.41.x).
+* **Compatibility with Kubernetes & frequency.** Cozystack ships a curated, tested Kubernetes version per release; tenant clusters are Certified Kubernetes following upstream skew/support. Platform upgrades are delivered as new Cozystack releases. The authoritative list of what has shipped is the [GitHub Releases page](https://github.com/cozystack/cozystack/releases); which release lines are still receiving security fixes is defined as a rolling policy in [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md) (latest stable minor and the one before it are supported; older `v1.x` lines get critical fixes at maintainer discretion; `v0.x` is out of support). Specific version numbers are deliberately not restated here, because they drift with every release.
 * **Upgrade procedure** ([upgrade docs](https://cozystack.io/docs/v1.6/operations/cluster/upgrade/)): run the troubleshooting/health checklist; annotate the `cozy-system` namespace and `cozystack-version` ConfigMap with `helm.sh/resource-policy=keep`; `helm upgrade cozystack oci://ghcr.io/cozystack/cozystack/cozy-installer --version X.Y.Z` (**do not** use `--reuse-values` — the chart pins OCI repo/package versions); verify pods and `kubectl get hr -A`.
 * **Rollback.** GitOps/Helm-managed with versioned releases; roll back by targeting the previous release (previous HelmRelease revisions) via the same mechanism. Stateful data (databases, VM disks) persists on replicated storage across control-plane rollbacks. `[maintainers: confirm a documented rollback runbook / version-skip constraints]`
 * **How a rollout/rollback can fail & impact.** Risks: incompatible CRD schema change, storage/CNI component upgrades requiring Talos node reboots, or a database-operator major bump. Impact is scoped to the component; running tenant workloads generally continue, though storage/CNI upgrades can transiently affect networking or volume attachment during node rolls. `[maintainers: confirm whether upgrades trigger Talos node reboots]`
@@ -125,9 +129,9 @@
 ### Dependencies
 
 * **Running services depended on.** As listed in Day 0 → in-cluster service dependencies (full platform stack).
-* **Dependency lifecycle policy.** Component versions are pinned and shipped per Cozystack release; upgrades are curated and tested together and bumped as a single coordinated release. `[maintainers: link the policy/process for tracking upstream component versions, e.g. renovate config]`
-* **Source Composition Analysis (SCA).** Static analysis via **CodeQL** (PRs + weekly, gating merges) and supply-chain posture via **OpenSSF Scorecard** (weekly). `[maintainers: confirm any dependency/image SCA scanner (e.g. Trivy/Grype) and where results are tracked]`
-* **Acting on SCA & timescale.** Vulnerability response targets are defined in SECURITY.md (Critical ≈14 days, High ≈30 days, Medium ≈90 days, Low next release; acknowledgement ≤3 business days, triage ≤7). `[maintainers: confirm the same SLA applies to CVEs in bundled upstream components and how fixes ship]`
+* **Dependency lifecycle policy.** Component versions are pinned and shipped per Cozystack release; upgrades are curated and tested together and bumped as a single coordinated release. Automated dependency updates are managed by **Renovate**, configured in [`.github/renovate.json`](https://github.com/cozystack/cozystack/blob/main/.github/renovate.json), which raises PRs for Go modules, container images, Helm charts and GitHub Actions so upstream bumps surface as reviewable changes rather than manual sweeps.
+* **Source Composition Analysis (SCA).** Three layers. (1) **Static analysis** — **CodeQL** on every PR and weekly, gating merges on new error-severity alerts. (2) **Supply-chain posture** — **OpenSSF Scorecard** weekly, published on scorecard.dev, plus the OpenSSF Best Practices badge. (3) **Dependency and container-image CVE scanning** — an organization-wide pipeline built on **[Trivy](https://trivy.dev/)** runs against every non-fork, non-archived repository in the `cozystack` organization. It discovers components automatically (Go modules from `go.mod`, base images from Dockerfile `FROM` directives, and container images referenced by the Helm charts under `packages/apps/*`, `packages/system/*` and `packages/core/*`), then scans both repository filesystems and the resolved container images against NVD, vendor advisories and the GitHub Advisory Database. A new application or system component is picked up on the next scan with no manual registration. CRITICAL findings are scanned and reported every 6 hours; HIGH/MEDIUM/LOW are collected into a weekly report. Every new CVE becomes a tracked issue with severity labels, affected components, fix version and a triage checklist, and maintainer triage decisions are persisted so a settled finding is not re-reported. The pipeline and its reports live in the `cozystack/security-scanner` repository, which is **private by design**: it holds pre-disclosure vulnerability detail and triage decisions for shipped artifacts, so publishing it would amount to publishing an exploitation roadmap for adopters running the affected releases. `[maintainers: decide what to expose publicly for TOC review — options are read access for the reviewers, or publishing the pipeline policy documents (SECURITY_PIPELINE_POLICY.md, SECURITY_TRIAGE_MATRIX.md, SECURITY_FINDING_STATUS_MODEL.md) and the monthly aggregate report while keeping per-CVE detail private]`
+* **Acting on SCA & timescale.** Two tracks with distinct SLAs. **Reported vulnerabilities** (Cozystack-specific code, packaging, defaults, integration logic) follow [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md): acknowledgement ≤3 business days, initial triage ≤7 business days, remediation targets Critical ≈14 days, High ≈30 days, Medium ≈90 days, Low next release, under a coordinated-disclosure window of up to 90 days. **Scanner findings in bundled upstream components** are triaged on the scanner pipeline's own schedule — Critical triaged within 1 business day with a 7-day fix target, High within 3 business days / 30 days, Medium within 10 business days / 90 days, Low within 30 days on a best-effort basis. Triage follows an explicit decision tree (is the CVE in a shipped artifact rather than dev/test tooling; is the vulnerable path reachable in Cozystack's usage; has the distribution already backported the fix; is an upstream fix available) and resolves to one of `confirmed`, `false-positive`, `accepted-risk`, `in-progress` or `fixed`. Confirmed findings ship as an ordinary component version bump in the next Cozystack release, or as a patch release on a supported line when severity warrants it, since component versions are pinned per release and an upgrade is a single coordinated bump.
 
 ### Troubleshooting
 
@@ -151,7 +155,10 @@
 
 ### Appendix — sources
 - cozystack.io docs v1.6: [platform-stack](https://cozystack.io/docs/v1.6/guides/platform-stack/), [hardware-requirements](https://cozystack.io/docs/v1.6/install/hardware-requirements/), [install](https://cozystack.io/docs/v1.6/install/cozystack/), [upgrade](https://cozystack.io/docs/v1.6/operations/cluster/upgrade/), [monitoring](https://cozystack.io/docs/v1.6/operations/services/monitoring/), [troubleshooting](https://cozystack.io/docs/v1.6/operations/troubleshooting/), [OIDC](https://cozystack.io/docs/v1.6/operations/oidc/), [REST API](https://cozystack.io/docs/v1.6/cozystack-api/rest/).
-- Repo (main): [GOVERNANCE.md](https://github.com/cozystack/cozystack/blob/main/GOVERNANCE.md), [CONTRIBUTOR_LADDER.md](https://github.com/cozystack/cozystack/blob/main/CONTRIBUTOR_LADDER.md), [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md), [ADOPTERS.md](https://github.com/cozystack/cozystack/blob/main/ADOPTERS.md).
-- Roadmap: [GitHub Project board](https://github.com/orgs/cozystack/projects/1).
+- Repo (main): [GOVERNANCE.md](https://github.com/cozystack/cozystack/blob/main/GOVERNANCE.md), [CONTRIBUTOR_LADDER.md](https://github.com/cozystack/cozystack/blob/main/CONTRIBUTOR_LADDER.md), [MAINTAINERS.md](https://github.com/cozystack/cozystack/blob/main/MAINTAINERS.md), [.github/CODEOWNERS](https://github.com/cozystack/cozystack/blob/main/.github/CODEOWNERS), [SECURITY.md](https://github.com/cozystack/cozystack/blob/main/SECURITY.md), [ADOPTERS.md](https://github.com/cozystack/cozystack/blob/main/ADOPTERS.md).
+- Releases: [GitHub Releases](https://github.com/cozystack/cozystack/releases).
+- CI / security workflows: [pull-requests.yaml](https://github.com/cozystack/cozystack/blob/main/.github/workflows/pull-requests.yaml), [e2e-tag.yaml](https://github.com/cozystack/cozystack/blob/main/.github/workflows/e2e-tag.yaml), [nightly.yaml](https://github.com/cozystack/cozystack/blob/main/.github/workflows/nightly.yaml), [ui-test.yaml](https://github.com/cozystack/cozystack/blob/main/.github/workflows/ui-test.yaml), [codeql.yml](https://github.com/cozystack/cozystack/blob/main/.github/workflows/codeql.yml), [scorecard.yml](https://github.com/cozystack/cozystack/blob/main/.github/workflows/scorecard.yml), [renovate.json](https://github.com/cozystack/cozystack/blob/main/.github/renovate.json).
+- Roadmap: [GitHub Project board](https://github.com/orgs/cozystack/projects/1); supply-chain items [cozystack#2937](https://github.com/cozystack/cozystack/issues/2937), [cozystack#3278](https://github.com/cozystack/cozystack/issues/3278).
+- SCA tooling: [Trivy](https://trivy.dev/) (organization-wide CVE scanning pipeline; the repository hosting it is private, see Day 2 → Dependencies).
 - SSA / Incubation: [cncf/toc#1916](https://github.com/cncf/toc/issues/1916).
 - GTR template: cncf/toc `toc_subprojects/project-reviews-subproject/general-technical-questions.md` v1.0.

SECURITY.md

@@ -8,19 +8,19 @@ Cozystack integrates and ships many upstream cloud native components. If you bel
 
 ## Supported Versions
 
-As of March 17, 2026, the Cozystack project maintains multiple release lines. Security fixes are prioritized for the latest stable release line and, when needed, backported to other supported lines.
+The Cozystack project maintains multiple release lines at once. Support is expressed below as a **rolling policy relative to the latest release** rather than as a list of version numbers, so that this table does not go stale between releases. To find which concrete lines the policy currently points at, read it against the GitHub Releases page:
+
+<https://github.com/cozystack/cozystack/releases>
 
 | Version line | Status | Notes |
 | --- | --- | --- |
-| `v1.1.x` | Supported | Current stable release line. |
-| `v1.0.x` | Supported | Previous stable release line; receives security and important maintenance fixes. |
-| `v0.41.x` | Limited support | Legacy pre-v1 line during the v0 to v1 transition; critical security and upgrade-blocking fixes may be backported at maintainer discretion. |
-| `< v0.41` | Not supported | Please upgrade to a supported release line before requesting a security fix. |
+| Latest stable minor (`vX.Y.x`) | Supported | Current stable release line. Security fixes land here first, and patch releases are cut from it. |
+| Previous stable minor (`vX.(Y-1).x`) | Supported | Receives security and important maintenance fixes, backported from the current line. |
+| Older `v1.x` minors | Limited support | Critical security and upgrade-blocking fixes may be backported at maintainer discretion. Adopters are expected to move to a supported line. |
+| `v0.x` (including `v0.41.x`) | Not supported | Pre-v1 lines from the v0 to v1 transition. Please upgrade to a supported release line before requesting a security fix. |
 | `alpha`, `beta`, `rc` releases | Not supported | Pre-release builds are for testing and evaluation only. |
 
-Supported versions may change over time as new release lines are cut. The authoritative source for current releases is the GitHub Releases page:
-
-<https://github.com/cozystack/cozystack/releases>
+Reporting a vulnerability against an unsupported line is still welcome: we will confirm whether the issue also affects a supported line and fix it there.
 
 ## Reporting a Vulnerability