ci: pin govulncheck to v1.6.0, narrow release.yml permissions to contents: read - #607
Closed
chethanuk wants to merge 1 commit into
Closed
ci: pin govulncheck to v1.6.0, narrow release.yml permissions to contents: read#607chethanuk wants to merge 1 commit into
chethanuk wants to merge 1 commit into
Conversation
Pin govulncheck to v1.6.0 instead of @latest. The argument is reproducibility, not supply chain: golang.org/x/vuln is the Go team's own module and go install is already checksum-verified via GOSUMDB. What @latest costs is a new govulncheck release turning CI red on an unchanged tree. This gate is load-bearing - e6e5da0 bumped the Go image to fix GO-2026-5856 after govulncheck caught it - so protecting it from unrelated churn is worth a pin. Pinning costs nothing in scan freshness: the vulnerability database is fetched at runtime, independently of the binary version. Verified: Scanner govulncheck@v1.6.0, DB updated 2026-07-08, no vulnerabilities, exit 0. Narrow release.yml's workflow-level permissions from contents: write to contents: read. Only the build job inherits it, and it only checks out and uploads artifacts - upload-artifact authenticates with ACTIONS_RUNTIME_TOKEN, not GITHUB_TOKEN. The release and npm-publish jobs declare their own job-level permissions, which replace the inherited set entirely, so both are unaffected. Verified with actionlint (clean across all workflows) and by confirming the release.yml still parses as YAML.
Contributor
|
✅ OpenCodeReview: No comments generated. Looks good to me. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Two one-line CI changes, split out of #473 so that PR stays single-purpose.
ci.yml:51installed govulncheck with@latest. Not a supply-chain hole:golang.org/x/vulnis the Go team's own module andgo installverifies it through GOSUMDB. What@latestactually costs is a govulncheck release turning CI red on an unchanged tree, and two runs of the same commit scanning with different binaries. This gate is load-bearing — e6e5da0 bumped the Go image to fix GO-2026-5856 because govulncheck caught it — so it's worth protecting from unrelated churn. Pinned tov1.6.0.The pin does not make the scan stale. The vulnerability database is fetched at runtime, independent of the binary version:
release.yml:8requested workflow-levelcontents: write.contents: readcovers it. Only thebuildjob inherits the workflow-level set, and it checks out, builds, and uploads artifacts —upload-artifactauthenticates withACTIONS_RUNTIME_TOKEN, notGITHUB_TOKEN.releasedeclares its owncontents: write/id-token: write/attestations: writeandnpm-publishdeclarescontents: read; job-level permissions replace the inherited set rather than adding to it, so neither job changes behaviour.Limitations
A pin needs a manual bump;
@latestdid not.release.ymlonly triggers onv*tags, so this can't be exercised before the next release — thatbuilddoesn't need write access is read off the job definition, not observed on a real run.Type of Change
How Has This Been Tested?
make testpasses locally (three consecutive-raceruns)govulncheck ./...at the pinnedv1.6.0— exit 0, no vulnerabilities; confirmedyaml.safe_loadparses both changed workflows; readrelease.ymlto confirmbuildis the only job inheriting the workflow-level permissionsChecklist
go fmt,go vet)Related Issues
Split out of #473.
AI assistance: Claude Code helped research and verify this change. I reviewed the full diff and take responsibility for it.