How do you list every package in a Go build that imports unsafe or os/exec, or uses cgo?

## What `-deps` gives you that nothing else does `go list` without flags prints the packages you named. With `-deps`, it prints those packages *plus every package they transitively import*, in dependency order (dependencies before dependents), and it includes the standard library. That list is the compile-time truth: it is the set of packages the toolchain will build and link. Compared with `go.mod`, which records module version constraints, and `go mod graph`, which records requirement edges, `-deps` is the only one of the three that answers "what code ends up in the binary". ## Templating over package fields `go list -f` takes a text template evaluated against a structure describing each package. The fields worth knowing for review are: - `.ImportPath` — the package's full path. - `.Imports` — the package's direct imports, as a list. `join` is available as a template function. - `.Deps` — the transitive import closure of that one package. - `.CgoFiles` — the `.go` files in the package that import `"C"`. Non-empty means the package uses cgo. - `.Standard` — whether the package is part of the standard library. - `.Module` — the module the package came from, with path and version. So the capability sweep is one command: ``` go list -deps -f '{{if not .Standard}}{{.ImportPath}} {{join .Imports " "}}{{end}}' ./... ``` Pipe that through a filter for the import paths you care about. And cgo is its own field: ``` go list -deps -f '{{if .CgoFiles}}{{.ImportPath}}{{end}}' ./... ``` For anything that needs to be parsed rather than eyeballed, `go list -deps -json ./...` emits the same records as a JSON stream. ## Why the three signals are worth separating **`unsafe`** disables the type and memory safety the rest of the language guarantees: pointer arithmetic through `unsafe.Pointer`, reinterpreting one type's memory as another, building slices and strings over arbitrary addresses. It is not automatically wrong — the standard library uses it heavily, `reflect` cannot exist without it, and high-performance libraries use it correctly — but it means correctness now rests on invariants the compiler is not checking, and mistakes there produce memory corruption rather than a panic at the fault site. `go vet`'s `unsafeptr` check catches one specific misuse (converting `uintptr` back to `unsafe.Pointer`), not the general case. **cgo** changes your build, not just your risk. It requires a C toolchain, complicates or blocks cross-compilation, and the race detector does not see inside the C code. A crash on the C side is not a Go panic and does not produce a Go stack trace. **`os/exec`** means the package runs external programs, which is a runtime dependency that `go.mod` does not record and the compiler cannot check — the missing tool is discovered in production. ## Turning it into a review gate The useful form of this is not a one-off command but a diff. `unsafe` is transitively reachable from almost any real build because of the standard library, so a raw list is all noise. Compute the set on the base commit, compute it on the branch, and report the difference: which non-standard packages are new to the build, and which of those new ones import `unsafe`, import `os/exec`, or have cgo files. A pull-request bot that comments only on that delta gives the reviewer three lines to think about instead of three hundred, and it makes the question concrete: *this* change adds *this* package, which shells out. ## The limits of a static inventory Be honest about what this proves. It is an import inventory, not behaviour. A package that imports `os/exec` may only use it on a code path you never take; a package with no risky imports can still exhaust memory, leak goroutines or send your data somewhere over `net/http`. The inventory tells you where to *read*, and reading the candidate's source is still the work. It also only covers the packages in the build configuration you ran it in: build constraints, `GOOS`/`GOARCH` and build tags change which files — and therefore which imports — are included, so a sweep run on your laptop may miss a file that only compiles for the target platform. ## Common mistakes - Confusing `go list -deps` (packages, compiled) with `go list -m all` (modules, build list). They answer different questions. - Treating any appearance of `unsafe` as a finding. Filter the standard library out and look at what changed. - Assuming one sweep covers all platforms. Re-run it with the `GOOS` and `GOARCH` you actually ship.