fix(vex): alias the GHSA so the statement grype reports actually matches #100

Merged
ryangr0 merged 1 commit from fix/vex-aliases-and-unmatched-guard into main 2026-08-08 04:47:58 +00:00
Owner

ADR-0005's VEX suppression has never worked. The first verdict the gate ever produced said vex-suppressed=0 with five reviewed statements applied — and grype agreed: 0 ignored.

Proven, not reasoned

Two earlier guesses (--vex itself, then path resolution) were both wrong, so this was measured on the runner.

First the product identifier was ruled out — a statement with product "*" still suppressed nothing. That left the vulnerability name. Four forms, same image, same single statement:

statement ignored
name: CVE-2026-34040 ← what we ship 0
name: CVE-2026-34040, aliases: [GHSA-x744-4wpc-v9h2] 1
name: GHSA-x744-4wpc-v9h2 1
name: GHSA-…, aliases: [CVE-…] 1

grype matches against the vulnerability ID it reports, and for Go modules that's the GHSA. Our statements name CVEs, so they never matched.

Aliases are honoured — so the CVE stays as the human-readable name and the GHSA goes alongside. The assertion is unchanged; only its identifiers are now complete.

GitHub's advisory API confirms GHSA-x744-4wpc-v9h2 is CVE-2026-34040 — the single High finding, and the only one that counts against a high: 0 budget. With it suppressed, cve-gate should meet its budget for the first time.

The guard is the more important half

A statement that suppresses nothing is indistinguishable, in every number this gate prints, from having no statement at all. That's how five of them sat here doing nothing across eight releases.

The gate now warns when statements were applied and grype suppressed nothing, naming the GHSA/CVE mismatch as the likely cause. It deliberately does not fail: an inert statement isn't itself a security hole, it's a claim not doing the work its author believed it was. But it has to be visible, because the failure mode is a budget that looks enforced and isn't.

Verified: warns on (5 statements, 0 ignored); silent on (5,1), (0,0) and (1,3). go vet and go build clean.

⚠️ Left for review — deliberately not rewritten

These are reviewed security assertions; changing what they claim is your call, not a side effect of a mechanism fix.

  • CVE-2026-41567 — grype reports CVE-2026-41568 (GHSA-vp62-88p7-qqf5) for docker/docker. An off-by-one that looks like a transcription error, but correcting a CVE number changes what the statement asserts.
  • CVE-2026-42306, CVE-2026-56852, GO-2026-5932 — not reported by grype in this scan at all. Inert and harmless, but they should be re-confirmed or retired rather than left to accumulate.

Neither affects the budget: both remaining findings are Medium, and the budget is critical/high.

This also cuts the release

It touches ops/docker/cve-gate/src/, so merging cuts cve-gate 0.3.4 — the first release to exercise #99's stderr fix, and the first real chance at a signed cve-gate.

