Stop govulncheck-action from overriding pinned Go version#622
Stop govulncheck-action from overriding pinned Go version#622filipelautert wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe PR updates the govulncheck workflow to install ChangesGovulncheck workflow update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Claude finished @filipelautert's task in 26s —— View job Code ReviewSummary: Excellent fix. The change correctly addresses the silent CVE scanning issue by removing the problematic Changes Overview:
Strengths:
Notes:
Blockers: The PR has a CLA signature requirement (shown in comments) that will need to be resolved before merge, but that's separate from code review. |
There was a problem hiding this comment.
Pull request overview
Updates the govulncheck GitHub Actions workflow to ensure vulnerability scans run using the repository’s pinned Go toolchain, avoiding golang/govulncheck-action re-invoking setup-go with go-version: stable and silently scanning with a different Go version than CI builds/releases.
Changes:
- Replaces
golang/govulncheck-action@v1.0.4with a directgo installofgovulncheckand runsgovulncheckcommands explicitly. - Keeps both symbol-level and module-level scans, now executed under the pinned Go toolchain.
- Continues generating and uploading a SARIF report to the GitHub Security tab.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # against whatever Go is "stable" today — not the version this repo pins. That | ||
| # mismatch let 5 stdlib CVEs ship in #619 with the scan reporting "no vulns". | ||
| - name: Install govulncheck | ||
| run: go install golang.org/x/vuln/cmd/govulncheck@latest |
There was a problem hiding this comment.
@filipelautert :could we use a SHA here instead of @latest
ac3127f to
4e67d2a
Compare
|
Claude finished @filipelautert's task in 34s —— View job Code ReviewSummary: The fix correctly addresses the root cause (govulncheck-action overriding the pinned Go version), but introduces a supply-chain risk by using Findings
RecommendationReplace |
| # against whatever Go is "stable" today — not the version this repo pins. That | ||
| # mismatch let 5 stdlib CVEs ship in #619 with the scan reporting "no vulns". | ||
| - name: Install govulncheck | ||
| run: go install golang.org/x/vuln/cmd/govulncheck@latest |
There was a problem hiding this comment.
Using @latest makes this workflow non-deterministic and introduces supply-chain risk—the version changes unpredictably as releases happen. Pin to a specific release tag (e.g., @v0.2.0) or SHA instead, consistent with your approach of pinning other action versions in this workflow.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/govulncheck.yml:
- Line 30: The workflow currently installs govulncheck with go install
golang.org/x/vuln/cmd/govulncheck@latest which makes scans nondeterministic;
change that to pin an explicit version string (for example `@v0.X.Y`) so the CI
uses a fixed govulncheck release. Update the run step that invokes govulncheck
(the line containing "go install golang.org/x/vuln/cmd/govulncheck@latest") to
use a specific tag instead of `@latest` and commit the workflow change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c800dda5-8366-41df-84ad-f32d94a6237b
📒 Files selected for processing (1)
.github/workflows/govulncheck.yml
| # against whatever Go is "stable" today — not the version this repo pins. That | ||
| # mismatch let 5 stdlib CVEs ship in #619 with the scan reporting "no vulns". | ||
| - name: Install govulncheck | ||
| run: go install golang.org/x/vuln/cmd/govulncheck@latest |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the workflow currently uses a floating govulncheck version
rg -n --type=yaml 'go install\s+golang\.org/x/vuln/cmd/govulncheck@latest'
# List available tagged versions to pick a pin
curl -fsSL https://proxy.golang.org/golang.org/x/vuln/@v/list | tail -n 20Repository: liquibase/liquibase-package-manager
Length of output: 177
🏁 Script executed:
cat -n .github/workflows/govulncheck.yml | sed -n '20,40p'Repository: liquibase/liquibase-package-manager
Length of output: 1404
Pin govulncheck to an explicit version instead of @latest.
Using @latest makes the security scan nondeterministic across runs and can change findings without any repo change. Pin the tool version to keep CI reproducible and reliable for a critical security gate.
Suggested change
+ - name: Set govulncheck version
+ run: echo "GOVULNCHECK_VERSION=v1.3.0" >> "$GITHUB_ENV"
+
- name: Install govulncheck
- run: go install golang.org/x/vuln/cmd/govulncheck@latest
+ run: go install golang.org/x/vuln/cmd/govulncheck@${GOVULNCHECK_VERSION}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| run: go install golang.org/x/vuln/cmd/govulncheck@latest | |
| - name: Set govulncheck version | |
| run: echo "GOVULNCHECK_VERSION=v1.3.0" >> "$GITHUB_ENV" | |
| - name: Install govulncheck | |
| run: go install golang.org/x/vuln/cmd/govulncheck@${GOVULNCHECK_VERSION} |
🧰 Tools
🪛 GitHub Check: SonarCloud Code Analysis
[warning] 30-30: Dependency versions are not predictable. Use a lock-file enforcing command instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/govulncheck.yml at line 30, The workflow currently
installs govulncheck with go install golang.org/x/vuln/cmd/govulncheck@latest
which makes scans nondeterministic; change that to pin an explicit version
string (for example `@v0.X.Y`) so the CI uses a fixed govulncheck release. Update
the run step that invokes govulncheck (the line containing "go install
golang.org/x/vuln/cmd/govulncheck@latest") to use a specific tag instead of
`@latest` and commit the workflow change.
golang/govulncheck-action@v1.0.4 internally runs setup-go with `go-version: stable`, replacing the 1.25.10 we just installed and scanning against whatever stable resolves to. That mismatch caused the 2026-05-07 stdlib CVEs to ship undetected — they were patched in 1.25.10 but stable already had them, so the scan said "no vulnerabilities found". Trivy caught the gap on the compiled binary in #619. Install govulncheck directly and invoke it against the Go we pinned, so the scan reflects what we actually ship.
4e67d2a to
584135f
Compare
|
Claude finished @filipelautert's task in 48s —— View job Code ReviewSummaryThe PR correctly fixes the root cause of the CVE scanning issue by removing However: The implementation introduces a non-determinism and supply-chain risk that contradicts the repo's established pinning practices. This issue has been flagged by multiple reviewers and must be addressed. [Major] Non-deterministic govulncheck version (Line 30)Issue: Using - name: Install govulncheck
run: go install golang.org/x/vuln/cmd/govulncheck@latest # ← @latest is problematicWhy this is a problem:
Recommendation: Pin to a specific version tag (check golang.org/x/vuln releases) and update intentionally when needed. For example: - name: Install govulncheck
run: go install golang.org/x/vuln/cmd/govulncheck@v1.3.0 # or similar stable tagCorrectness & Safety: ✓ Passed
Maintainability & Standards: ✓ Passed (except for the major issue above)
Checklist
RecommendationDo not merge until the Confidence: 30% production-ready as-is. The fix addresses the real issue, but the implementation choice introduces new risk that reviewers have already identified. |




Problem
golang/govulncheck-action@v1.0.4internally re-runssetup-gowithgo-version: stable, replacing the Go version we explicitly pinned. The module-level scan that follows it inherits the samePATH, so both scans end up running against "whatever stable is today" — not the Go we actually build with.This silently masked the 5 stdlib CVEs that #619 had to patch by hand. Each scheduled scan reported "No vulnerabilities found" while the released binary was vulnerable; Trivy / Docker Scout caught the gap because they inspect the compiled binary's stdlib version.
Reproduced locally against the same module setup the CI uses:
Run logs confirming the override on the 2026-05-12 nightly (pre-#619 merge):
Workflow had asked for 1.25.9; scan ran against 1.26.3.
Fix
Install govulncheck directly with
go installand invoke it against the Go version thatactions/setup-goset up. No transitive action, no surprise version override.Test plan
govulncheck ./...andgovulncheck -C cmd/lpm -scan modulerun against Go 1.25.10