# nancy: scanning Go dependencies against Sonatype Guide

> nancy is a Go command line tool that takes the output of go list, sends the dependency list to Sonatype Guide or Sonatype Lifecycle, and reports the vulnerabilities it finds. Version 2 rewrote the authentication around a Guide bearer token, and the 2.0.0 tag was retracted because the module path was wrong.

**sonatype-nexus-community/nancy** — A tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype Guide and Sonatype Lifecycle Index

- Repository: https://github.com/sonatype-nexus-community/nancy
- Stars: 614 · Forks: 76
- Language: Go
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/sonatype-nexus-community-nancy

## A scanner for the module graph, not for your code

The description says it plainly: nancy is a tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype Guide, and it also works with Sonatype Lifecycle, the product formerly known as Nexus IQ Server. Two things follow from that. The scope is dependencies, so the unit of analysis is the module graph rather than the code you wrote, and the findings are about the versions of third party modules you resolved. The second is that the intelligence is remote. nancy is not a vulnerability database and it is not a static analyser; it is a client for a service that holds the index, which is why authentication and a service account are the first section of the documentation and why the tool exists in two flavours. The usage section narrows the audience further, stating that nancy works for projects that use go mod for dependencies, which in practice means it reads the output of the go list command rather than parsing your go.mod file directly. For a Go team, the appeal is that the check is one pipeline stage long and produces a list of packages with known issues, at the level of a dependency list rather than a code review.

## Authentication: a Guide bearer token, and a deprecation clock

Version 2.0.0 supports two authentication modes for vulnerability scanning through Sonatype Guide, and the README is explicit about which one to use. The recommended path is a Sonatype Guide bearer token, obtained for free from the guide.sonatype.com site, and it can be passed as a flag or supplied as an environment variable.

```shell
go list -json -deps ./... | nancy sleuth --guide-token $GUIDE_TOKEN
```

```shell
export GUIDE_TOKEN=YOUR_TOKEN
go list -json -deps ./... | nancy sleuth
```

The second path is the old one. OSS Index credentials, given as a username and a token, continue to work through the Sonatype Guide compatibility API, but the README marks them deprecated, says they will be removed in the v3.x.y line, and notes that nancy will display a deprecation warning while they are in use.

The practical advice is to migrate now rather than when the v3 line arrives, because a CI job that reads credentials from the environment will break on that upgrade, and because the warning output in a pipeline is noise you have to filter. There is also a config subcommand, described in the help output as setting up credentials to use when connecting to services, which is the alternative to exporting variables on every run.

## Three ways to install, and what the release artefacts look like

The installation section offers the usual three choices. The first is to build from source, with the instructions given as a clone of the repository and a go build in the root of the project.

The second is to download a release binary from the GitHub releases page, and the README explains the naming convention, that each tag pushed to the repository creates a new release binary, with a curl example showing the file name pattern for a macOS amd64 build. Building from source is the same two steps the first option names, a clone of the repository and a go build in the root of the project.

```console
$ curl -o /path/where/you/want/nancy \
  https://github.com/sonatype-nexus-community/nancy/releases/download/v0.0.44/nancy-darwin.amd64-v0.0.44
```

The third is Homebrew on macOS, through a tap that the project maintains, and the README notes that the formulae are created and published to that tap with each new release, so brew can also upgrade the tool.

```shell
brew tap sonatype-nexus-community/tap
brew install sonatype-nexus-community/tap/nancy
```

The repository layout backs up the release process, with a .goreleaser.yml file and two Dockerfiles, one for Alpine and one for goreleaser, so the same tags that produce the binaries also produce container images.

## sleuth and lifecycle are two backends for the same job

The help output in the README shows the command structure, and there are two scanning commands plus two utility ones. The sleuth command checks for vulnerabilities using Sonatype Guide, and the lifecycle command does the same using Sonatype Lifecycle. The config command sets up credentials for connecting to services, and the update command checks whether updates are available. The reason there are two scanning commands is that they talk to different services with different data and different licensing, and the README describes the Sonatype Lifecycle options as including a persistent Lifecycle configuration, so a team that has a Lifecycle server can point the tool at it and keep that configuration on disk rather than passing settings on every invocation. The Sonatype Guide options are a different set, covering a custom server URL, loud mode, a maximum input size, excluding vulnerabilities, and output control. The custom server URL matters for anyone who has to route the traffic through a proxy or a regional endpoint, and the exclude option is what you want when a finding has been triaged and accepted. For a team deciding between them, the question is which service you already pay for, not which command is better.

## The go list pipeline, and the 100 megabyte input limit

