ci(security): add govulncheck supply-chain scanning to validate-go-project#266
Merged
Conversation
…oject Add a govulncheck job to the shared validate-go-project reusable workflow so every Go consumer (go-template, ksail, ...) inherits known-vulnerability scanning on each PR. Mirrors the read-only deadcode job (changes-gated, pull_request-only, contents: read; tool pinned by version). govulncheck uses call-graph reachability — it blocks (exit 3) only on vulnerabilities the code actually calls, so imported-but-unreachable advisories don't fail the gate, keeping false positives near zero. README + AGENTS.md updated to list the step. Fixes #265 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
Adds supply-chain vulnerability scanning to the shared Go validation reusable workflow so Go consumer repositories inherit govulncheck on PRs, and updates docs to reflect the new capability.
Changes:
- Added a
govulncheckjob to.github/workflows/validate-go-project.yaml(changes-gated, PR-only, read-only permissions). - Updated README feature list to include supply-chain scanning via
govulncheck. - Updated
AGENTS.mdworkflow inventory description to mention vuln scanning.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| README.md | Documents govulncheck as a Validate Go Project feature. |
| AGENTS.md | Updates workflow inventory description to include vuln scanning. |
| .github/workflows/validate-go-project.yaml | Introduces the govulncheck job to scan ./... for reachable known vulnerabilities. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Per AGENTS.md every reusable-workflow job leads with step-security/harden-runner (egress-policy: audit). Aligns the new job with the documented convention. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 tasks
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![botantler[bot]](https://avatars.githubusercontent.com/in/1025824?s=60&v=4){kind=small}
Contributor
|
🎉 This PR is included in version 5.3.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This was referenced Jun 1, 2026
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
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.
Fixes #265.
What
Adds a
govulncheckjob to the sharedvalidate-go-project.yamlreusable workflow, so every devantler-tech Go consumer (go-template, ksail, …) inherits supply-chain / known-vulnerability scanning on each PR. Until now the workflow ran lint, dead-code, build, test, and coverage — but nothing checked dependencies againstvuln.go.dev.This closes the last gap flagged in the go-template roadmap #75, which concluded
govulncheck"belongs onreusable-workflows… so every Go consumer inherits it."How
govulncheckjob mirrors the existing read-onlydeadcodejob:changes-gated,pull_request-only,permissions: { contents: read }, sets up Go fromgo.mod.golang.org/x/vuln/cmd/govulncheck@v1.3.0(pinned by version, same convention asdeadcode@v0.43.0) and runsgovulncheck ./....AGENTS.mdinventory updated to name the step (docs in sync).Why it's safe to roll out
govulncheckuses call-graph reachability — it fails (exit 3) only on vulnerabilities the code actually calls; imported-but-unreachable advisories return exit 0 and don't block. Near-zero false positives.Validated locally (govulncheck v1.3.0 / Go 1.26.3):
No vulnerabilities found.→ exit 0 (pass)jwt-goMapClaims.VerifyAudience, GO-2020-0017)Your code is affected by 1 vulnerability→ exit 3 (block)your code doesn't appear to call these→ exit 0 (no false-block)actionlint+yamllintclean on the changed workflow (the onlyactionlintfinding is the pre-existingcode-quality-scope false positive on the unrelatedcoveragejob, already ignored via mega-linter's-ignore code-quality). The workflow is unchanged on thereusable-workflowsrepo itself (all jobs skip here via the existing repo guard; the[Test] Validate Go Projectjob confirms it stays callable).Blast radius — flagged for the promotion decision
Additive but impactful: this is a new required check on every Go consumer's PRs. A consumer whose code reaches a known vulnerability will see this job fail until the affected module is bumped (or the call removed) — the intended supply-chain-security behavior. No consumer-side wiring change is needed (the called workflow fails as a unit). Shipping as a draft; promoting it is the deliberate decision to enable the gate across all Go repos.