**ADR-0005's VEX suppression has never worked.** The first verdict the gate ever produced said `vex-suppressed=0` with five reviewed statements applied — and grype agreed: `0 ignored`. ## Proven, not reasoned Two earlier guesses (`--vex` itself, then path resolution) were both wrong, so this was measured on the runner. First the product identifier was ruled out — a statement with product `"*"` **still** suppressed nothing. That left the vulnerability name. Four forms, same image, same single statement: | statement | ignored | |---|---:| | `name: CVE-2026-34040` ← what we ship | **0** | | `name: CVE-2026-34040`, `aliases: [GHSA-x744-4wpc-v9h2]` | **1** ✅ | | `name: GHSA-x744-4wpc-v9h2` | **1** ✅ | | `name: GHSA-…`, `aliases: [CVE-…]` | **1** ✅ | **grype matches against the vulnerability ID *it* reports, and for Go modules that's the GHSA.** Our statements name CVEs, so they never matched. Aliases *are* honoured — so the CVE stays as the human-readable name and the GHSA goes alongside. The assertion is unchanged; only its identifiers are now complete. GitHub's advisory API confirms `GHSA-x744-4wpc-v9h2` **is** `CVE-2026-34040` — the single **High** finding, and the only one that counts against a `high: 0` budget. With it suppressed, cve-gate should meet its budget for the first time. ## The guard is the more important half A statement that suppresses nothing is **indistinguishable, in every number this gate prints, from having no statement at all**. That's how five of them sat here doing nothing across eight releases. The gate now warns when statements were applied and grype suppressed nothing, naming the GHSA/CVE mismatch as the likely cause. It deliberately **does not fail**: an inert statement isn't itself a security hole, it's a claim not doing the work its author believed it was. But it has to be visible, because the failure mode is *a budget that looks enforced and isn't*. Verified: warns on `(5 statements, 0 ignored)`; silent on `(5,1)`, `(0,0)` and `(1,3)`. `go vet` and `go build` clean. ## ⚠️ Left for review — deliberately not rewritten These are reviewed security assertions; changing what they *claim* is your call, not a side effect of a mechanism fix. - **`CVE-2026-41567`** — grype reports `CVE-2026-41568` (`GHSA-vp62-88p7-qqf5`) for docker/docker. An off-by-one that looks like a transcription error, but correcting a CVE number changes what the statement asserts. - **`CVE-2026-42306`, `CVE-2026-56852`, `GO-2026-5932`** — not reported by grype in this scan at all. Inert and harmless, but they should be re-confirmed or retired rather than left to accumulate. Neither affects the budget: both remaining findings are Medium, and the budget is critical/high. ## This also cuts the release It touches `ops/docker/cve-gate/src/`, so merging cuts cve-gate 0.3.4 — the first release to exercise #99's stderr fix, and the first real chance at a signed cve-gate.
fix(vex): alias the GHSA so the statement grype reports actually matches
All checks were successful
[Workflow] On Source Change / Guard: per-image .releaserc.cjs present (push) Successful in 3s
[Workflow] On Source Change / Determine Changed Directories (push) Successful in 19s
[Workflow] On Source Change / Determine changed images (push) Successful in 0s
[Workflow] On Source Change / Resolve release matrix (push) Successful in 3s
[Workflow] On Source Change / Release (cve-gate, ops/docker/cve-gate) (push) Has been skipped
[Workflow] On Source Change / Build check (cve-gate, ops/docker/cve-gate) (push) Successful in 20s
51df52ca5c
ADR-0005's suppression has never worked. The first verdict the gate ever produced said
"vex-suppressed=0" with five reviewed statements applied, and grype's own summary agreed:
"0 ignored".

Proven on the runner rather than reasoned about, because two earlier guesses (--vex itself, then
path resolution) were both wrong. First the product identifier was ruled out — a statement with
product "*" still suppressed nothing — which left the vulnerability name. Four forms, same image,
same single statement:

    name=CVE-2026-34040                          -> 0 ignored
    name=CVE-2026-34040, aliases=[GHSA-x744-...] -> 1 ignored
    name=GHSA-x744-...                           -> 1 ignored
    name=GHSA-x744-..., aliases=[CVE-...]        -> 1 ignored

grype matches against the vulnerability ID IT reports, and for Go modules that is the GHSA. Our
statements name CVEs, so they never matched. Aliases ARE honoured, so the CVE stays as the
human-readable name and the GHSA goes alongside it — the assertion is unchanged, only its
identifiers are now complete.

GitHub's advisory API confirms GHSA-x744-4wpc-v9h2 IS CVE-2026-34040: the single HIGH finding, and
the only one that counts against a high:0 budget. With it suppressed, cve-gate should meet its
budget for the first time.

THE GUARD IS THE MORE IMPORTANT HALF. A statement that suppresses nothing is indistinguishable, in
every number this gate prints, from having no statement at all — which is how five of them sat here
silently doing nothing across eight releases. The gate now warns when statements were applied and
grype suppressed nothing, naming the GHSA/CVE mismatch as the likely cause. It deliberately does
not fail: an inert statement is not itself a security hole, it is a claim not doing the work its
author believed. But it must be visible, because the failure mode is a budget that looks enforced
and is not.

LEFT FOR REVIEW, deliberately not rewritten here — these are reviewed security assertions and
changing what they claim is the author's call, not a side effect of a mechanism fix:
  - CVE-2026-41567: grype reports CVE-2026-41568 (GHSA-vp62-88p7-qqf5) for docker/docker. An
    off-by-one that looks like a transcription error, but correcting a CVE number changes what the
    statement asserts.
  - CVE-2026-42306, CVE-2026-56852, GO-2026-5932: not reported by grype in this scan at all. Inert
    and harmless, but they should be re-confirmed or retired rather than left to accumulate.
Neither affects the budget: both remaining findings are Medium, and the budget is critical/high.
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
webgrip/infrastructure!100
No description provided.