Get started

bomwerk is a command-line scanner. It runs on your machine, never uploads your source, and writes a CycloneDX or SPDX SBOM plus an optional offline HTML report. This page takes you from nothing to a first SBOM. Most of the time is the first compile.

Every flag's full reference is the command's own --help. A copy of each one is kept in the repository and checked against the binary on every change. This page does not repeat it.

Install

There are no prebuilt binaries yet, so build from source. You need Linux or macOS, a C++20 compiler (GCC 12+, Clang 15+ or AppleClang 14+), CMake 3.22+ and git.

git clone --recurse-submodules https://github.com/bomwerk/bomwerk.git
cd bomwerk
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel
./build/bomwerk --version

The first build compiles the pinned dependencies through vcpkg and takes a while. Later builds reuse the cache.

First scan

bomwerk scan .                                  # writes sbom.cdx.json (CycloneDX 1.6)
bomwerk scan . --format spdx -o sbom.spdx.json  # SPDX 3.0.1 instead
bomwerk scan . --html report.html               # also a self-contained HTML report

Every component carries a confidence level and the evidence it came from. The console ends with a coverage line: how many components have an identifier a vulnerability database can look up at all. It is there so that "no vulnerabilities found" is never mistaken for "everything was checked".

Vulnerability matching queries OSV by default and caches every answer. --offline uses the cache only. --no-vuln skips matching.

Record a release

For CRA evidence, name the product and version the SBOM describes:

bomwerk scan . --product acme-gateway --product-version 2.1.0 -o sbom.cdx.json

Run it in CI

The exit code is a stable contract: 0 clean, 1 completed with warnings (an SBOM was written), 2 incomplete. --fail-on picks which of them fail the job:

bomwerk scan . --fail-on incomplete -o sbom.cdx.json

Two runs over the same tree produce byte-identical files, and SOURCE_DATE_EPOCH is honoured. An SBOM can be diffed and signed like any other build output.

Check the SBOM against the build

Manifests say what a project declares. For C and C++ that is often incomplete or wrong. bomwerk can record a real build and compare. That takes separate commands, in this order. scan on its own does not run or observe a build.

bomwerk observe -- cmake -S . -B build   # configure under observe, so the build uses its compiler shims
bomwerk observe -- cmake --build build   # record what was compiled and linked
bomwerk scan . -o sbom.cdx.json          # picks up the trace and marks which components were built
bomwerk trim sbom.cdx.json               # which components the build used, and which it never touched
bomwerk binscan sbom.cdx.json            # dynamic deps, archive contents and symbols of the build output

The configure step matters. CMake records the compiler's absolute path when it configures, so a tree configured outside observe never reaches the shims and the trace comes back empty. Each observe run writes a fresh .bomwerk/trace.jsonl. scan applies it when it finds one in the scanned directory.

trim and binscan report to the console and change nothing by default. Add -o to write a new SBOM: trim drops the components the build provably never used, and binscan adds the binary evidence.

observe supports GCC and Clang toolchains on Linux and macOS.

What is available today

Shipped means it is in a tagged release. Nothing is yet: there is no tagged release. Preview means it is on the main branch, covered by tests and usable from source, but not yet in a tagged release, so the syntax may still change before 1.0. Planned means it is not built yet. The authoritative list, with the test behind each claim, is docs/capabilities.md.

Pro prepares report drafts. A person at the manufacturer reviews, completes and submits them through the ENISA Single Reporting Platform. bomwerk has no interface to ENISA and never submits anything on your behalf.

Network use and telemetry

The CLI has no telemetry. It sends nothing about you, your machine or your usage to bomwerk. Vulnerability matching queries OSV with package coordinates (a purl or commit id), never source code. bomwerk --endpoints prints every host the binary can reach, and --offline reaches none of them.

This website is separate from the product. It uses Plausible for aggregate, cookie-free analytics and Formspree for the enquiry form, as described in the privacy notice.

Limitations

• Conan and vcpkg have no OSV ecosystem. Their components are matched only with --cpe-fallback, at lower confidence, and labelled as such.
• Component-to-component dependency edges are not recorded yet. The SBOM carries the root relationship only.
• No prebuilt binaries yet. The first build takes a while.

The same list, kept current, is in the README.

Try to break it

bomwerk/nightmare is a small, deliberately hostile C project built to break manifest-only scanners: a vendored library with a known CVE, an uninitialized submodule, a forked dependency, prebuilt binaries with no manifest. Point bomwerk, or any other scanner, at it. Its documentation lists the answer a correct scanner should give, including the cases bomwerk still gets wrong.

Want us to look at your own repository? Request a free scan.