How do you vet a Go module before adding it to your project?

Before adding a Go module, look it up in the Go vulnerability database through govulncheck, check whether versions are retracted or deprecated, read what else it pulls in, and review its source for surprises. Then commit go.mod and go.sum so the exact version you reviewed is the one that builds.

What does govulncheck tell you?

Go's vulnerability data comes from the National Vulnerability Database, the GitHub Advisory Database and package maintainers. The Go Security team reviews and curates entries in the vuln.go.dev database, which uses the OSV format.

govulncheck analyzes your code and, per the Go docs, reports only vulnerabilities that affect you, by checking whether functions in your code transitively call vulnerable functions. Run it like this:

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

Two limits to know. The database does not use labels like LOW or CRITICAL, because Go treats impact as context dependent. And the page describes the project as a work in progress. A clean result means nothing known applies, not that nothing is wrong.

What do retractions and deprecations add?

The module reference describes go list -m -u, which marks modules with newer versions and reports whether the current version is retracted or deprecated. Its sample output shows entries such as a deprecated module and a retracted version with the newer version in brackets.

A maintainer uses the retract directive to say a version should not be used. Retracted versions are not chosen automatically by go get or go mod tidy, though existing builds that depend on them keep working. So if you inspect a candidate and see retracted releases, find out why. Published by accident is one reason the docs give; others may be more serious.

How do you see what a module drags in?

Adding one module can add many. Go's go mod graph and go mod why commands show the requirement graph and why a package is needed, though the portion of the module reference we read did not cover them, so treat that as something to confirm in the docs. A simple check: add the module on a branch, run go mod tidy, and read the diff to go.mod and go.sum before merging. A constructed example: a small helper library adds a dozen new indirect modules, one of them a networking package your team has never used. That is worth a conversation.

What about where it comes from?

GOPROXY is a comma separated list of proxy URLs, or the keywords direct and off. GOPRIVATE and GONOPROXY also control behavior. A company can point GOPROXY at its own server first, which gives you a place to enforce review. Read the exact semantics in the module reference before relying on them.

What do you read in the source?

Skim, in this order: the init functions and package level variables, anything that runs at import time; network calls, process execution and file writes; build tags and cgo; and recent commit history for ownership changes. Look at the repository, not only the published module, and check they match.

What to do

1. Run govulncheck on a branch that adds the module.
2. Run go list -m -u all and look for retracted or deprecated entries.
3. Read the go.mod and go.sum diff after go mod tidy, and note every new indirect module.
4. Review import time code and anything touching the network or the shell.
5. Check maintainer activity and recent ownership changes in the repository.
6. Commit go.mod and go.sum together, and keep the default read-only build mode (-mod=readonly has been the default since Go 1.16).
7. Re-run govulncheck in CI so new advisories surface later.

Safeguard can scan Go modules, generate an SBOM, and use reachability analysis to show whether a flagged function is called. The Gold open source Chrome extension also supports package lookups.

Quick check

Sources

• Go vulnerability management (fetched 18 October 2026)
• Go modules reference (first 100,000 characters fetched 18 October 2026)

Last reviewed: 18 October 2026.