bomwerk Is Open Source Now. Here's Exactly What That Means.

As of today, bomwerk's core is public. Source, not just a pitch: github.com/bomwerk/bomwerk, Apache-2.0, clean history, no marketing layer between you and the code that decides what's in your SBOM.

Here's exactly what that gets you, and what it doesn't, because the difference matters more than the announcement.

What's actually open

scan, observe, trim, binscan, the vulnerability matching against OSV, all of it. Clone the repo, build it yourself on Linux or macOS, and point it at your own codebase. There's no prebuilt binary yet, signed releases are still coming, so today this means building from source, not downloading an installer. If that's a dealbreaker for you right now, it's a fair thing to wait on, and I'd rather say that plainly than let you find out after cloning.

What you get for that effort is the whole evidence chain: a lockfile-and-manifest scan, a build-observed inventory that only counts what your compiler and linker actually touched, and outputs in CycloneDX 1.6 or SPDX 3.0.1 that are byte-identical across runs on the same input.

Getting from clone to a first SBOM looks like this:

$ git clone https://github.com/bomwerk/bomwerk.git
$ cd bomwerk && cmake -B build && cmake --build build
$ ./build/bomwerk scan --format cyclonedx-json ../your-project > sbom.json

No account, no API key, no network call beyond the OSV lookup for known vulnerabilities. The scan runs against your source tree, not a manifest file it hopes matches your source tree.

What's still commercial, and still in preview

Registering releases over time, nightly monitoring against CISA KEV, triaging findings as VEX (Vulnerability Exploitability eXchange), and drafting the ENISA report itself, that's the Pro extension, and it's not open source. It's also not generally available yet: it's tested and usable from source, with no tagged release. If you want early access, ask, we're not pretending it's finished software.

Keeping that boundary honest matters to me more than it probably should to most people building a company. The open core isn't a trial that expires or a crippled version designed to make you upgrade. It's the actual evidence-generation engine, unencumbered, because the thing worth trusting is the part that decides what's in your SBOM, not the part that emails you about it later.

Go try to break it

We didn't just publish the scanner. We published bomwerk/nightmare alongside it, a small C project built specifically to defeat manifest-only scanners: a vendored library with a known CVE, an uninitialized submodule, a forked dependency, prebuilt binaries with no manifest anywhere. It ships with a hand-written ground truth of what a correct scanner should find, and bomwerk is scored against that ground truth too, misses included.

We're not publishing the full head-to-head numbers in this post, that's a piece on its own, coming soon, and it deserves more than a paragraph here. What matters today is that the test exists, it's public, and you don't have to take our word for any of it. Run your current scanner against nightmare. Run bomwerk against it. The repository's ground truth file tells you exactly what the right answer looks like.

Why this, and why now

Every claim in the posts before this one, the deterministic output, the exit-code contract, the fuzzing, the signing, was true before today, but it was also unverifiable by anyone outside the company. That gap between "we say this is how it works" and "you can check how it works" is the whole reason open source exists as a trust mechanism, and it's a gap that's been open longer than it should have been.

It's closed now, for the part that actually matters most: the code that decides what your SBOM says you ship.

The source is public. The nightmare repo is public. Go read both, and if you want a second opinion on what your own repo looks like under this, that free scan is still on the table.