Know exactly what ships.

Build-accurate SBOMs for C/C++ — and the CRA paperwork to match. On-prem. Your code never leaves your machines.

CRA vulnerability-reporting obligations begin 11 September 2026
days
hours
minutes
bomwerk — build 4c1f
$ bomwerk observe -- make && bomwerk scan .
observing compiler + linker … 1,284 objects, 37 archives
✓ SBOM written — CycloneDX 1.6 — 214 components ✗ vendored zlib 1.2.11 — CVE-2022-37434 — statically linked into the release binary
The problem

Guessed SBOMs won't hold up.

C/C++ builds don't leave a lockfile behind. Most scanners read manifests and hope. Regulators won't accept hope.

no lockfile

C/C++ has nothing to read.

There's no package-lock for a Makefile. Manifest scanners guess — and miss vendored code, static libraries and forked SDKs that end up in the binary anyway.

24-hour clock

ENISA, within 24 hours.

From 11 Sep 2026 you must report to ENISA within 24 hours whether an actively exploited CVE affects your products — including products you've already shipped.

penalties

€15M or 2.5%.

Non-compliance under the CRA carries fines up to €15 million or 2.5% of worldwide annual turnover — whichever is higher.

How it works

Observe. Scan. Monitor.

Three commands. One SBOM per product, from what your build actually did — not what a manifest claims.

1

observe

Records what your compiler and linker actually did — every object, archive and static link that reaches the binary.

$ bomwerk observe -- make
2

scan

Merges package manifests, vendored-code detection and binary analysis into one CycloneDX/SPDX SBOM — all languages, one SBOM per product.

$ bomwerk scan . --format cyclonedx
3

monitor

Watches OSV, NVD and CISA KEV. When an exploited CVE hits a shipped component, it starts your 24-hour clock with a pre-filled report draft.

$ bomwerk monitor --notify enisa
SBOM Trim

See which declared components never made it into the binary. Dead dependencies inflate your attack surface on paper and waste triage time. Trim shows what's actually linked, so you report on what actually ships.

Honest comparison

bomwerk vs. generic free scanners.

Free scanners are useful. They also stop at what the manifest declares. Here's the difference on a real C/C++ repo.

Capability Generic free scanner bomwerk
Declared vs. build-observed componentsdeclared onlybuild-observed
Vendored / static-linked code detection
Unused-component (dead dependency) report
CRA report drafts, pre-filled
On-prem by defaultvaries✓ always
Free scan

Request a free scan of one repo.

Point us at one repository. We'll run bomwerk against it and walk you through what it found — no obligation.

Send us one repo link — or just a note about your build. We'll reply within one working day.

  Request free scan

Writes to info@bomwerk.com — or reach us at hello@bomwerk.com.

What you get back:

A build-observed SBOM (CycloneDX 1.6)
Vendored & static-linked findings
Any CVEs on components that actually ship
A short call to walk through the diff

The scan runs on hardware you control, or on a repo you share deliberately. Nothing is retained.

Open-source core

The scanner is Apache-2.0. Read it, fork it, run it in your pipeline.

Signed releases

Signed, reproducible builds. Verify the binary before you trust it.

No telemetry

No telemetry by default. It doesn't phone home; you turn on what you want.

Standards output

Conforms to CycloneDX 1.6 / SPDX 3.0, with BSI TR-03183 fields.

FAQ

Straight answers.

Does my code leave my machines?
No. bomwerk runs on-premises. The scanner analyzes your build on hardware you control, and source never leaves your environment. Monitoring pulls public CVE feeds in — it doesn't push your code out.
Which languages does it support?
Deep support for C/C++ via build observation and binary analysis. On top of that, all major lockfile ecosystems — npm, PyPI, Cargo, Go modules, Maven and more — merged into one SBOM per product.
Is it free?
The scanner is open source (Apache-2.0) and free to run. Continuous monitoring and pre-filled CRA report drafts are the paid part. You can generate SBOMs forever without paying us anything.
We already use Syft / Trivy. Why add this?
Keep them. Run both on one C/C++ repo and we'll show you the diff — the vendored zlib, the static-linked OpenSSL, the forked SDK that manifest scanners can't see. If there's no diff, you've lost nothing.
When do I actually need this?
Vulnerability-reporting duties start 11 September 2026. Full CRA obligations apply from December 2027. Building the SBOM pipeline before the reporting clock starts is the point.