# golang.org/x/vuln and govulncheck: finding Go dependency flaws you actually call

> The golang/vuln module holds the client and tooling behind Go's vulnerability database, and its govulncheck command narrows dependency advisories to the symbols your code actually reaches. Its precision comes from a limitation you should understand before trusting a clean result.

**golang/vuln** — [mirror] the database client and tools for the Go vulnerability database

- Repository: https://github.com/golang/vuln
- Stars: 529 · Forks: 72
- Language: Go
- License: BSD-3-Clause
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/golang-vuln

## This is the module behind Go's official vulnerability workflow

The repository is described as a mirror of the database client and tools for the Go vulnerability database, and the module path is golang.org/x/vuln, which places it in the golang.org/x family of Go subrepositories. That matters because it is not a third-party scanner wearing a Go costume. The tooling it provides is backed by a database curated by the Go security team, and the API documentation for the scan package is published on pkg.go.dev alongside the rest of the standard library ecosystem. The target audience is Go developers who want to know whether a known vulnerability in a dependency affects the binary they are about to ship, not a general security team auditing an entire estate. The name to remember is govulncheck, since that is the command the module ships and the one you will actually run.

## Call-graph reachability is the whole point of the scanner

The documentation states that Go tooling reduces noise by only surfacing vulnerabilities in functions your code is actually calling. That single design decision is what separates govulncheck from a version-matching tool that reports every advisory touching any module in your dependency graph. A version match produces a wall of findings where most are irrelevant to the code path you ship. A reachability-based scan asks a narrower question: is there a path from an entry point in your program to the affected function? If the answer is no, the advisory is not reported. The consequence for a reader is important: a clean govulncheck run is a statement about reachable code, not a statement that no dependency in your graph is vulnerable. The scan package is where this analysis lives, and its documentation is linked from the repository as the place to look for the details of the mechanism.

## Installing govulncheck takes one go install command

Installation is a standard Go tool install, which means no Makefile, no system package, and no version pinning by default since the documentation points at the latest release. The command installs the govulncheck binary into the Go bin directory, which needs to be on your PATH for the next step to work. The project also links a tutorial on go.dev for a walkthrough, a broader page on Go vulnerability management at go.dev/security/vuln, and the scan package API documentation, so the repository itself is deliberately thin and points outward for the conceptual background.

```bash
go install golang.org/x/vuln/cmd/govulncheck@latest
```

## Running the scan inside a module and reading the output

The command is run from inside your Go module and takes package patterns, with the documented invocation scanning everything under the current directory. From there the tool analyzes your source, resolves the affected symbols in your dependencies, and reports the vulnerabilities your code can actually reach. It also works against compiled binaries rather than only source trees, which matters for the case where you ship a binary built by someone else's pipeline and want to check the artifact rather than the tree. The tutorial linked from the repository is the fastest way to get a working setup, and because the tool ships as part of the standard Go module ecosystem, it will be the same binary on every developer machine and in CI as long as the toolchain version lines up.

```bash
govulncheck ./...
```

## The privacy policy is a separate document worth reading

govulncheck has its own privacy policy published at vuln.go.dev/privacy, and the repository treats it as a first-class link rather than a footnote. The reason to care is architectural: the tool consults a vulnerability database that is served over the network, so a scan in a corporate environment can involve outbound requests and, depending on the mode you use, information about the code being analysed. A team with a strict egress policy or a source-code confidentiality rule should read that page and confirm the behaviour before adding the tool to a build pipeline. This is also the part of the Go vulnerability story that a scanner vendor, whose business depends on centralising your data, has no incentive to explain as clearly as a foundation project does. The licence section follows the same pattern of separating concerns, with a note on which data is covered by which terms.

## Two different licences cover the code and the data

