build: make the main module version readable by image scanners - #4486
build: make the main module version readable by image scanners#4486stevenvegt wants to merge 1 commit into
Conversation
Trivy only reads a version from -ldflags when the -X key ends in ".version", so core.GitVersion was ignored and the nuts-node module showed up without a version in Trivy scans of the image. Rename the variable to core.Version (and the Version() func to VersionOrBranch()) so both Trivy and Syft pick it up. Build with -buildvcs=false: the module path has no /v6 suffix, so Go cannot derive the version from the v6.x tags and stamps a pseudo-version (v0.0.0-<time>-<rev> on the release binaries) that scanners rank against old advisories. The ldflag is the intended source of the version. Derive the version in the image workflow from the tag ref instead of git name-rev, so it is always a clean vX.Y.Z on tag builds and "undefined" otherwise. Refs #4485 Assisted-by: AI
0 new issues
|
|
Coverage Impact This PR will not change total coverage. Modified Files with Diff Coverage (3)
🤖 Increase coverage with AI coding...🚦 See full report on Qlty Cloud » 🛟 Help
|
|
Converted to draft. #4487 (module path rename on V6.2) supersedes this PR: once the module path carries the /v6 suffix, go build stamps the version from the tag itself and scanners read it from the build info, so the ldflags key and -buildvcs=false here are no longer needed. The -buildvcs=false flag would even block that stamping. If #4487 is approved and ported to master, close this PR. If #4487 is rejected, this PR is the fallback and can be marked ready again. |
1 participant
Docker image scanners could not read the version of the nuts-node main module from the image. Trivy showed no version at all, because it only reads
-Xldflag keys ending in.versionand ours wascore.GitVersion. The GitHub release binaries carryv0.0.0-<time>-<rev>, stamped by Go's VCS support, because the module path without/v6makes the v6.x tags invalid module versions.Changes:
core.GitVersiontocore.Version, so the ldflag key ends in.version. That name was taken by the functioncore.Version(), and a Go package cannot have a variable and a function with the same name, so the function is renamed tocore.VersionOrBranch(). Its behaviour is unchanged: it returns the tagged version if set, otherwise the branch. Tests updated.-buildvcs=falsein the Dockerfile, makefile and binaries workflow, so no pseudo-version can be stamped. The ldflag is the intended source of the version.GITHUB_REF_TYPEandGITHUB_REF_NAMEinstead ofgit name-rev, so tag builds get a cleanvX.Y.Zand everything else getsundefined.Verified on a binary built with the new flags: Trivy and Syft both report
pkg:golang/github.com/nuts-foundation/nuts-node@v6.2.10. Before the change Trivy reported no version for the published 6.2.10 image.This does not make advisories match yet. Both GitHub and the Go vulnerability database store our advisory ranges as "up to 1.1.0" or "all versions", because the module path has no major version suffix. See #4485 for that.
Related: #4451 attaches the SBOM to the image; this PR fixes what that SBOM says about the nuts-node module. The two are independent and touch neighbouring lines of
build-images.yaml, so whichever merges second needs a trivial rebase.