Conan 2 can generate CycloneDX SBOMs natively from the resolved dependency graph. You write a small client hook that calls the cyclonedx_1_4 or cyclonedx_1_6 function from conan.tools.sbom and saves the output. The feature is marked experimental in the documentation, so pin your Conan version and test the output.
What Conan provides
The documentation describes SBOM generation as native, built from a resolved dependency graph. The functions live in the conan.tools.sbom.cyclonedx module. Each takes a conanfile and returns a dictionary in CycloneDX JSON form. Only CycloneDX versions 1.4 and 1.6 are supported. A separate option serialises the subgraph, which the documentation says is not a standard SBOM format, so do not hand that one to a customer expecting CycloneDX.
Conan does not choose where the file goes. The hook writes it. The documentation's examples use the package metadata folder, with a file called sbom.cdx.json, or an sbom subfolder under the generators folder.
Steps
- Pick your Conan 2 version and read its SBOM page, since the documentation for different releases describes different supported CycloneDX versions.
- Write a hook, for example one that runs after the package step or after generation, that calls the function for the version you want.
- Write the result to a stable path, and publish it as a build artifact next to the binary.
- Decide whether build and test requirements belong. The 1.4 function takes arguments for adding build requirements and test requirements, both off by default.
- Validate the output with a CycloneDX validator before you ship it to anyone.
What to check in the result
| Check | Why |
|---|---|
| Every dependency has a name and version | Matching advisories needs both |
| The top-level application component exists | Without it the document has no root |
| Licences are present where known | Customers often ask |
| Identifiers use a type that fits | See which package URL type to use for C and C++ |
| Build tools are included or excluded on purpose | Tools are part of the supply chain |
What it does not cover
The SBOM reflects the Conan graph. Libraries pulled in by CMake, copied into the tree, or linked from the operating system do not appear unless you add them. The result is an accurate description of your Conan dependencies and a partial description of your product.
See how to find vulnerabilities in vendored or copied code for the gaps and how to close them.
Try it yourself
Open the demo and look at what a dependency inventory contains and how versions are listed. Use it as a checklist for your own SBOM output.
Click through it at your own pace, or open it full screen.
Quick check
Is Conan SBOM generation stable?
The documentation marks it experimental and subject to breaking changes. Pin your version and re-test on upgrades.
Which CycloneDX versions does it write?
Versions 1.4 and 1.6 are supported. Check the page for your Conan release.
Safeguard's SBOM and dependency scanning can build an inventory of the components in a repository, and the free scan at gold.safeguard.sh/scan is a quick way to see what turns up.
Sources
Last reviewed: 19 October 2026.
