docs: add CNCF General Technical Review (GTR) questionnaire - #3572

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Thanks IvanHunters — both factual items were real, and the pre-verified marker triage saved a lot of time. Addressed across six commits, be8c6e5 through c1da673. One item of yours is a correction rather than a fix, and the second commit walks back some of the first, because an internal pass found that my initial round overstated several controls. Details below, since a few of them change the project's posture rather than just its prose.

1. Supported-versions drift — fixed, then fixed again

You were right on both halves: the SECURITY.md table was five minors behind (it called v1.1.x the current stable line while v1.6.1 had shipped), and the GTR line restating it dropped v1.1.x on top of that.

My first attempt restated the table as a rolling window — latest stable minor plus the previous one — so it could not go stale again. That was wrong in a way worth recording: it quietly narrowed the project's support commitment. The release record shows several 1.x lines receiving patch releases concurrently (v1.4.5 shipped 2026-07-03 the same day as v1.5.2, v1.1.7 shipped 2026-06-03 while v1.4.x was current, and backport branches exist for release-1.2 through release-1.5). A latest-plus-one window would have told adopters on 1.3 and 1.4 that they were on discretionary support while they were in fact being patched.

It took two more attempts to land. A second version keyed support to having an active release branch, which is no test at all — branches are never deleted, so every line back to release-0.1.0 still has one — and in removing the fixed window it also removed the end-of-life category entirely and extended discretionary backports across all of 0.x. What is in the branch now keys support to observable patch activity: a patch release within the last 6 months is supported, 6 to 18 months is limited support, beyond that is end of life, v0.41.x is end of life with its last-patch date stated, and everything before v0.41 is unsupported. An adopter can determine their own status from the Releases page without insider knowledge, and the table says outright that the marks describe current behaviour rather than committing the project to patch any line for that long.

Two things worth flagging in that table. Applied today it classifies every 1.x line from 1.0 to 1.6 as supported, because each has had a patch release inside six months — so the lower tiers are forward-looking rather than describing anything. And recent activity points the other way: of the sixteen most recent backport branches, fifteen target 1.4, 1.5 or 1.6, and only those three lines have released since 2026-07-03. Whether the intended set is seven lines or three is in the PR body as a decision, with the evidence for both readings.

Andrei Kvapil (@kvaps) — you are a CODEOWNER for SECURITY.md and there are two decisions here for you, not wording checks. First, the supported set above. Second: an intermediate version of this branch asserted a backport prioritisation rule — by severity, by reachability in a default configuration, and by adopter count, with a critical fix reaching every supported line. I made that up. No such rule exists in any project document, public or private; reachability appears only as a triage question and adopter count appears nowhere. It is removed, and SECURITY.md now says only that backporting is decided per fix and the rule is not documented. If a rule exists informally, writing it down would answer the question the seven-supported-lines table otherwise raises — and docs/security/incident-response.md step 5 already promises fixes ship "across all affected supported release lines", which turns on the same answer.

The GTR now cites the Releases page plus SECURITY.md in both places it previously hardcoded versions, exactly as you suggested.

2. OWNERS — fixed at the source, not relocated

Correct, there is no top-level OWNERS. The GTR answer now distinguishes the two rosters properly: .github/CODEOWNERS carries the area-scoped Reviewer role and gates merges on matching paths, MAINTAINERS.md carries the named roster in its three sections (Active, Reviewers, Emeritus).

But the GTR had inherited that phantom file from CONTRIBUTOR_LADDER.md line 94, which still described Reviewer nomination as a PR "which adds their GitHub username to the OWNERS file for one or more directories" — while line 158 of the same document already refers to CODEOWNERS. Fixing only the questionnaire would have meant a reviewer clicking the cited source and landing on the same error. So the ladder is fixed here too, as a factual correction naming the files that exist. It is a one-line change and it does not alter the process, but flagging it since it touches a governance document.

3. Markers closed with repository evidence

All three of yours, plus four more the tree settles:

• Signing / SBOM / SLSA. Your reading was right and my first version was still imprecise. Restated from the build tooling rather than from issue titles: hack/common-envs.mk sets --provenance=false in BUILDX_ARGS, so provenance is not merely absent but explicitly disabled, and SBOM generation is implemented and switchable (SBOM=1 → --sbom=true, CycloneDX buildx attestation) but defaulted off pending a registry referrers/attestation check. Signing genuinely does not exist — no cosign or sigstore anywhere, and no issue tracking it, which the document now says outright. The distinction matters for DD: two of the three are configuration-and-verification work, one is greenfield.
• e2e / CI workflows. Linked, plus the conventions doc.
• Renovate. Linked — and materially corrected, see below.
• Security self-assessment, threat model, incident response. All three are in-tree at docs/security/; those markers are closed with paths.
• Default audit policy. None is shipped — there is no audit-policy manifest in any package. Now stated as opt-in with the reference policy left to the adopter, and enabling it by default flagged as an improvement.
• Third-party NOTICE. There is no top-level NOTICE file. For a distribution bundling on the order of fifty upstream components that is a genuine compliance gap, so it is written up as one rather than deferred to a marker.

4. Dependency SCA — this is the one correction

