@@ -1,3 +1,11 @@
+# This file encodes the area-scoped Reviewer role from the Contributor Ladder
+# (CONTRIBUTOR_LADDER.md): the handles below have review authority over the
+# matching paths. This is intentionally a different set from the governance
+# roster in MAINTAINERS.md — a Reviewer owns a specific code area, while a
+# Maintainer is responsible for the whole project. The two overlap but are not
+# identical by design. Security reports are NOT routed through this file; see
+# SECURITY.md (GitHub Private Vulnerability Reporting + MAINTAINERS.md).
+
 * @kvaps @lllamnyp @lexfrei @androndo @IvanHunters @sircthulhu @myasnikovdaniil
 
 # The API review gate must not be editable without an API-owner review, or a
 
@@ -87,7 +87,7 @@ jobs:
       # isolated buildkit so it never contends with PR builds on the shared one.
       - name: Set up Buildx (docker-container driver)
         id: buildx
-        uses: docker/setup-buildx-action@8d2750c68a42422c14e847fe6c8ac0403b4cbd6f # v3.12.0
+        uses: docker/setup-buildx-action@8d2750c68a42422c14e847fe6c8ac0403b4cbd6f # v3
         with:
           driver: docker-container
         env:
 
@@ -93,3 +93,4 @@ packages/core/platform/.build-revision
 examples/backups/*/.bucket-info.env
 examples/backups/*/.sentinel.env
 examples/backups/*/.backup-name.env
+packages/core/platform/images/migrations/etcd-operator-crds/
@@ -26,10 +26,11 @@ Supported versions may change over time as new release lines are cut. The author
 
 Please do **not** report security vulnerabilities through public GitHub issues, discussions, pull requests, Telegram, Slack, or other public community channels.
 
-At the moment, this repository does not publish a dedicated private security mailbox in-tree. If you need to report a vulnerability:
+Please report vulnerabilities privately through one of the following channels, in order of preference:
 
-1. Contact one of the project maintainers listed in `CODEOWNERS` using an existing private channel you already have.
-2. If you do not already have a private maintainer contact, use a public community channel only to request a private contact path, without disclosing any vulnerability details.
+1. **GitHub Private Vulnerability Reporting** — the preferred channel. Open the repository's **Security** tab, then **Advisories** → **Report a vulnerability** (<https://github.com/cozystack/cozystack/security/advisories/new>). This creates a confidential advisory visible only to you and the maintainers, and is the CNCF-recommended path for coordinated disclosure.
+2. **Contact a maintainer** listed in [`MAINTAINERS.md`](MAINTAINERS.md) through an existing private channel you already have.
+3. If you have neither, use a public community channel only to request a private contact path, without disclosing any vulnerability details.
 
 Please do not include exploit details, credentials, tokens, private keys, customer data, or other sensitive material in any public message.
 
@@ -54,6 +55,21 @@ The maintainers will aim to:
 
 Resolution timelines depend on severity, complexity, release branch applicability, and whether coordination with upstream projects is required.
 
+### Disclosure timeline
+
+The project follows a coordinated-disclosure window of **up to 90 days** from acknowledgement. If a fix or mitigation is not available within that window, the maintainers may publish the advisory (via GitHub Security Advisories) with the available details and any known workarounds, so that users are not left uninformed indefinitely. The window may be extended only by mutual agreement with the reporter, typically for issues that require coordination with upstream projects.
+
+Target remediation timelines are guided by CVSS v3.1 severity:
+
+| Severity (CVSS v3.1) | Target time to fix or mitigation |
+| --- | --- |
+| Critical (9.0–10.0) | ~14 days |
+| High (7.0–8.9) | ~30 days |
+| Medium (4.0–6.9) | ~90 days |
+| Low (0.1–3.9) | next scheduled release |
+
+These are targets, not guarantees; complex or upstream-coordinated issues may take longer.
+
 ## Disclosure Process
 
 The Cozystack project follows a coordinated disclosure model.
 
@@ -29,16 +29,16 @@ const (
 // +kubebuilder:resource:scope=Cluster
 
 // Etcd defines a backup strategy that delegates execution to the
-// etcd-operator (etcd.aenix.io). The strategy carries a templated backup
-// destination configuration; the driver materialises one
-// etcd.aenix.io/v1alpha1 EtcdBackup per Cozystack BackupJob and surfaces
+// etcd-operator (etcd-operator.cozystack.io). The strategy carries a templated
+// backup destination configuration; the driver materialises one
+// etcd-operator.cozystack.io/v1alpha2 EtcdSnapshot per Cozystack BackupJob and surfaces
 // it as a Cozystack Backup artefact.
 //
 // Restore is in-place only: the driver suspends the source Etcd
 // HelmRelease, snapshots the live EtcdCluster spec, deletes it, and
 // re-creates the EtcdCluster with spec.bootstrap.restore.source
 // pointing at the Backup's S3 coordinates, then resumes the HR after
-// the cluster reaches Ready.
+// the cluster becomes Available.
 //
 // To-copy restore is NOT supported: RestoreJob.spec.targetApplicationRef
 // is a TypedLocalObjectReference (no namespace field), so there is no
@@ -68,7 +68,7 @@ type EtcdList struct {
 
 // EtcdSpec specifies the desired etcd-operator-driven backup strategy.
 type EtcdSpec struct {
-	// Template carries the templated EtcdBackup destination configuration
+	// Template carries the templated EtcdSnapshot destination configuration
 	// applied per BackupJob (and re-rendered against the same
 	// .Application / .Parameters at restore time). String fields support
 	// Helm-style Go templating with two top-level values:
@@ -80,19 +80,19 @@ type EtcdSpec struct {
 	Template EtcdTemplate `json:"template"`
 }
 
-// EtcdTemplate describes the templated EtcdBackup-shaped configuration the
+// EtcdTemplate describes the templated EtcdSnapshot-shaped configuration the
 // driver renders per BackupJob (and on the restore path stamps onto
 // EtcdCluster.spec.bootstrap.restore.source).
 type EtcdTemplate struct {
 	// Destination defines where the etcd snapshot will be stored. Field
-	// semantics mirror etcd.aenix.io/v1alpha1 EtcdBackup.spec.destination.
+	// semantics mirror etcd-operator.cozystack.io/v1alpha2 EtcdSnapshot.spec.destination.
 	Destination EtcdDestinationTemplate `json:"destination"`
 }
 
-// EtcdDestinationTemplate mirrors etcd.aenix.io/v1alpha1
-// EtcdBackup.spec.destination, RESTRICTED to S3.
+// EtcdDestinationTemplate mirrors etcd-operator.cozystack.io/v1alpha2
+// EtcdSnapshot.spec.destination, RESTRICTED to S3.
 //
-// The upstream etcd-operator EtcdBackup.spec.destination accepts either
+// The upstream etcd-operator EtcdSnapshot.spec.destination accepts either
 // S3 or PVC, but the operator's filename convention is asymmetric
 // between backup and restore on the PVC path:
 //
@@ -118,7 +118,7 @@ type EtcdDestinationTemplate struct {
 }
 
 // EtcdS3Template is a typed, kubebuilder-validated mirror of
-// etcd.aenix.io/v1alpha1 EtcdBackup.spec.destination.s3. Restores reuse
+// etcd-operator.cozystack.io/v1alpha2 EtcdSnapshot.spec.destination.s3. Restores reuse
 // the same shape: the driver re-renders the strategy and stamps the
 // resulting block onto EtcdCluster.spec.bootstrap.restore.source.s3 of the
 // target Etcd application.