fix(ci): resolve nightly packages digest without image-specific skopeo ops - #3332

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 <[email protected]>
Signed-off-by: Timur Tukaev <[email protected]>

…timeline

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 <[email protected]>
Signed-off-by: Timur Tukaev <[email protected]>

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: LLM
Signed-off-by: Timur Tukaev <[email protected]>

…timeline

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: LLM
Signed-off-by: Timur Tukaev <[email protected]>