Go - Go Modules, Go Dep, Bazel

  • 17 January 2023
  • 2 replies

Debricked supports tracking Go dependencies via:

  • Go Modules, using go.mod files

  • Go Dep, using gopkg.lok files

  • Bazel, using WORKSPACE files


Go Modules

We support tracking Go dependencies using the Go Modules dependency management system and its associated file go.mod.

For the fastest and most accurate results, a file containing the resolved dependency tree, .gomod.debricked.lock, has to be created prior to scanning.

This can be done using the High Performance Scans technology in our Debricked CLI. By running the resolve command, the CLI automatically detects all manifest files without the recommended go lock files and generates the files as needed.


It is also possible to generate the recommended file(s) manually by running go mod graph followed by go list -m all and storing the outputs separated by two new lines between the sections in gomod.debricked.lock.


printf "$(go mod graph)\n\n$(go list -mod=readonly -e -m all)" > gomod.debricked.lock


Every gomod.debricked.lock must be put in the same directory as the corresponding go.mod. 

We also recommend running go mod tidy, which cleans up unused modules, before pushing the go.mod files, which makes the results of our service more accurate.



We support Go projects using Bazel, scanning the WORKSPACE file format in addition to any Go file formats being used. Even though Bazel does not have native support for Go, it is possible to add support using Gazelle.


Go Dep

Go Dep and its associated file Gopkg.lock is deprecated and will not get any improvements present in other formats, such as Go Modules.


Supported file formats and features:


Package Manager

Supported File Formats

Root dependencies 

Indirect dependencies

Dependency trees

Security Scanning

License Scanning

Root Fix





Go Modules


Go Dep






Have a look at the overview of all supported languages.

2 replies

Hello ,

We are using Debricked to generate sbom file for our go application. In the dependent components, it is including almost all dependencies used in the code. Some of them are not part of production binary, but used for testing.

For e.g: This is used for only unit testing


This is part of the main go.mod file as it is being used in unit tests.

How do I selectively exclude some modules (not files/folders) from the generated SBOM file?

Is there any way to do the same?





Hi @rkbk2000,

thank you for your question! We unfortunately do not have the possibility of breaking out certain dependencies from the SBOM, since the SBOM will contain everything we have found in a scan. Some time in the future, we plan to add support for finding dev-dependencies, enabling users to treat them separately, which I believe would solve your issue.

What you could do for now is to create a separate Go module for the test dependencies and make sure to exclude that file with the “-e” flag in the scan command. Alternatively, you could split up the application into two “repositories” in the tool, if you’d like to keep track of the test dependencies as well. Our head of Engineering, Emil, wrote a post on that earlier this year that can be found here: 

I hope this was helpful, let us know if you have any further questions.


Kind regards,

Carl, Debricked Product Manager