For a Rust project, install cargo-cyclonedx and run it from the directory holding Cargo.toml to produce a CycloneDX file of all project dependencies. If you also want the dependency data to travel inside the compiled program, build with cargo-auditable, which embeds a compressed dependency list in the binary.
Two approaches, two jobs
| Approach | When it runs | Where the data lives | Suited to |
|---|---|---|---|
| cargo-cyclonedx | On the source tree | A separate CycloneDX file | Release artifacts, customer requests, CI storage |
| cargo-auditable | During the build | Inside the executable | Auditing a deployed binary later, even without the source |
They are not rivals. The first gives you a document to hand over. The second means the binary can always answer the question "which crate versions went into me?"
Steps for a separate SBOM file
- Install with cargo install cargo-cyclonedx.
- From the project root, run cargo cyclonedx.
- Store the output next to the release artifact.
The tool calls into Cargo itself to read project information. Its maintainers warn that Cargo may run arbitrary code, so do not run it on an untrusted project. They add that tools which only parse Cargo.lock still depend on Cargo to produce that file, so the caution applies broadly.
Steps for data inside the binary
- Install cargo-auditable and cargo-audit.
- Build with cargo auditable build and the release option instead of plain cargo build.
- Scan the result with cargo audit bin pointed at the executable.
The project describes the embedded data as zlib compressed JSON in a section named dep-v0. It states the list is under 4 kB even with more than 400 dependencies. File paths and URLs are redacted, while crate names and versions are stored as they are, so remember that anyone holding the binary can read them.
Several scanners and SBOM generators can read this data back, including cargo-audit, Trivy, Grype, OSV-Scanner and Syft, from the versions the project lists. Check your tool's version before relying on it.
What neither approach does
The cargo-auditable project says plainly that it does not protect against supply chain attacks, and that SBOMs do not either. An inventory tells you what you used. It does not tell you whether a crate is trustworthy.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how many components sit two or three levels below the ones you declared. Rust projects often look the same.
Quick check
Do I need cargo-auditable if I already produce a CycloneDX file?
Not strictly. It helps when binaries get separated from their SBOM files, because the data stays with the executable.
Is it safe to run cargo-cyclonedx in CI on pull requests from forks?
Treat it like any build step. Cargo can run code from the project, so use an isolated runner for untrusted contributions.
Safeguard's SBOM and dependency scanning accepts CycloneDX documents, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
