Check the platform's Go modules for known advisories in CI #4961

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

Problem

Nothing in this repository checks its Go tooling for known security advisories. The root module ran on a Go release and a golang.org/x/net version with 18 known advisories for at least a week. The repository's own checks never reported them. They were found because the same advisories failed the vulnerability scan in data-product-controller on 2026-10-09 (#4684).

The nested modules are in the same position. A local version scan on 2026-10-16 reported known advisories in every one of them:

A version scan does not show which advisories these tools actually reach. Some of these modules are pinned on purpose to match an upstream release. That is a valid reason to keep a version. It should be a recorded exemption that a check can read, not an unchecked gap.

Audience and outcome

• Audience: everyone who relies on the production deploy and CI tooling.
• Outcome: a new advisory against a module this repository builds becomes a visible, failing check in the pull request that introduces it, or in a scheduled run when the advisory is published later.
• Success signal: a deliberately vulnerable fixture fails the check. The current root module passes. Each nested module either passes or has a named, reasoned exemption that the check enforces.

Proposed direction

• Prefer the organization's shared Go validation, if it already offers a vulnerability step that sibling repositories use, over a bespoke job.
• Use reachability-aware scanning (govulncheck) for modules this repository builds and runs. Record pinned upstream-mirror modules as explicit exemptions with their reason and an owner check.
• Run the check on pull requests that touch Go modules, and on a schedule, so that an advisory published after merge is still caught.

Acceptance criteria

• Pull requests that change a Go module run a vulnerability check, and the check fails on a known-vulnerable fixture (negative control).
• The root module is scanned on a schedule, and a finding creates a visible failure.
• Every nested module is either scanned or listed as an exemption with its reason. An unlisted module fails the check rather than being skipped silently.
• The check documents how to resolve a finding.

Rough effort: Medium. Part of the security posture epic #2447.