security(supply-chain): the pin guard rejects the concrete revisions a generated allow-list emits #3531

🤖 Generated by the Agentic Engineer

Evidence

guard-shared-publish-workflow-pin.sh judges each ref alternative against the literal pattern text [0-9a-f]{40}, because these cosign subjects are regexes. A subject naming one concrete commit — exactly what a generated approved-revision allow-list emits — is therefore rejected, despite being strictly narrower than what is accepted.

The guard's own header recorded this as a deliberate limit rather than a defect, and asked for the widening once the generator landed:

extend the allow-list deliberately when the generator lands, rather than reading the failure as a defect in the generated output

The generator is #3048, merged 2026-08-23. So the prerequisite is met and this is now the blocking step: any narrowing produced from the report reads as a guard failure until the allow-list recognises the concrete form.

Problem

The enabling half of #3308 cannot be built while correct generated output fails CI.

Expected

The allow-list recognises two forms — the pattern text (any 40-hex commit) and a concrete 40-hex commit (exactly one) — with the widening bounded so it cannot become a loosening.

Acceptance criteria

• A concrete 40-hex commit is accepted, and an alternation of two concrete commits (the shape a diverged consumer needs) is accepted.
• The widening is covered by a test that fails if it is reverted — i.e. the GREEN case must fail against the previous guard, not pass vacuously.
• Near-miss shapes stay rejected: 39-hex, 41-hex, uppercase hex, a concrete commit with anything appended, and an approved set widened back with a branch alternative.
• No cosign subject changes. Narrowing the live matchers is security(supply-chain): the computed approved revisions are not consumed — matchers still accept any fixed revision #3308's remaining half and carries a different blast radius.

Size

Small. Guard plus its test; no manifest changes.