ci: enforce govulncheck failures and centralize version#254
ci: enforce govulncheck failures and centralize version#254
Conversation
Remove continue-on-error: true from govulncheck steps in both ci.yml and security-scan.yml so vulnerability findings actually fail the build instead of being silently ignored. In ci.yml, also replace the hardcoded govulncheck@v1.1.4 with the centralized GOVULNCHECK_VERSION from versions.env (single source of truth), matching the pattern already used in security-scan.yml. Addresses review findings CICD-1 and CICD-3.
There was a problem hiding this comment.
Pull request overview
This PR strengthens the repository’s CI security posture by ensuring govulncheck findings fail workflows and by centralizing the govulncheck tool version in versions.env (consistent with the project’s existing “single source of truth” pattern).
Changes:
- Removed
continue-on-error: truefromgovulnchecksteps so vulnerability findings fail the workflow. - Updated CI to install
govulncheckusing${{ env.GOVULNCHECK_VERSION }}loaded fromversions.env. - Added a
versions.envload step to thesecurityjob inci.ymlto support the centralized version.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/workflows/security-scan.yml | Makes govulncheck results enforceable by removing continue-on-error. |
| .github/workflows/ci.yml | Loads versions.env, installs govulncheck via centralized version, and enforces scanner failures. |
CI Status NoteThe Vulnerabilities found (all Go stdlib — require Go version bump):
These are all in the Go standard library and will be resolved by bumping the Go toolchain version. The call chains trace through test utilities, generated apply configurations, and the webhook/controller code — but the root cause is the Go stdlib version, not application code. Recommendation: Merge this PR first (to enforce the check), then immediately follow up with a Go version bump PR. |
Summary
continue-on-error: truefrom govulncheck steps in bothci.ymlandsecurity-scan.ymlso vulnerability findings actually fail the build instead of being silently ignoredci.yml, replace hardcodedgovulncheck@v1.1.4with${{ env.GOVULNCHECK_VERSION }}loaded fromversions.env(single source of truth), matching the pattern already used insecurity-scan.ymlMotivation
Code review findings CICD-1 and CICD-3 identified that govulncheck was configured with
continue-on-error: truein both CI workflows, meaning vulnerability scan results were effectively ignored. This defeats the purpose of running the scanner.Changes
.github/workflows/security-scan.ymlcontinue-on-error: truefrom the "Run govulncheck" step.github/workflows/ci.ymlcontinue-on-error: truefrom the govulncheck stepgovulncheck@v1.1.4→govulncheck@${{ env.GOVULNCHECK_VERSION }}to use the centralized versionNotes
continue-on-error: trueon the Trivy SARIF upload step (not scan) is intentionally preserved — it exists because the upload may fail due to org security-events permission policy on forks