Surface into the public SECURITY.md the rotating Security Champion policy (6-month term, one-week handoff) and the security response team's composition and cross-organization diversity, previously defined only in the CVE-scanning pipeline's private governance document. Record @tym83 as the current champion, filling the role the GTR and this file flagged as unassigned.
Signed-off-by: Timur Tukaev <6355522@gmail.com>
Four independent reviews of the first draft of this reporting found that it
overstated remediation, understated how much of the backlog was never
applicable, and contained a disclosure leak the stated rule had not
anticipated. What lands here is the corrected version.
The reconciliation is the substantive artifact. It audits every finding the
CVE-scanning pipeline has tracked against what the project actually shipped,
because the pipeline has no write-back from this repository and so has never
marked anything fixed. Findings: remediation did happen and is invisible to the
tracker, concentrated in one wave in June 2026 rather than the steady stream an
earlier draft claimed; 57% of the backlog was never applicable or cannot be
assessed, the largest block being packages that contain no executable
vulnerable code, chiefly kernel headers, since a container never provides a
running kernel; reachable exposure in a stock install is an estimated 2-5% of
the tracker; four component bumps are available upstream and not yet taken; and
the pipeline itself has seven defects, including deduplication by CVE
identifier alone and a broken attribution step that left 16% of findings
unattributable.
The monthly reports are cut back to per-month facts. Remediation is no longer
attributed to individual months: crossing a severity-banded count of still-open
findings with one month's component bumps, which anyone can enumerate from the
commit log, narrows the search for unpatched exposure more than a bare count
does. An earlier draft did exactly that while refusing to publish bare counts
on disclosure grounds. The triage-latency figure is also gone, because 494 of
495 decisions were recorded in a single bulk pass and a per-finding latency
cannot be recovered from a closing timestamp.
Two process-tracking issues that the pipeline's severity filter should have
excluded are no longer counted as findings, so the total is 825 rather than 827.
The disclosure rule is revised in two directions, both more open: findings with
no upstream fix will be named with mitigation guidance, since there is nothing
to wait for and a mitigation is then the only available control; and the
generator's guard now covers every advisory namespace rather than CVE alone,
refuses to emit any file if any file would leak, and takes released evidence
rather than a stale tracker label as its source of truth.
SECURITY.md, the self-assessment and the GTR are brought into line: all three
previously described this reporting as unpublishable, and the GTR refused on
principle the counts the reports print.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
Maintainer decisions on the two questions this branch raised rather than
answered.
Supported versions are the latest stable minor and the two minors preceding it.
Expressed as a rolling rule, so it names concrete lines when read against the
Releases page without going stale, and it replaces the activity-window test,
which classified every 1.x line back to 1.0 as supported and so described
something wider than the project does.
There is no documented rule for choosing which supported lines a fix is
backported to; it is a per-fix maintainer decision weighing severity against
backport risk. Say that plainly in SECURITY.md instead of implying a policy.
That also resolves the promise in the incident-response process, which said a
fix ships across all affected supported release lines. It does not necessarily,
and with no rule governing the choice that sentence committed the project to
something it has not agreed. Point at the per-fix decision instead.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
The vulnerability-reporting paragraph named severity and upgrade impact as the
basis for backporting to an older line, two paragraphs after the table says no
rule is documented. Both sentences were added by this branch, so this is an
internal inconsistency of its own making rather than inherited text. Point at
the same absence instead of naming a basis.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
The previous commit added a backport prioritisation policy to SECURITY.md — by
severity, by reachability in a default configuration, and by adopter count, with
a critical fix reaching every supported line. No such rule exists in any project
document. Reachability appears only as a triage question, and adopter count
appears nowhere. In an adopter-facing file that also lists seven supported
lines, that sentence read as a guarantee no maintainer has made. Replaced with
what is actually true: backporting is decided per fix and the rule is not
documented.
Nightly figures corrected. Counting only scheduled runs, the first run after
the fix still failed, the streak that followed was three days rather than four,
and six of the last twenty-four passed rather than seven. The earlier numbers
folded in a workflow_dispatch success from a day whose scheduled run failed.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
The previous commit narrowed a true statement into a false one. It said the
scanner gap was remediation throughput and that triage ran on schedule; triage
is also behind, and the backlog awaiting a triage decision includes findings at
critical severity well past the one-business-day target. Both tracks are now
stated as behind. Figures stay out of this repository for the disclosure reason
the document already gives and belong in the private channel, so the admission
is qualitative rather than rounded down.
The nightly characterisation was also wrong. It read as fixed-then-regressed,
which understates it: after the fix in #3332 the scheduled run passed for four
days, went red for five, passed for three, and has failed every run since
2026-08-02 — seven of the last twenty-four passed. It is flapping, not newly
broken, and the current failure is untriaged rather than provably unfiled.
Carry the target-attainment caveat into SECURITY.md, which stated the triage
SLAs with no indication they are not being met, and resync the self-assessment
on the monthly report: it names findings individually and so is not publishable
until reduced to counts by severity.
Also note in SECURITY.md what the activity test actually classifies today —
every 1.x line from 1.0 to 1.6 — and how backport effort is prioritised across
that set, since supporting seven lines in parallel otherwise invites the
question it does not answer.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
A second internal pass found that the previous commit's disclosure argument did
not hold together and that its support test could not be evaluated by a reader.
The document had nominated the monthly aggregate summaries as safe-to-publish
evidence on the grounds that they hold no vulnerability detail. They do: they
name accepted-risk findings individually by CVE ID, severity and package, some
of them critical, next to a count of confirmed findings awaiting a fix. State
the line where it actually falls — aggregate counts by severity are
publishable, naming an individual unfixed finding is not, because a CVE ID plus
a package plus this project's public pinned component list locates unpatched
exposure — and note that the monthly summary needs reducing to counts before it
can be published. Present the resulting posture as a proposal rather than as a
position the maintainers have taken.
The scanner SLA paragraph said a triage backlog was running against the clock.
The pipeline's own output says something more specific and worse: triage is
keeping up, remediation is not, with the last monthly period closing on no
confirmed findings fixed. Say that instead.
The supported-versions table keyed support to having an active release branch.
Release branches are never deleted, so every line back to the earliest has one
and the test tells a reader nothing; read literally it also committed the
project to every 1.x line. Key it to patch activity within a stated window
instead, restore an end-of-life category the previous commit had removed
entirely, and put the v0.41 cutoff back rather than extending discretionary
backports across all of 0.x.
Also: drop an unevidenced claim that the per-PR checks are healthy, correct the
nightly attribution — the current red run is a regression after #3332 and is
not tracked by an issue, unlike the older failure in #3278 — and qualify how
zizmor gates, through the required pre-commit hook rather than through its own
path-filtered workflow.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
Two internal reviews of the previous commit found that it overstated several
controls. Corrections, all verified against the tree and the GitHub API:
CodeQL is not a required status check on main — the required checks are
pre-commit and E2E Tests — so the questionnaire no longer says it gates merges.
SECURITY.md and the security self-assessment already hedged this correctly and
the GTR now matches them.
Renovate does not cover Helm charts: helm-values is disabled repo-wide because
many image refs are assembled by the cozy-lib.image helper rather than written
literally in values.yaml. Say so, and say that the curated platform component
images are bumped by maintainers per release rather than by a bot.
The rewritten supported-versions table narrowed the support window to the
latest two minors, which contradicts practice — several 1.x lines receive patch
releases concurrently. Restate it as a description of what the project actually
does, keyed to active release branches rather than to version numbers.
The CVE-scanning pipeline is described more precisely: noise filters run before
issue creation, discovery reads direct Go requirements with transitive coverage
coming from the filesystem scan, and render-time image refs are a known blind
spot. Its SLAs are labelled as targets rather than measured attainment, and the
confidentiality claim is narrowed from the whole repository to per-CVE findings
and triage state, since the policy documents and scripts hold no vulnerability
data and are what actually evidences the control.
SBOM and provenance are stated from the build tooling rather than from an issue
title: provenance is explicitly disabled and SBOM generation is implemented but
defaulted off. zizmor is added as a third gating scanner in both documents.
Also close markers that repository evidence settles: the in-tree security
self-assessment, threat model and incident-response documents; no default audit
policy is shipped; and there is no top-level NOTICE file, which is stated as a
compliance gap rather than deferred. Fix the phantom OWNERS reference at its
source in CONTRIBUTOR_LADDER.md, and add current CI health next to the e2e
workflow links so the red nightly run is disclosed rather than discovered.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
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>
GitHub write access and the documented roster describe two different
projects: ten people hold write or admin on this repository without
appearing in MAINTAINERS.md, and three people listed there hold only
read. CNCF Incubation requires code ownership in GitHub to match
documented governance roles, and there is no in-between state for it.
Add the three contributors whose work is project-wide -- lexfrei,
myasnikovdaniil and IvanHunters -- as maintainers, and introduce a
Reviewers table for people who own a specific area with write access but
not the project-wide responsibilities of a maintainer. The Reviewer tier
already existed in CONTRIBUTOR_LADDER.md and had never been used; the
area-to-owner mapping stays in .github/CODEOWNERS, which this table
mirrors.
Also name the maintainers who triage security reports, so the Required
'contact information' item points at people rather than at a list.
Assisted-By: Claude
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
Bring the security documentation in line with controls that are already
in place, and add the two coordinated-disclosure items flagged during the
incubation due-diligence review.
- self-assessment: DCO is enforced by an automated check; private intake
is GitHub Private Vulnerability Reporting; OpenSSF passing badge achieved
2026-04-01 (working toward silver); GHSA/PVR framing for advisory history;
incident-response now summarized publicly.
- SECURITY.md: route reports to Private Vulnerability Reporting with a
MAINTAINERS.md fallback; add a 90-day coordinated-disclosure window and a
CVSS-based remediation-target table.
- CODEOWNERS: document that it encodes the area-scoped Reviewer role, which
is intentionally distinct from the MAINTAINERS.md governance roster, and
that security reporting is not routed through this file.
- Add docs/security/incident-response.md as the public incident runbook.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: tym83 <6355522@gmail.com>
Record the repository's automated security analysis in SECURITY.md: CodeQL
SAST (manual Go build, runs per-PR/push/weekly, new-alert-on-diff, intended
as a required pre-merge check, dismiss-with-reason for false positives) and
OpenSSF Scorecard (supply-chain posture, published to the scorecard.dev
badge, intentionally not uploaded to code scanning). Mirrors the workflow
changes in this PR so the security posture is documented, not just encoded
in YAML.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Timur Tukaev