Skip to content

Stop govulncheck-action from overriding pinned Go version#622

Open
filipelautert wants to merge 1 commit into
mainfrom
fix/govulncheck-scans-wrong-go-version
Open

Stop govulncheck-action from overriding pinned Go version#622
filipelautert wants to merge 1 commit into
mainfrom
fix/govulncheck-scans-wrong-go-version

Conversation

@filipelautert

Copy link
Copy Markdown
Collaborator

Problem

golang/govulncheck-action@v1.0.4 internally re-runs setup-go with go-version: stable, replacing the Go version we explicitly pinned. The module-level scan that follows it inherits the same PATH, 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:

GOTOOLCHAIN=go1.25.9 govulncheck -C cmd/sub -scan module
→ 8 vulnerabilities in stdlib@go1.25.9 (incl. all 5 from #619)

Run logs confirming the override on the 2026-05-12 nightly (pre-#619 merge):

Acquiring 1.26.3 from https://github.com/actions/go-versions/...
GOROOT='/opt/hostedtoolcache/go/1.26.3/x64'
...
No vulnerabilities found.

Workflow had asked for 1.25.9; scan ran against 1.26.3.

Fix

Install govulncheck directly with go install and invoke it against the Go version that actions/setup-go set up. No transitive action, no surprise version override.

Test plan

  • CI on this PR: both govulncheck ./... and govulncheck -C cmd/lpm -scan module run against Go 1.25.10
  • No vulnerabilities reported (1.25.10 is patched for the published stdlib CVEs)
  • SARIF upload to GitHub Security tab still succeeds
  • Next nightly run confirms the same

@coderabbitai

coderabbitai Bot commented May 12, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ebbb98b0-6f26-444c-92f9-92f773efadc8

📥 Commits

Reviewing files that changed from the base of the PR and between 4e67d2a and 584135f.

📒 Files selected for processing (1)
  • .github/workflows/govulncheck.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/govulncheck.yml

📝 Walkthrough

Walkthrough

The PR updates the govulncheck workflow to install govulncheck directly with Go and run it as a command. The module-level scan, SARIF generation, and upload steps are unchanged.

Changes

Govulncheck workflow update

Layer / File(s) Summary
Direct govulncheck installation and execution
.github/workflows/govulncheck.yml
The symbol-level govulncheck step now installs golang.org/x/vuln/cmd/govulncheck@latest and runs govulncheck ./... directly instead of using golang/govulncheck-action@v1.0.4.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

Suggested labels

go

Suggested reviewers

  • jandroav
  • sayaliM0412
  • jnewton03
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly matches the main change: replacing govulncheck-action to prevent Go version overrides.
Description check ✅ Passed The description directly explains the version override issue and the workflow fix, matching the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/govulncheck-scans-wrong-go-version

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@CLAassistant

CLAassistant commented May 12, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@claude

claude Bot commented May 12, 2026

Copy link
Copy Markdown

Claude finished @filipelautert's task in 26s —— View job


Code Review

Summary: Excellent fix. The change correctly addresses the silent CVE scanning issue by removing the problematic govulncheck-action (which internally overrides the pinned Go version) and replacing it with direct go install + CLI invocation.

Changes Overview:

  • Removes golang/govulncheck-action@v1.0.4 which was internally re-running setup-go with go-version: stable
  • Adds explicit go install golang.org/x/vuln/cmd/govulncheck@latest step
  • Changes symbol-level scan from action to direct CLI: govulncheck ./...
  • Module-level scan was already using direct CLI (unchanged)

Strengths:

  1. Correct diagnosis: Root cause (action overriding pinned version) is clearly documented in the comment
  2. Clean implementation: Direct install inherits the PATH from the already-configured Go 1.25.10
  3. Minimal changes: Only modifies what's necessary; SARIF upload logic unchanged
  4. Preserves functionality: Both symbol and module scans remain, with proper error handling for SARIF generation

Notes:

  • Using @latest for govulncheck is appropriate for a security scanner (ensures latest vulnerability data)
  • The || true on the SARIF generation step correctly handles cases where scans report no vulnerabilities

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.


Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.4 with a direct go install of govulncheck and runs govulncheck commands 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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@filipelautert :could we use a SHA here instead of @latest

@filipelautert filipelautert requested a review from sayaliM0412 May 12, 2026 21:16
@filipelautert filipelautert force-pushed the fix/govulncheck-scans-wrong-go-version branch from ac3127f to 4e67d2a Compare May 13, 2026 14:52
@claude

claude Bot commented May 13, 2026

Copy link
Copy Markdown

Claude finished @filipelautert's task in 34s —— View job


Code Review

Summary: The fix correctly addresses the root cause (govulncheck-action overriding the pinned Go version), but introduces a supply-chain risk by using @latest for govulncheck.

Findings

  • Fix is correct: Replacing the action with direct go install + CLI invocation ensures scans run against the pinned Go 1.25.10, not an unexpected "stable" version.
  • Non-determinism risk: Using @latest for govulncheck makes the workflow unpredictable—the version changes as releases happen. This contradicts the deterministic versioning used elsewhere in this workflow (all action SHAs are pinned).
  • Supply-chain risk: You're implicitly trusting that each new govulncheck release is safe and won't change scanning behavior. Pin to a specific version tag (e.g., @v0.2.0) or SHA instead.
  • Implementation otherwise sound: Both symbol-level and module-level scans remain intact, error handling for SARIF generation is correct, and upload logic unchanged.
  • Reviewers' concern valid: Two reviewers already flagged this—pinning is the right approach here.

Recommendation

Replace @latest with a specific release tag or commit SHA (check golang.org/x/vuln releases for current stable version).


# 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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@sonarqubecloud

Copy link
Copy Markdown

Quality Gate Failed Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 4f5e799 and 4e67d2a.

📒 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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 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 20

Repository: 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.

Suggested change
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.

See more on https://sonarcloud.io/project/issues?id=liquibase_liquibase-package-manager&issues=AZ4d9TXQG_SzeXAES_uw&open=AZ4d9TXQG_SzeXAES_uw&pullRequest=622

🤖 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.
@filipelautert filipelautert force-pushed the fix/govulncheck-scans-wrong-go-version branch from 4e67d2a to 584135f Compare June 25, 2026 14:49
@claude

claude Bot commented Jun 25, 2026

Copy link
Copy Markdown

Claude finished @filipelautert's task in 48s —— View job


Code Review

Summary

The PR correctly fixes the root cause of the CVE scanning issue by removing golang/govulncheck-action (which was silently overriding the pinned Go version) and replacing it with direct go install + CLI invocation. The core logic is sound and the detailed comment explaining the fix is excellent.

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 @latest for govulncheck makes the workflow non-deterministic and introduces supply-chain risk.

- name: Install govulncheck
  run: go install golang.org/x/vuln/cmd/govulncheck@latest  # ← @latest is problematic

Why this is a problem:

  1. Inconsistent with repo standards: All other GitHub Actions in this workflow use pinned SHAs:

    • actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
    • actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c
    • github/codeql-action/upload-sarif@c10b8064de6f491fea524254123dbe5e09572f13
  2. Unpredictable scan results: The workflow's behavior changes as new govulncheck releases happen, even with no repo changes. This can mask or falsely report vulnerabilities.

  3. Supply-chain risk: You're implicitly trusting each new govulncheck release without explicit review. A malicious or broken release could change scanning behavior.

  4. Debugging difficulty: If a scheduled scan suddenly starts reporting different results, it's unclear whether the repo changed or the tool changed.

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 tag

Correctness & Safety: ✓ Passed

  • Logic: Correct. The go install inherits the PATH from the preceding setup-go step, so scans run against Go 1.25.11 as intended.
  • Error handling: Proper. SARIF generation uses || true, and the upload step has if: always().
  • Test plan: Reasonable for a CI change. The PR description includes verification steps.

Maintainability & Standards: ✓ Passed (except for the major issue above)

  • Documentation: Excellent. The comment explaining why govulncheck-action was problematic is clear and detailed.
  • No breaking changes: Both symbol-level and module-level scans remain; only the invocation method changed.

Checklist

  • Correctness: Logic is sound, no off-by-one or inverted conditions.
  • Error handling: Properly configured with || true and if: always().
  • Security: No secrets, injection, or unsafe operations in the workflow itself. (The @latest is a deployment-time supply-chain concern, not code-level.)
  • Test coverage: CI change; test plan is adequate.
  • Public API/contract stability: No impact; CI internal change.
  • Concurrency/resources: No issues; standard workflow steps.
  • Repo standards (CLAUDE.md): BLOCKED on the @latest pin issue.

Recommendation

Do not merge until the @latest is replaced with a pinned version. The core fix is correct, but the non-deterministic tool version contradicts the repo's established practice and introduces avoidable risk. This should take <1 minute to fix.

Confidence: 30% production-ready as-is. The fix addresses the real issue, but the implementation choice introduces new risk that reviewers have already identified.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants