Publish machine-readable statements for the vulnerabilities that are not fixed

[iderex]

The target gate validates a set of published vulnerability statements as part of
its build, so that a malformed edit fails there rather than at the step that
ships the document.

Every scanner in this milestone will eventually report something that is not
exploitable here, or not reachable from any path this core takes. The choices are
to fix it, to suppress it silently, or to say publicly why it does not apply. The
third is the only one a downstream consumer can act on, and it is the one that
survives the person who made the judgement leaving.

What this produces

A machine-readable document listing each known advisory against a dependency of
this repository with a disposition and the reasoning for it.

A structural check inside the gating build, so a malformed edit reddens a pull
request rather than a release.

A rule that a suppressed scanner finding must have a statement, so that
suppression and explanation cannot come apart.

Done when

The document exists and validates in the gate, a malformed edit reddens it, and
every suppression in any scanner configuration in the repository has a matching
statement. Blocked on #19 and #81.

[iderex]

The third condition here is not empty today, and its first instance predates both
issues this one names.

A scanner configuration in this tree already excludes a class of findings from the
gate and carries its reason as a comment rather than as a statement anything reads:

git grep -n 'pedantic persona is deliberately NOT used' -- .github/workflows/zizmor.yml
.github/workflows/zizmor.yml:10:# actionable"). The pedantic persona is deliberately NOT used to gate: it adds

The reason runs on from there to line 15, where it is parked:

git grep -n '#263' -- .github/workflows/zizmor.yml
.github/workflows/zizmor.yml:15:# tracked as a code-quality task (#263), not gated here.

That number does not resolve on this board:

gh issue view 263 --json number -q '.number'
GraphQL: Could not resolve to an issue or pull request with the number of 263. (repository.issue)

So the one exclusion in the tree points at a task nobody here can open, which is
the state this issue exists to replace, arriving before the scanners in #19 and
#81 have added any of their own. A reader who wants to know why the low-severity
hygiene findings are not gated gets a sentence and a dead number.

Two things follow for the scope here rather than for the wait.

The condition reaches configuration that is not a dependency advisory. What is
excluded above is a class of workflow findings, not a vulnerability in a package,
so a document shaped only around advisories against dependencies would not have a
row for it and the condition would read as met while this exclusion still has no
statement. Either the document covers both kinds or the condition says which one it
means.

The instance is available for the proof. A deliberate malformed edit is the second
condition and needs the document. Showing that a suppression without a statement is
refused needs a suppression, and there is one here already rather than one that has
to be invented for a fixture.

I have changed nothing in that workflow. It is not this issue's file, and what the
comment says about the persona choice reads as deliberate rather than accidental.

[iderex]

Two readings recorded above have moved, and one of them changes how many
instances the third condition here has to cover. Read at
aeb3907bb4e2f9aa7366c839f79b835206162c99.

The dead number is repaired. The exclusion itself is untouched:

git grep -n 'pedantic persona is deliberately NOT used' origin/main -- .github/workflows/zizmor.yml
origin/main:.github/workflows/zizmor.yml:11:# actionable"). The pedantic persona is deliberately NOT used to gate: it adds

and the reason beside it now says which repository the number belongs to, so it
resolves where it was written rather than reading as a task on this board:

git grep -n '263' origin/main -- .github/workflows/zizmor.yml
origin/main:.github/workflows/zizmor.yml:19:# Flowfin/jellyfin-plugin-sso#263.
gh issue view 263 --repo Flowfin/core --json number -q '.number'
GraphQL: Could not resolve to an issue or pull request with the number of 263. (repository.issue)
gh issue view 263 --repo Flowfin/jellyfin-plugin-sso --json number,state,title --jq '"\(.number) \(.state) \(.title)"'
263 CLOSED Address zizmor pedantic workflow code-smells (non-gating)

What that exclusion still has is a sentence in a comment and nothing a machine
reads, which is the half this issue is about, and that half did not move.

The count is the part worth having. The reading above is written as though the
tree held one instance. It holds a second, in another of the guards that run
here, and it is the same shape:

sed -n '42,46p' .github/workflows/unicode-guard.yml
          # included as an invisible control with no legitimate use in source. U+FEFF (BOM) is
          # deliberately NOT listed: a leading UTF-8 BOM is legitimate (solution files often carry one),
          # so banning it outright would false-positive, and the bidi reordering attack does not
          # rely on it.
          pattern='(*UTF)[\x{202A}-\x{202E}\x{2066}-\x{2069}\x{200E}\x{200F}\x{061C}\x{200B}-\x{200D}\x{2060}]'

U+FEFF is absent from the set that guard refuses, the reason it is absent is a
judgement that the codepoint has a legitimate use and that the attack the guard
exists for does not rely on it, and that judgement lives in a comment next to the
pattern. Nothing machine-readable stands behind it, because no such document is
in the tree at all:

git ls-tree -r --name-only origin/main | grep -Ei 'vex|csaf|advisor'
exit=1

Both instances are a class excluded from what a scanner is pointed at, rather
than a finding a scanner raised and somebody turned off. That is a sharper form
of the scope question opened above. A document shaped around findings that were
raised and suppressed has no row for either of them, so this condition can read
as met while two live exclusions in the tree carry their reasoning only as a
comment, which is the arrangement the body argues against.

One thing nearby is a different shape and I am not counting it as a third.
dco.yml exempts two bot identities from the rule it enforces:

git grep -n 'allowlist' origin/main -- .github/workflows/dco.yml
origin/main:.github/workflows/dco.yml:60:            # self-sign; exempt them, as the DCO App does. An explicit allowlist of

That takes a subject out of a check rather than a class of findings out of a
scanner, so a statement register built for the two above would not obviously have
a row for it either, and whether it wants one is a question rather than an
omission.

This stays open on what it already waits for. I have edited neither workflow and
changed no condition here.