If the binary was built with Go, a tool can read the module list from its embedded build information. If it was built with cargo-auditable, the dependency list is stored in a dedicated section. Either way the result is a starting inventory you can turn into an SBOM, but it is only as trustworthy as the binary.
Go binaries
The cyclonedx-gomod tool has a bin mode that generates a rudimentary CycloneDX file from a compiled binary using the same information as the go version command with the module option. The binary must be executable, but the tool never runs it.
cyclonedx-gomod bin -json -output sbom.json -version 1.5.0 ./myapp
Set the version, because the binary does not always carry it for the main component. The tool warns that the embedded data should not be trusted unless the binary is known to be unmodified. If you turn on license detection in this mode, it downloads the modules, which needs the main module version.
Rust binaries
Rust programs built with cargo auditable embed a zlib compressed JSON dependency tree in a section named dep-v0. The data has no timestamps, so builds stay reproducible. Paths and URLs are redacted, while crate names and versions are stored as is.
Tools that read it, according to the project, include cargo-audit, Trivy, Grype, OSV-Scanner, Syft, and a converter named auditable2cdx that outputs CycloneDX. The project lists minimum versions for some of them, so check yours.
What you get and do not get
| Question | Go bin mode | Rust auditable data |
|---|---|---|
| Module or crate names and versions | Yes | Yes |
| Hashes | Not guaranteed | Not part of the format described |
| Licenses | Only with extra detection | Not included |
| Build time only dependencies | Not reliably | Recorded as the build saw them |
| Works with no source | Yes | Yes, if built with the tool |
A binary built without this support, in either language, gives far less. Then you are down to analyzing strings and file contents, with more guesses.
When to use this
- A supplier hands you a binary and no SBOM.
- You inherit an old release and lost the source tree.
- You want to check that a release matches its source based SBOM.
For the third, compare the two. A difference is worth an explanation.
Limits
An inventory is not a trust statement. The Rust project says plainly that neither it nor SBOMs protect against supply chain attacks. And an attacker who controls the binary can edit the embedded data.
Quick check
Do all Go binaries have module information?
Recent Go toolchains embed it by default, but a stripped or unusual build may not. Test with your own binary.
Can I trust the result for compliance?
Treat it as supporting evidence. Prefer an SBOM generated at build time from source.
Safeguard's SBOM and dependency scanning can ingest the files these tools produce, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
