Make every version the catalogue runs both immutable and tracked by update automation #627

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

Evidence

Measured on main at 945434b on 2026-10-17:

• Go modules. There are 15 go.mod files. dependabot.yml lists only two (.github/tests/govulncheck-allowlist and govulncheck-generics), and both entries ignore every dependency. No Go module in the catalogue therefore receives version updates. Among the untracked modules with dependencies are two shipped actions: validate-shell-pipelines uses mvdan.cc/sh/v3 v3.14.1, the shell parser that decides pass or fail in consumer CI, and validate-naming uses go.yaml.in/yaml/v3 v3.0.5. The PostgreSQL test fixture (pgx/v5 v5.10.0) and the credentials test module are also untracked.
• Hard-coded tool versions that no automation reads: semantic-release@25.0.3, golangci-lint v2.14.0 (three places), deadcode@v0.50.0, gocover-cobertura@v1.5.0, node-version: 22, GODOT_VERSION: 4.7.1, and the cosign installer's implicit default (no cosign-release input is set). The upstream review found security fixes already missed in semantic-release and Go; that bump is Take the semantic-release 25.0.9 and Go 1.26.9 security fixes on the shared release and validation paths #625.
• Images. The PostgreSQL fixture image is pinned by digest in validate-go-project.yaml and its read-only projection, and no ecosystem in dependabot.yml covers it.
• Pins that do not freeze what runs. github/stale-repos is SHA-pinned, but runs a floating :v9 container image while holding an organization App token. Homebrew/actions/setup-homebrew tracks a main commit because upstream publishes no releases; it is now behind upstream main.

Audience and problem

Every consumer inherits these versions. A pin nobody updates is safe only until its next upstream fix, and nothing here notices that moment. A SHA pin around a floating image gives the appearance of immutability without the substance.

Hypothesis

If every pinned version is either tracked by update automation or listed in one reviewed refresh manifest, upstream fixes reach consumers through the normal review path. The existing refresh-gh-digests updater is the model for the manifest. Changes would arrive within the 7-day cooldown, not when someone happens to look.

Direction

• Add one gomod update entry covering every module with dependencies, as a single weekly group with the existing cooldown. Keep the two vulnerability fixtures deliberately frozen and say why in a comment.
• Move each hard-coded tool version to a place an updater can read: a Dependabot-readable file, or a version manifest with a reviewed updater like refresh-gh-digests.yaml.
• First verify whether Dependabot reads a workflow services: image. If it does not, cover the PostgreSQL image through the same manifest.
• Pin stale-repos' image by digest, by calling the image directly or replacing the action. Record why setup-homebrew tracks main, and give it a refresh path.
• Keep the added update volume small. Bursts of update pull requests already starve the organization's runners (A burst of pull requests here starves the organization's runners and delayed a production deploy by an hour #475), so prefer one grouped pull request per ecosystem per week.

Acceptance criteria

• A census, kept as a test, lists every version pin in workflows, actions and modules, and fails when a pin is neither tracked nor in the manifest.
• Every module with dependencies receives grouped weekly updates.
• No step runs a container image by a mutable tag while holding a token that can write.
• The weekly number of update pull requests is measured before and after, and does not grow by more than one per ecosystem.

Priority rationale: removes the cause of the missed security fixes and closes a supply-chain gap in an App-token job. Effort: medium. Prerequisites: none.

Rough size: M.