The licensing is split in a way that reflects the two halves of the project. The Go source files are distributed under the BSD-style licence found in the LICENSE file, and the repository also carries a PATENTS file, which is standard for Go subrepositories. The database entries available at vuln.go.dev are a separate thing entirely: they are distributed under the terms of the CC-BY 4.0 licence. If you build a tool that consumes the database programmatically, or you redistribute vulnerability data in a product, you are in the CC-BY 4.0 territory rather than the BSD territory, and attribution is part of that. This is a licensing implication, not legal advice, but it is the kind of detail that matters to a platform team shipping an internal scanning service. The copyright and patent grant in the source tree, meanwhile, is the same broad model used across the Go project.

## Where the reachability model leaves gaps

Precision has a cost, and the cost is coverage. Because the tool reasons about call paths, any code that does not appear in a path the analysis can follow is a case the scanner cannot speak to, and the documentation here does not enumerate the situations where reachability analysis fails. Binary mode has a mirror problem: it works from the compiled artifact, so a finding may arrive with incomplete symbol information and no source location. The correct reading of a finding that carries no source location is that the tool could not connect the advisory to a line in your tree, not that the affected code is unreachable. The second limitation is scope: this is a Go module. A JavaScript frontend, a Python service and a Go binary in the same product will not be covered by the same scan, so a platform team still needs a separate story for its non-Go components.

## Repository layout, release history and upgrade cost

The tree is small and conventional for a Go subrepository: a cmd directory holding the command, an internal directory for unexported code, a scan directory for the public API, a doc directory, a go.mod and go.sum, and a codereview.cfg plus a CONTRIBUTING.md for the code review process. The go.mod declares a module path of golang.org/x/vuln with a go directive of 1.26.0, and it requires golang.org/x/tools, golang.org/x/mod, golang.org/x/sync and golang.org/x/telemetry, with a test dependency on go-cmdtest. The repository is not archived and the last push was on 2026-10-11. The tagged releases tell a different story, though: the newest is v1.1.4 from 2025-01-13, before v1.1.3 in July 2024 and v1.1.2 in June 2024. In other words the module path itself and the vulnerability database are active, while the tags on this code have been quiet for the better part of a year. If you pin a version, understand that pinning is pinning the client, not the data it retrieves.

## Conclusion

Adopt govulncheck if your team ships Go binaries and wants dependency advisories filtered by real call paths rather than by module version alone. Do not adopt it as a substitute for dependency updates, for scanning non-Go code, or as a proxy for a human review of business logic. Before you wire it into CI, read the privacy policy at vuln.go.dev/privacy to confirm the data the scan sends, decide whether you will run it in source mode or binary mode, and remember that a finding with no symbol information attached means the tool could not reach a conclusion, not that your code is safe.

## FAQ

### How do I install govulncheck?

Run go install golang.org/x/vuln/cmd/govulncheck@latest, which installs the command from the golang.org/x/vuln module. The binary lands in your Go bin directory, which has to be on your PATH before you can run it.

### What does govulncheck report that other scanners do not?

The documentation states that the tooling reduces noise by only surfacing vulnerabilities in functions your code is actually calling, rather than flagging every advisory that touches a module version in your dependency graph.

### Can govulncheck scan a compiled Go binary?

The tooling analyzes your codebase and binaries, and the scan package documentation is published at pkg.go.dev/golang.org/x/vuln/scan. When a binary is scanned, symbol information may be incomplete, so a finding without a source location means the tool could not map the advisory back to your code.

### What licence applies to govulncheck and to the vulnerability data?

The Go source files are distributed under the BSD-style licence in the LICENSE file, while the database entries available at vuln.go.dev are distributed under the terms of the CC-BY 4.0 licence. A separate privacy policy for govulncheck is published at vuln.go.dev/privacy.

## Sources

- [golang/vuln on GitHub](https://github.com/golang/vuln)
- [Issues](https://github.com/golang/vuln/issues)
- [License: BSD-3-Clause](https://github.com/golang/vuln/blob/master/LICENSE)
- [README](https://github.com/golang/vuln/blob/master/README.md)
- [Releases](https://github.com/golang/vuln/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/golang-vuln