SBOMFlow documentation

SBOMFlow is a deterministic, offline-by-default system of record for connected-device cybersecurity release evidence. For each firmware or software release it collects composition (SBOM), vulnerability context, reviewer decisions, and an audit trail into reviewer-ready, portable evidence you own as plain files.

Pick your journey#

Start from the job you came for. Goals lists every one — an SBOM, vulnerability triage, a CI gate, a sign-off, release history, a handoff, runtime-evidence custody, firmware evidence, a post-market case, AI evidence, and the optional CRA regime — with its exact offline steps, and sbomflow help goals prints the same list. None of them but the CRA goal needs a requirement regime; see Use SBOMFlow without CRA assessment.

Six common journeys through these pages, each starting from a real build and ending in evidence a human can review, reproduce, and hand off.

1. Run your first audit — install the CLI and produce a complete offline evidence pack from a real build. "Complete" here means the full artifact set for that run; it is never a claim that the observation itself is complete. Installation -> Your first offline audit -> Read an evidence bundle.
2. Review a release — understand what the engine observed, what needs a person, and how decisions are recorded. Observed vs reviewed -> Evidence outputs -> CLI workflow.
3. Gate a release in CI — run on every release candidate. The gate is informational until you choose a policy to enforce; then it blocks on your conditions with the exact reason and exit code recorded. CLI workflow -> Exit codes -> Evidence outputs.
4. Compare releases — see what changed between two releases: new and resolved findings, component and coverage drift, and support-period changes. Evidence outputs -> CLI workflow.
5. Share with an auditor — hand off a portable, hash-verified bundle a reviewer can open in a browser without installing anything. Read an evidence bundle -> Evidence outputs.
6. Keep trace and crash evidence with a release — record the traces and dumps a release was judged on against its firmware image, record a named decision about each, and see what changed at the next release. Trace and crash evidence -> Runtime evidence custody.

Evaluating the tool itself? Read the trust posture a security buyer should see before adopting anything that touches their build: Security & privacy -> Testing & trust -> Capabilities.

What SBOMFlow does#

• Ingests your build (lockfiles, manifests, SBOMs, container/firmware inputs) and produces a deterministic composition with SHA-256 provenance.
• Adds vulnerability context, offline by default; real advisory sources are explicit, named, opt-in lookups.
• Optionally maps evidence to a requirement regime — the EU CRA is the one offered today — and reports gaps; it never decides a requirement is met. With no regime chosen, nothing is assessed and every run says so.
• Keeps runtime and test evidence it cannot read — traces, crash dumps, captures — in custody by digest, with named human decisions: see Keeping runtime evidence in custody.
• Records human review decisions and approvals separately from machine observation, with an append-only, hash-chained, tamper-evident audit trail.
• Exports a portable evidence bundle (JSON, HTML, and more) you can read, diff, and hand to an auditor.

What SBOMFlow does NOT do#

• It does not claim your product is "compliant", "certified", or "conformant".
• It is not limited to SBOM generation — it can build SBOMs from supported local inputs and consume supplier SBOMs as observed context.
• It is not a vulnerability scanner that decides what ships.
• It does not file, transmit, sign, or submit any regulatory report.
• It does not send your source, firmware, paths, or findings anywhere by default.

Start here#

1. Installation
2. Your first offline audit
3. Read an evidence bundle
4. Core concepts