wolfSSL ships many products. They build with autotools, CMake, plain Make, IAR Embedded Workbench, Zephyr, and IDE projects. Each product needs an SBOM, but each product should not keep its own copy of the SBOM logic.
wolfssl-compliance-tooling is the shared toolkit. A product describes its own build. The toolkit turns that description into CycloneDX 1.6 and SPDX 2.3.
The toolkit is at https://github.com/wolfSSL/wolfssl-compliance-tooling.
Two inputs
Every build system answers two questions:
- Which configuration was compiled? That is the set of feature macros.
- What was produced? That is a library file, a source set, a declared dependency, or an artifact that must be hashed as shipped.
The generator sees only those answers. It does not know if they came from ./configure, an IAR .ewp, or compile_commands.json.
A front end collects the two inputs for one build system and gives them to sbom-driver, which calls gen-sbom. The toolkit has these front ends:
- sbom.am for autotools
- build/sbom.cmake for CMake
- build/sbom.mk for plain Make
- frontends/compdb_sbom.py for any compile_commands.json
- frontends/iar_sbom.py for an IAR .ewp
- frontends/zephyr_sbom.py for a Zephyr module
The driver expands macros with the host compiler, not the cross-compiler. It also removes absolute host paths, so a local SDK path does not enter the file.
A FIPS canister or a kernel module is hashed as shipped. A front end must not replace that binary with a source list.
What stays in the product
The product keeps the facts that only it knows: its name, its version, its source list, and any route that is special to its tree. The generator stays shared.
For Make, the product sets SBOM_NAME, SBOM_SRCS, SBOM_CFLAGS, and a version, then includes tools/sbom/build/sbom.mk. When the configuration is derived inside user_settings.h, the product also sets SBOM_SETTINGS_H. Without it, the SBOM misses every macro that the header computes.
Vendor a snapshot
Products copy a snapshot of the toolkit into tools/sbom/. They do not use a git submodule, because a submodule needs network access and breaks a source tarball. Generation works on an air-gapped machine.
tools/wolfssl-compliance-tooling-sync --dest /path/to/product
The product stores the toolkit version and commit that it copied. CI runs the sync tool with –check, which fails if the vendored files differ from that pin. A local edit of the generator cannot ship quietly.
Document identity
The CycloneDX serialNumber and the SPDX documentNamespace come from the name, the version, and a digest of the inputs. Two builds of one release with different features or sources get different identifiers. The same inputs give byte-identical output. SOURCE_DATE_EPOCH fixes the timestamp.
The package URL uses the canonical lower-case form and the release git tag:
pkg:github/wolfssl/wolfssl@v-stable
The CPE is cpe:2.3:a:wolfssl:wolfssl:
The other two pillars
The toolkit answers three questions:
- What is in this build? The SBOM engine. The product vendor provides this part.
- Does this CVE affect this product? The advisory tools are in central/. The wolfSSL security team runs them and publishes the results. Customers do not run them.
- Did this binary come from these sources? provenance/bomsh_verify.py checks an OmniBOR tree. More provenance tooling is planned.
The map of products, build systems, and methods is in docs/TIERS.md in the repository.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now