fix(os): clear the appliance rootfs CVE gate at the source (#1153)

[VijitSingh97]

Closes #1153.

OS rootfs scan has been red on develop-v2's own tip since 2026-08-19 — four runs, with PRs
merged through them. No commit broke it: the branch was untouched between a green run and a red one
and the advisories were published in between.

Three findings, three different answers

Raised in the build — the rootfs compiles both binaries from source, so the module graph is
ours, the same reasoning the patched toolchain above them already uses:

module
golang.org/x/mod	v0.38.0 → v0.40.0	CVE-2026-56864, CVE-2026-56865	both binaries
google.golang.org/grpc	v1.82.0 → v1.82.1	GHSA-hrxh-6v49-42gf	cosign

Neither is reachable by a pin bump. cosign v3.1.3 is the newest release and pins x/mod v0.37.0;
compose v5.4.0 and v5.5.0 both pin v0.38.0; cosign's own main is still v0.38.0.

Two mutes deleted, not added. .trivyignore already carried CVE-2026-56852 (x/text) and
GHSA-hrxh-6v49-42gf (grpc), on the premise that these modules were vendored inside downloaded
release binaries so "no pin bump can clear them". That premise died when the rootfs started
compiling them. Both are fixed at the source now and their entries are gone.

That deletion is load-bearing, not tidiness: while a mute is present the scan cannot tell "fixed"
from "hidden". The first version of this branch verified the grpc raise against grpc's own
still-present mute and proved nothing. Caught in review.

One accepted, with corrected reasoning — github.com/docker/docker CVE-2026-34040, which
genuinely cannot be raised (see below). It replaces a duplicate: the change had added a second entry
for an ID already accepted at line 24, with a different rationale and a different clearing
condition, so following either comment would have left the other muting.

Verification — the scan, on the real binaries, twice

Built the gobuild stage on a real machine and scanned the extracted binaries with trivy 0.70.0 and
the gate's own flags.

With no ignore file at all (the probative run — nothing can hide behind a mute):

cosign          gobinary   0
docker-compose  gobinary   1   <- CVE-2026-34040 only

With the trimmed .trivyignore, gate settings, --exit-code 1:

cosign          gobinary   0
docker-compose  gobinary   0
TRIVY_EXIT=0

docker-compose version and cosign version both run in the build's own check (exit 0).

Why CVE-2026-34040 cannot be raised

Trivy names the fix as 29.3.1. That is a Moby release, not a version of this module:

go list -m -versions github.com/docker/docker   -> ... v28.5.2+incompatible   (newest)
go list -m -versions github.com/moby/moby       -> ... v28.5.2+incompatible   (newest)

Tried it rather than assuming — the build fails with invalid version: unknown revision v29.3.1.
Docker 29 lives at a module path compose does not import, so no compose release can carry it
either: v5.4.0, v5.5.0 and main all pin v28.5.2+incompatible. The advisory is also a daemon-side
authz bypass, and compose links the client half.

Two provenance claims corrected, both found by review

• A raise moves more than it names. go get X@v Y@v upgrades the whole closure MVS needs to
  seat them — compose moves 1 module, cosign moves 9 (x/mod → x/tools → x/net → x/crypto,
  x/term, x/text, x/sync, x/sys). No formulation avoids that; it is what raising a module in a Go
  build means, so it is written down instead of implied. The reviewer's security framing was
  checked and does not hold: the release-signature verifier is the pinned ghcr.io/sigstore/cosign
  container (pithead:542), not this binary, whose only consumer is an -x check in
  tests/os/verify-image.sh.
• cosign version now reports v3.1.3+dirty. go get edits go.mod, Go stamps vcs.modified,
  and release-utils overwrites the gitVersion ldflag from the build info — so the ldflag is inert
  and the suffix is truthful. The build was nevertheless still asserting gitTreeState=clean about
  a tree Go itself had recorded as modified. It now says dirty, so the two agree and both are
  true. Confirmed on the rebuild: GitVersion: v3.1.3+dirty, GitTreeState: dirty.

Nothing in the repo or the overlay parses either version string — checked.

Not done

• The local scan covered the two Go binaries, not the whole rootfs image. CI's OS rootfs scan
  scans the full image and is the real gate here; this PR's own run is what confirms it.
• No tier-1 test asserts the raises landed, deliberately: the scan is the behavioural gate, and a
  source-text assertion that the ARG contains a version string would be exactly the kind of check
  this repo keeps finding cannot fail.
• The compose currency bump (v5.4.0 → v5.5.0, The pin watcher never sees the appliance's own two pins: a schedule only runs on the default branch #1146) is not here. It is a separate decision — a
  compose minor is a behaviour change, and it does not move any of these three findings.

[VijitSingh97]

Merging with Build image (dashboard) red. It is not this change: PR #1155, which does not touch .trivyignore at all, fails the identical check with the identical finding list. CI was green on develop-v2 at 04:43 today and red at 13:32 with no commit in between — three new util-linux advisories (CVE-2026-53612/53613/53614), the same family as the already-accepted CVE-2026-53615. Filed as #1156, where I also confirmed a base bump cannot fix it: the pinned python:3.11-slim digest is already the newest published one.

Every other check is green, including Build + scan the appliance rootfs — the gate this PR exists to fix.