Add govulncheck to CI for vulnerability scanning#921
Conversation
📝 WalkthroughWalkthroughThe PR adds a new ChangesVulnerability Check Job
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 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)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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 |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/go.yml (1)
3-14: ⚡ Quick winConsider adding a scheduled trigger for proactive vulnerability detection.
Currently,
govulncheckonly runs when Go files or dependencies change. Vulnerability databases are updated independently as new CVEs are disclosed, so unchanged dependencies can become vulnerable between code changes.Adding a scheduled trigger (e.g., weekly) would proactively detect newly disclosed vulnerabilities in your dependency tree, which is especially valuable for long-lived branches or between releases.
📅 Example: Add weekly scheduled scan
on: push: branches: [main] paths: - '**.go' - 'go.mod' - 'go.sum' pull_request: paths: - '**.go' - 'go.mod' - 'go.sum' + schedule: + # Run vulnerability check every Monday at 09:00 UTC + - cron: '0 9 * * 1'Note: Scheduled runs ignore the
pathsfilter and will run the entire workflow, butcontinue-on-error: trueensures only visibility without blocking.🤖 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/go.yml around lines 3 - 14, The workflow currently triggers govulncheck only on push/pull_request with a paths filter; add a weekly scheduled trigger by adding an on: schedule entry (e.g., cron: '0 0 * * 0' for weekly) so the workflow runs proactively, and ensure the govulncheck job/step (the job that runs govulncheck) is marked continue-on-error: true so scheduled runs report but do not block CI; keep the existing push/pull_request triggers and paths filter intact (scheduled runs will ignore paths).
🤖 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/go.yml:
- Line 161: In the vuln_check GitHub Actions job remove the "check-latest: true"
setting so the job uses the same pinned Go release as other jobs; ensure
vuln_check includes the same "go-version: '1.24'" and "cache: true" keys as
fmt/lint/test/test-race (or explicitly set "check-latest: false" if you prefer
keeping the key) to avoid version skew when running vulnerability scans.
---
Nitpick comments:
In @.github/workflows/go.yml:
- Around line 3-14: The workflow currently triggers govulncheck only on
push/pull_request with a paths filter; add a weekly scheduled trigger by adding
an on: schedule entry (e.g., cron: '0 0 * * 0' for weekly) so the workflow runs
proactively, and ensure the govulncheck job/step (the job that runs govulncheck)
is marked continue-on-error: true so scheduled runs report but do not block CI;
keep the existing push/pull_request triggers and paths filter intact (scheduled
runs will ignore paths).
🪄 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 Plus
Run ID: 2a9a5b54-21bb-4e63-8f09-8a99cd1477d0
📒 Files selected for processing (1)
.github/workflows/go.yml
| with: | ||
| go-version: '1.24' | ||
| cache: true | ||
| check-latest: true |
There was a problem hiding this comment.
Remove check-latest: true for version consistency across jobs.
The vuln_check job is the only one using check-latest: true, while other jobs (fmt, lint, test, test-race) use go-version: '1.24' with cache: true only. This can create version skew where vulnerability scanning runs on Go 1.24.x (latest patch) while tests run on Go 1.24.y (cached version).
For accurate vulnerability assessment, scan the same Go version used in tests and production.
🔧 Proposed fix to align with other jobs
- name: Install Go
uses: actions/setup-go@v5
with:
go-version: '1.24'
cache: true
- check-latest: true📝 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.
| check-latest: true | |
| - name: Install Go | |
| uses: actions/setup-go@v5 | |
| with: | |
| go-version: '1.24' | |
| cache: true |
🤖 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/go.yml at line 161, In the vuln_check GitHub Actions job
remove the "check-latest: true" setting so the job uses the same pinned Go
release as other jobs; ensure vuln_check includes the same "go-version: '1.24'"
and "cache: true" keys as fmt/lint/test/test-race (or explicitly set
"check-latest: false" if you prefer keeping the key) to avoid version skew when
running vulnerability scans.
uloamaka
changed the title
1 participant
vuln_checkjob to the CI workflow that runsgovulncheck ./...against the codebase on every push request to catch known CVEs in Go dependencies before they ship.Why
continue-on-errorflag:continue-on-error: trueadds visibility into vulnerabilities without blocking merges while the project remains on Go 1.24. Once the project bumps to Go 1.25,continue-on-errorcan be removed and the job becomes a hard gate.FIX: #884
Summary by CodeRabbit