security: build uses a stale Go patch and lacks govulncheck, image-scan, and SBOM gates

[dcmcand]

Summary

The module declares an older Go patch release, the builder image tracks a mutable minor tag, and the build has no vulnerability, image-scan, or SBOM gate. The exact compiler is not established by source, and no step checks the source or final binary for known vulnerabilities.

Affected code

• go.mod (L3) - go 1.25.6, with no toolchain directive. Newer 1.25.x patch releases with security fixes exist.
• Dockerfile (L2) - FROM golang:1.25, a mutable minor tag, so the exact compiler patch is chosen at build time.
• .github/workflows/release.yml (L35-47) and .github/workflows/build-pr.yml (fmt/vet L47-53, lint L56-58, test L96) run tests, vet, and lint but no security scan. A grep across workflows, .goreleaser.yml, Dockerfiles, and the Makefile for govulncheck|trivy|grype|syft|sbom|scan returns nothing.

This finding does not claim that a specific Go advisory is reachable by the operator; it is about missing build-time gates and version currency.

Impact

Without a compiler floor and vulnerability gates, a build can ship with an out-of-date compiler and undetected vulnerable dependencies, and there is no automated signal when a known-vulnerable dependency or compiler is in use.

Remediation

• Build with a current supported Go security patch, and pin the compiler image by exact version and digest.
• Run govulncheck against source and compiled binaries as a release gate.
• Scan the final runtime image, publish an SBOM, and record the compiler identity in provenance.
• Define and enforce a maximum compiler patch age.

Acceptance criteria

• Source, binary, and final-image security scans run in CI and meet documented thresholds.
• The compiler version and digest are pinned and recorded in provenance.

References

• CWE-1104 (Use of Unmaintained Third-Party Components)

Line numbers reference commit 4ad2c10.