Running go install with @latest builds and installs whatever version is newest at that moment, outside your project's go.mod. It is convenient and not reproducible. For tools that run in CI or touch your source, pin an exact version, or record the tool in go.mod, so every machine gets the same code.
What the command actually does
Per the Go modules reference, since Go 1.16 go install is the recommended way to build and install programs. When you add a version suffix such as @latest or @v1.4.6, the command builds in module-aware mode and ignores the go.mod file in the current directory or any parent directory.
That second part matters. Your project may pin a dependency at a known good release, but a tool installed with a version suffix is resolved on its own. The project's pins do not apply to it.
Why @latest is a risk for tools
A tool is code you run with your own permissions. Linters, code generators and test helpers read your source, and some write to it. If the newest release of a tool is broken or compromised, @latest pulls it in the next time anyone runs the command.
Two things still protect you. The go command checks downloaded modules against hashes and reports a security error on a mismatch, and it consults the checksum database when a hash is not in go.sum. Those checks confirm that the bytes match what was publicly recorded. They do not tell you the release is safe.
Three ways to pin a tool
| Approach | What it gives you | Trade off |
|---|---|---|
| Exact version in the command | Same version everywhere the command is copied | Easy to forget to update |
| Tool line in go.mod | Version recorded next to your other dependencies | Needs a recent Go release |
| Vendor or mirror the tool | Works offline and under your control | More maintenance |
An exact version looks like this:
go install golang.org/x/tools/gopls@v0.6.4
The Go reference documents a tool flag on go get that adds a matching tool line to go.mod. We cover that approach in go tool directive: pin dev tools in go.mod.
A short routine for teams
- Search your Makefile, CI files and README for
go installlines that end in @latest. - Replace each with an exact version.
- Put the versions in one place, so a bump is a single reviewed change.
- Scan the tool's own dependencies when you update it, the same way you scan your service.
- Run installs in CI from a clean cache at least occasionally, to catch a version that no longer resolves.
Treat a tool bump like a dependency bump: read the release notes, look at who maintains it, and review the diff in a pull request.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation cover Go modules, so tool dependencies recorded in go.mod show up in the same inventory as application ones. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice that anything not recorded in a manifest is missing from it, which is the gap an unpinned tool leaves.
Quick check
Does go install read my project's go.mod?
Not when you give it a version suffix. The Go reference says it builds in module-aware mode and ignores the go.mod file in the current directory or parents.
Does the checksum database make @latest safe?
No. It confirms the module bytes match the public record. It cannot judge whether a new release is trustworthy.
Sources
Last reviewed: 19 October 2026.
