mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-30 08:37:31 +09:00
Andrei Kvapil
eef95f456d
## What this PR does Adds the CNCF General Technical Review (GTR) questionnaire for Cozystack, completed for the Sandbox → Incubation Due Diligence (tracks cncf/toc#1916). It answers the Day 0 / Day 1 / Day 2 questions from the CNCF TOC project-reviews template, with versioned links to the v1.6 documentation and to the repo's governance and security files. **Status: DRAFT / work in progress.** The questionnaire itself is a living document per the template's guidance. Everything repository evidence settles has been answered and verified against the tree; the banner at the top of the file names the seven substantive gaps that need measurement, publication or a maintainer decision — load/scale results and tested maximums, published SLOs/SLIs, measured platform baseline overhead, the upgrade→downgrade CI matrix, whether upgrades trigger Talos node reboots, the security-team rotation and diversity policy, and publication of the CVE-scanning pipeline's policy documents. Version-specific links should be pinned to the submitted tag before final submission. ## Changes beyond the new file — please read this part Review feedback found two factual errors that originate **outside** this questionnaire, so fixing them only in the GTR would have left a reviewer clicking through to the contradiction. Three existing files are therefore touched: - **`SECURITY.md` — supported-versions table. This is a policy change and needs a policy review, not a wording check.** The table was dated "As of March 17, 2026" and named `v1.1.x` as the current stable line, five minors behind `v1.6.1`. It is rewritten to be keyed to **observable patch activity on a line** — supported means a patch release within the last 6 months, limited support 6 to 18 months, end of life beyond that — so an adopter can determine their own status from the Releases page and the table cannot drift again. Two intermediate versions of this PR got the policy wrong in opposite directions and both are reverted: one narrowed support to the latest two minors, which contradicts practice since several `1.x` lines receive patch releases concurrently; the other removed the end-of-life category altogether and extended discretionary backports across all of `0.x`. What lands here restores an end-of-life category, puts the `v0.41` cutoff back with its last-patch date, and states explicitly that the six- and eighteen-month marks describe current behaviour rather than committing the project to patch any line for that long. `@kvaps`, as a CODEOWNER for this file: please review the **policy**. If the project would rather state a guaranteed backport window, or keep support entirely at maintainer discretion with no stated marks, that is a governance decision and this PR deliberately does not make it. - **`SECURITY.md` — automated security analysis.** It said "two scanners run continuously" and listed CodeQL and Scorecard. It now also describes `zizmor` (GitHub Actions SAST, gating on PRs), the organization-wide Trivy CVE-scanning pipeline, and Renovate's actual coverage. It also records that CodeQL is **not** currently among the required status checks on `main` — those are `pre-commit` and `E2E Tests` — so the CodeQL gate is review convention rather than branch protection today. - **`CONTRIBUTOR_LADDER.md`** — Reviewer nomination described adding a username to an `OWNERS` file. No `OWNERS` file exists in this repository; line 158 of the same document already refers to `CODEOWNERS`. Corrected to name the files that exist. This does not change the process. - **`docs/security/self-assessment.md`** — brought in step with the above on the same three points (CodeQL's gate status, the Trivy pipeline and its limitations, Renovate's real coverage), so the GTR, `SECURITY.md` and the self-assessment agree rather than contradict each other in front of the TOC. ## Two things for `@kvaps` to decide, not to approve as wording 1. **Which release lines are supported — and the evidence points two ways.** The six-month activity test in the rewritten table classifies every `1.x` line from `1.0` to `1.6` as supported, because each has had a patch release inside six months (`v1.1.7` as recently as 2026-06-03, `v1.0.7` on 2026-03-30). But *recent* activity looks like three lines, not seven: of the sixteen most recent backport branches, fifteen target `release-1.4`, `release-1.5` or `release-1.6`, and only `1.4`, `1.5` and `1.6` have shipped a release since 2026-07-03. Older backport branches for `release-1.2` and `release-1.3` exist but are months old — and since branches are never deleted, their existence proves nothing about the present, which is the same trap the table's own lead-in now warns about. So the concrete question is: **is the intended set `1.4`/`1.5`/`1.6` supported with `1.0`–`1.3` on limited support, or is it genuinely all seven?** If a critical fix would today be backported to `v1.1`, the wide table is right. If it would not, the six-month window is the wrong instrument and should be shortened. I have deliberately not chosen — either answer is defensible and it is a maintainer call, not a documentation one. **A third file turns on the same answer.** [`docs/security/incident-response.md`](https://github.com/cozystack/cozystack/blob/main/docs/security/incident-response.md) step 5 says a fix ships "across all affected supported release lines", pointing at the `SECURITY.md` table — so widening that table to seven lines widens this commitment with it. This PR does not touch that file and does not assert the claim, but the two should move together: if the answer is "all seven", incident response is right and `SECURITY.md` should stop hedging; if it is "1.4–1.6", the table, the window and that sentence all change at once. 2. **Whether there is a backport rule at all.** No project document, public or private, describes how a fix is chosen for backporting to a given supported line. An intermediate version of this PR asserted one (by severity, default-config reachability and adopter count); that was invented and has been removed. The file now says the decision is taken per fix and the rule is not documented. If a rule exists informally, writing it down would answer a question the seven-supported-lines table otherwise raises. ## Gaps this documents rather than fixes Recorded here because they surfaced while verifying the questionnaire's claims and each is a real finding: - CodeQL is not a required status check, though two documents described it as gating merges. - There is no top-level `NOTICE` file, for a distribution bundling on the order of fifty upstream components. - No default Kubernetes audit policy is shipped; audit logging is opt-in with the policy left to the adopter. - Release artifacts are not signed and no issue tracks adding signing; build provenance is explicitly disabled (`--provenance=false`); SBOM generation is implemented but defaulted off. - The CVE-scanning pipeline lives in a repository that returns 404 to non-members. Its aggregate reporting is now published (below); its policy documents and scanning scripts, which hold no finding data, are not, so the method behind the numbers is still not independently auditable. - `nightly.yaml` has been failing since 2026-08-02 and `e2e-tag.yaml` failed around the v1.6.1 release; current CI health is disclosed next to the workflow links. ## New: published security reporting, and a backlog audit that changes the SCA answer `docs/security/reports/` now holds monthly vulnerability-handling reports plus a [backlog reconciliation](https://github.com/cozystack/cozystack/blob/main/docs/security/reports/reconciliation-2026-08.md). The reconciliation exists because the CVE-scanning pipeline has no write-back from this repository, so it has never marked a finding as fixed and its counts were misleading in both directions. Audited against what actually shipped: - Remediation did happen — a clear majority of confirmed findings relate to a component whose in-tree version now carries the fix — but as **one wave in June 2026**, not a steady stream. The changes that did most of the work name no CVE at all: re-vendoring the dashboard console removed the vulnerable npm dependencies rather than upgrading them; refreshing the Alpine bases cleared fourteen; bringing the Go toolchain current satisfies all 62 `stdlib` findings. - **57% of the backlog was never applicable or cannot be assessed.** The largest block is packages containing no executable vulnerable code — chiefly kernel headers, since a container never provides a running kernel, which is the same reasoning the maintainers already applied 80 times to `kernel-headers` and never to `linux-libc-dev`. Reachable exposure in a stock install is an estimated 2–5% of the tracker. - **Four component bumps are available upstream and not taken**: `nats-server`, the CoreDNS image, OpenBao, `fast-uri`. - Seven defects in the pipeline itself, with a write-back specification to fix the root cause. Two issues counted as findings are actually quarterly-review tracking tasks. The disclosure rule moved in the open direction: findings with no upstream fix will be named with mitigation guidance, because under the previous rule that class — a fifth of the backlog — stayed secret permanently, and it is exactly where an adopter needs to know a mitigation is the only control. Conversely, remediation is no longer attributed to individual months, because crossing a count of still-open findings with one month's publicly enumerable component bumps narrows the search for unpatched exposure more than a bare count does. Several findings warrant maintainer attention ahead of the backlog and are being raised privately rather than named here. ### Downstream repositories - [x] No downstream repository is affected by this change (docs-only; no code, API, manifest or packaging changes). ### Release note ```release-note docs: add CNCF General Technical Review (GTR) questionnaire for the Sandbox → Incubation review ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added a comprehensive technical review covering planning, installation, operations, architecture, security, and troubleshooting. - Added April–August 2026 security reports and a complete CVE backlog reconciliation. - Expanded security self-assessment, scanning coverage, reporting guidance, disclosure rules, and audit limitations. - Clarified supported-version policies, release backport decisions, and private vulnerability-reporting procedures. - **Process Updates** - Updated reviewer nomination requirements to use current ownership and maintainer records. - Clarified severity- and risk-based backport decisions for coordinated security releases. <!-- end of auto-generated comment: release notes by coderabbit.ai -->