The data flow is short and worth understanding because it determines what nancy can see. The tool reads the JSON output of go list with the deps flag, which is the resolved dependency list of the module, and sends that to the service. The pipe form is the classic one, and the README gives both variants in the examples.

```
  Or explicitly piping go list output:
  go list -json -deps ./... | nancy sleuth [flags]
  go list -json -deps ./... | nancy lifecycle [flags]
```

There is a new behaviour in version 2.0.0, because running nancy sleuth with no piped input will automatically invoke go list -json -deps ./... for you. The README notes that the pipe form still works and may be preferred in CI for explicitness, which is a sensible position, since a pipeline stage that quietly runs the resolver for you behaves differently in a clean container where the module cache is empty. The flags list includes a maximum input size for the go list output, given in megabytes with a default of 100, and that is the constraint to watch. A large dependency tree with many modules can produce a go list output that is big enough to matter, and the tool will refuse to read beyond the limit rather than exhaust memory. There is also a cache, with a flag to delete the local cache directory and another to give an alternate path for it, which matters in CI where the cache location and its lifetime are decisions you have to make deliberately.

## CI usage, loud mode and the fine print

The README has a section on usage in CI, and the flags give the practical details. The loud flag indicates that output should include non-vulnerable packages, which is the switch you flip when a pipeline is being set up and somebody needs to see the full list, and the quiet flag does the opposite. The verbosity flag takes repeated v characters for more verbose output, and the log level is separate from the result output. The reason this is worth reading carefully is that a scanner whose default output lists only problems will fail a pipeline differently from one that lists everything, and a team that switches the loud flag on to debug a finding and forgets to switch it back will end up with a very different log volume in production.

The documentation also has a section titled Why Nancy, and within it a subsection on the relationship to govulncheck, which is the comparison a Go team should actually make before adding another tool to the pipeline. The scope difference is visible from the usage itself, since nancy checks the dependency list against a Sonatype service, and the project's own guidance is where the detail lives. There are also sections on how to fix vulnerabilities, a disclaimer, a section on the fine print, and an acknowledgements section, and the disclaimer is worth reading for any tool that queries a service and reports on your dependencies. On releases, the documentation covers both the release process and a pre-release process, and the repository carries a contributors file, a contributing guide and a licence file under Apache-2.0, with a copyright header for Sonatype from 2018 onwards.

## Conclusion

Adopt nancy if your organisation already runs Sonatype Guide or Lifecycle and you want a single command in CI that reports known vulnerabilities in your module graph. It does not fit a team that has no Sonatype service and no appetite for one, because the scanning is performed by that service rather than locally, and it does not fit a Go project that wants the analysis of its own build rather than of its dependency list. Before you wire it into a pipeline, read the section on the relationship to govulncheck in the project documentation, because the two tools answer different questions, and note that the 2.0.0 tag was retracted, so pin to 2.1.0 or later rather than to the version number you might expect from the release history.

## FAQ

### What does nancy check?

It checks your Golang dependencies for known vulnerabilities, reading the resolved dependency list reported by go list and querying Sonatype Guide, or Sonatype Lifecycle formerly Nexus IQ Server, for the findings. It works for projects that use go mod for dependencies.

### How do I authenticate nancy?

The recommended method from v2.0.0 is a Sonatype Guide bearer token, obtained for free from guide.sonatype.com and passed with the guide-token flag or the GUIDE_TOKEN environment variable. The older OSS Index username and token still work through the compatibility API but are deprecated and will be removed in v3.x.y.

### How do I install nancy?

You can build it from source with go build -o nancy . in the repository root, download a release binary from the GitHub releases page, or install it on macOS with Homebrew after running brew tap sonatype-nexus-community/tap and brew install sonatype-nexus-community/tap/nancy.

### What is the difference between nancy sleuth and nancy lifecycle?

They are the same check against two different Sonatype services. The sleuth command scans using Sonatype Guide, and the lifecycle command scans using Sonatype Lifecycle, which has its own options including a persistent Lifecycle configuration for connecting to the service.

### Why was the nancy v2.0.0 release retracted?

The go.mod file in the repository retracts v2.0.0 because the module path was missing the /v2 suffix, which made that version uninstallable. The module path is now github.com/sonatype-nexus-community/nancy/v2.

## Sources

- [Issues](https://github.com/sonatype-nexus-community/nancy/issues)
- [License: Apache-2.0](https://github.com/sonatype-nexus-community/nancy/blob/main/LICENSE)
- [README](https://github.com/sonatype-nexus-community/nancy/blob/main/README.md)
- [Releases](https://github.com/sonatype-nexus-community/nancy/releases)
- [sonatype-nexus-community/nancy on GitHub](https://github.com/sonatype-nexus-community/nancy)

---

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