deps: raise everything that was behind, and watch what nothing was watching

[donislawdev]

An audit of every pinned thing in the repository, prompted by yesterday's migration, where two CI tools turned out to be on versions that could not read Go 1.27 at all.

Raised

Each checked against its own release source rather than recalled.

	from	to
golangci-lint	v2.13.1	v2.13.2
semgrep	1.175.0	1.176.0
actions/deploy-pages	v5.0.0	v5.0.1
anchore/sbom-action	v0.24.0	v0.24.2
golang.org/x/image	v0.43.0	v0.45.0

x/image is the only one that could have moved bytes, and it does not - every format at two sizes, byte for byte identical across the bump. D11 holds and no version is owed. The module graph is unchanged at 68, and the notices file carries the new number because those licences ask for the version that actually ships.

The comment in webp.go citing what x/image contains was re-read at v0.45.0 rather than carried across with the number changed. It still holds no encoder.

The rest of the audit came out clean

Ten of twelve actions were already current, five of six direct modules were, and all three Dependabot alerts are fixed with govulncheck finding nothing.

The finding: four pins nothing was watching

CLAUDE.md says Dependabot keeps these current, and that is true of go.mod and of uses: only. Four tool versions live as shell commands inside workflow steps, where it does not look.

Measured: thirty pull requests from that bot, not one about any of them. Nobody had ignored a warning yesterday. There was never going to be one.

Semgrep moves to .github/requirements-semgrep.txt, an ecosystem Dependabot reads, so it will now arrive as a pull request.

The three Go tools cannot be handled that way, twice over. A token cannot push changes under .github/workflows, so no bot can edit the line they sit on; and putting them in go.mod as tool directives was measured at 69 modules becoming 439 - against immutable rule 11, which asks for a licence check on every one, and against two gates that pin that graph deliberately.

So they get a weekly job that reports instead. Two things about how it does that:

• It reads the pins out of the workflows rather than keeping its own copy.
• It asks the Go module proxy, not the GitHub releases API. The first version asked GitHub and raised two false alarms out of three - staticcheck releases under two names at once (v0.8.1 is 2026.2.1), and x/vuln answered with an older tag than the one already pinned. A gate that cries wolf is worse than no gate, which is the whole thing this job exists to replace.

Confirmed in both directions: rolled staticcheck back to v0.7.0 and it goes red, naming exactly the failure that cost a session yesterday.

Also

The semgrep guard was split rather than relaxed: the job has to name the requirements file, and the file has to pin an exact version, so an empty file cannot pass.

preflight.py gains a toolchain check, first in the list, comparing go version with the toolchain line in go.mod. It asks rather than sets - putting GOTOOLCHAIN from a script would take the setting away from whichever project holds it, which is the same tug of war in the other direction. (tools/ is outside the repository, so that part is not in this diff.)

What was checked

• full suite green, preflight 10 of 10 including the two new tool versions
• x/image byte neutrality across all 24 formats at two sizes
• the version checker proven red as well as green
• six mutations caught, three of them repointed after the bumps staled them

Written up as O170.

🤖 Generated with Claude Code