There is a dependency and container-image SCA scanner, built on Trivy. It does not live in this repository, which is why searching here turns up only CodeQL and Scorecard. It runs organization-wide against every non-fork, non-archived repo in the cozystack org: discovery reads Go modules, Dockerfile FROM directives and chart image references, then Trivy scans both repository filesystems and the resolved images against NVD, vendor advisories and GHSA. CRITICAL every 6 hours, everything else weekly, with each actionable finding tracked as an issue under a documented triage matrix and persisted triage decisions. It also closes your separate marker about whether the SECURITY.md SLA covers CVEs in bundled upstream components — it does not; that is a distinct track with a tighter triage clock, and confirmed findings ship as a pinned-component bump or a patch release on an actively patched line.

SECURITY.md now describes this pipeline, Renovate, and zizmor — the last of which was missing from every document and is a third gating scanner (it audits the workflow definitions on PRs and fails on unpinned actions and over-broad permissions). The "two scanners run continuously" line is now four controls. The self-assessment got the same treatment, so the three documents agree instead of contradicting each other.

Three things I want to put on the record rather than let a reviewer discover:

The pipeline is not externally verifiable today, and that is a real problem. cozystack/security-scanner returns 404 to anyone outside the org. My first draft justified that as "private by design" covering the whole repository; that was overbroad and read as spin. Only the per-CVE reports and the triage-state files actually need embargo — they describe unfixed exposure in released artifacts. The pipeline policy, the triage matrix, the finding status model and the scripts contain no vulnerability data, and they are the part that actually evidences the control. I also initially listed the monthly aggregate summaries as safe to publish; that was wrong, and I checked before saying so — the latest one names accepted-risk findings individually by CVE ID, severity and package, several of them CRITICAL, next to a count of confirmed findings awaiting a fix, under a header calling itself a public summary. So the document now states the rule rather than a conclusion: aggregate counts by severity are publishable, naming an individual not-yet-fixed finding is not, because a CVE ID plus a package plus this project's public pinned component list locates unpatched exposure in a running deployment. By that test the four policy and script artifacts are publishable as they stand and the monthly summary is publishable once its table is reduced to counts. Publication has to happen before submission rather than be promised inside it, it is a maintainer action, and I have not taken it.

The SLAs are documented targets and the project is not currently meeting them, on both tracks. Detection keeps up. Triage does not, and the backlog awaiting a decision includes findings at critical severity open well beyond the one-business-day target. Remediation is further behind still — the most recent monthly period closed with no confirmed findings fixed against a three-figure backlog of confirmed findings awaiting one. The rotating role that owns both clocks is defined but unfilled, which is the likeliest single cause. The document says all of that. What it deliberately does not contain is the figures: a count of unreviewed or unfixed criticals in shipped artifacts, sitting next to a public pinned-component list, is a targeting hint with no compensating benefit to a reader. They go to the TOC through the private channel with a remediation plan, which is what TAG Security asks for anyway.

Renovate covers less than "Renovate-managed" implies. enabledManagers is gomod, dockerfile, github-actions, custom.regex; the helm-values manager is disabled repo-wide, because many image refs are assembled at render time by the cozy-lib.image helper rather than written literally in values.yaml. So the curated component images that make up the shipped platform are bumped by maintainers when preparing a release, not by a bot. The same blind spot limits values-file-based discovery in the scanner, and that limitation is now disclosed in both the GTR and the self-assessment.

5. CodeQL does not gate merges, and the document said it did

Not from your review — this came out of internal verification, and it was in my first commit as well as in the original. GET /branches/main/protection returns required checks ["pre-commit", "E2E Tests"]. CodeQL is not among them. SECURITY.md and the self-assessment both hedged correctly ("intended as a required check"), while the GTR asserted "blocks merge" and "gating merges" as fact — in a document that sits next to the self-assessment in the TOC's reading pile. All three assertions are gone; the questionnaire now names the two actual required checks and says the CodeQL gate is review convention pending promotion.

Related, and also volunteered rather than waiting to be found: the scheduled nightly.yaml run is flapping, not newly broken. Counting only scheduled runs, the first one after the fix in #3332 still failed, then three passed, five failed, three passed ending 2026-08-01, and every run since 2026-08-02 has failed — six of the last twenty-four passed. e2e-tag.yaml also failed around the v1.6.1 release. The GTR carries that next to the workflow links, notes that gating coverage rests on the per-PR job today, and says the current failure is not yet triaged to an issue — #3278 covers the earlier never-completing failure, not this one.

6. Items that genuinely need maintainer input

Kept as markers, and the banner no longer hides behind "roughly seven items" — it names them. One of your framings needed correcting, though: I had written that the security-team rotation policy "is not documented anywhere today". That is too strong. A rotating Security Champion role with a 6-month term and a handoff overlap is defined, in the scanner pipeline's own governance document. The accurate statement, which is what the banner now says, is that it is defined but unpublished, the current holder is unassigned, and nothing about rotation or diversity appears in the public SECURITY.md. Publishing that document closes both this and the marker in the Day 2 security answer.

Of what remains, the two I would treat as real DD blockers rather than paperwork are the load/scale numbers with methodology — "recommended limits" without a method is the question TOC reviewers reliably push on — and the publication decision above, since without it the SCA answer is an assertion a reviewer cannot check.