govulncheck has no way to silence a finding. Its documentation says so directly. To accept a Go finding on purpose, keep a separate exceptions file with the advisory ID, reason, owner and review date, then compare it with govulncheck's JSON or OpenVEX output in CI.
What the documentation says
The govulncheck page lists its limitations. One of them reads: there is no support for silencing vulnerability findings. It points to a Go issue for updates. Nothing here is a flaw in your setup. It is a current limit of the tool.
Two more details from the same page shape the workaround:
- Output formats include JSON, SARIF and OpenVEX.
- Exit codes: govulncheck exits with code 0 when there are no vulnerabilities and unsuccessfully when there are. But with the JSON, SARIF or OpenVEX format selected, it exits successfully regardless of how many vulnerabilities it finds.
That second point catches teams out. If you switch to machine readable output to post-process results, a CI step that relies on the exit code will pass even when findings exist.
Why you still need exceptions
Some findings are real but cannot be fixed today. The fix may need a major upgrade, or the vulnerable function may not be called. Without a way to record that, a team either lets the build stay red or stops running the scan. Both are worse than a tracked exception.
A simple exceptions file
Keep a small file in the repository, reviewed like code.
| Field | Purpose |
|---|---|
| id | The advisory ID from the report |
| module | The module and version affected |
| reason | One sentence, with the evidence |
| owner | A person or team |
| review_by | A date, after which the entry fails the build |
A date that fails the build is the key idea. An exception without an expiry becomes a permanent blind spot.
How to wire it into CI
- Run govulncheck with JSON output and save the result.
- Extract the advisory IDs of findings that were reported.
- Remove the IDs listed in the exceptions file whose review date has not passed.
- If anything remains, fail the step. Do the check yourself, because the tool's exit code will not do it in these output modes.
- Fail on any exception past its review date, so someone reads it again.
Keep the script short and test it with a sample report, so a format change shows up as a failure rather than a silent pass.
Use the OpenVEX output carefully
govulncheck can write OpenVEX. That is useful for sharing results with consumers. But a VEX document states exploitability for a product, so do not hand edit it to hide a finding without evidence. See VEX justifications for unreachable code.
Know the limits of the signal
The same documentation says reflection calls are not visible to static analysis, and that conservative handling of function pointers and interface calls can produce false positives. So an exception based on "not reachable" should carry a re-check date. For wider context, see what reachability analysis cannot tell you.
Quick check
Can I add a comment in the code to silence govulncheck?
Not according to its documentation, which lists lack of silencing support as a limitation. Track exceptions outside the tool.
Why did my CI pass with findings present?
If you used JSON, SARIF or OpenVEX output, govulncheck exits successfully regardless of the number of findings. Check the output yourself.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
Last reviewed: 19 October 2026.
