Building in the open
System of record · cybersecurity release evidence
SBOMFlow turns every firmware and software release into traceable, reviewer-ready evidence — what shipped, which vulnerabilities matter, how it maps to the EU Cyber Resilience Act, and who signed it off. Deterministic, offline by default, and built so your people still make the calls.
$ sbomflow audit ./firmware-build ✓ scan components · dependencies · file hashes ✓ sbom cyclonedx · spdx (validated) ✓ vulns offline by default · KEV · EPSS · reachability ✓ cra Annex I · VII · Art. 14 (2024/2847) ✓ review queue · sign-off · approvals ✓ gate you decide what blocks a release ✓ bundle portable, hash-verified handoff › observed evidence — pending human review
Why now
The EU Cyber Resilience Act makes cybersecurity evidence a condition of market access for products with digital elements. These are the dates the official sources currently state.
Today the proof of a release's security is scattered across build outputs, SBOM tools, trackers, spreadsheets, PDFs, and manual reviews — assembled by hand, under deadline pressure, with little of it tracing back to the exact build that shipped or the person who accepted it. It should be a system, not a scramble — one that can reproduce the decision two years later, when an auditor or customer asks. Source: European Commission ↗ Reporting details ↗
What SBOMFlow is
SBOMFlow reads a real build and the files around it, gathers the security facts about what's actually inside a release, organises them into evidence you can trace and hand to a reviewer, and leaves the judgment calls to your team. Pin the inputs and run context, and the evidence is reproducible.
Pinned inputs and run context produce stable identifiers, hashes, and byte-reproducible release artifacts, so a result can be re-checked long after the release. Operational timing data is kept separate.
Runs in locked-down CI and customer environments with zero required dependencies. Your code stays put; it reaches the network only when you explicitly ask it to.
What the engine observes is kept separate from what a person has reviewed and accepted. Evidence is never quietly turned into a compliance conclusion.
Firmware build systems, embedded package managers, and container images are first-class — not an afterthought bolted onto a web-app scanner.
The depth behind it
Every output is a portable file you own and can diff — not rows in a black box. Every change is held to a strict engineering bar: tests, provenance, and a human-review boundary. The full pipeline — parser, malformed-input, determinism, integrity, and boundary testing, plus a ten-archetype synthetic manufacturer stress corpus — is documented openly in Testing & trust.
Use cases
Concrete jobs SBOMFlow does today — each one starts from a real build and ends with evidence a human can review, hand off, and reproduce.
Assemble traceable, build-backed evidence for one product release and see exactly where it maps to the regulation — and where the gaps are — without claiming conformity.
Outcome a reviewer-ready evidence pack & coverage map
Run on every release candidate. The gate is informational until you choose a policy to enforce — then it blocks on the conditions you set, with the exact reason recorded.
Outcome a deterministic, explainable release decision
Produce validated CycloneDX and SPDX SBOMs, VEX statements, and a coverage summary on demand — so a customer or downstream operator request takes minutes, not a sprint.
Outcome standards-based artifacts you can send today
Correlate components against public advisories and layer in exploitation signals — known-exploited status, exploit probability, and conservative reachability — as inputs for human triage, never automatic verdicts.
Outcome less false-positive noise, clearer priorities
Route findings and evidence through a review queue, require multi-role approval with separation of duties, and record time-boxed exceptions in an append-only, hash-chained trail designed to expose later modification.
Outcome a defensible record of who decided what, and why
Compare any two releases — new and resolved findings, component and coverage drift, support-period changes — and share a redacted evidence pack downstream to importers and distributors.
Outcome release-to-release continuity you can prove
How it works
Run SBOMFlow against an actual product or firmware build — the same one you ship — plus any SBOMs, test results, and evidence you already have.
It identifies components and dependencies, produces standards-based SBOMs, and hashes every scanned file — so each piece of evidence traces to the exact bytes it came from.
It correlates known issues, layers in exploitation context only when you ask, and maps what it observed to a versioned model of the regulation — keeping judgment areas clearly separate.
Findings and evidence flow through a review queue, multi-role approvals, and a release gate you configure. What the engine observes never becomes acceptance on its own.
It produces a consistent set of outputs — an evidence pack, a release-gate decision, a portable reviewer bundle, and an audit trail — for a release call a human still owns.
Shipping today as an experimental preview. When a new advisory arrives, the post-market case workflow shows which shipped releases are exposure candidates and carries your assessments, decisions, and human-reviewed unsigned reporting drafts — so post-market work builds on the release evidence instead of restarting it. Design partners are shaping it toward production. Consequential calls stay human decisions, and SBOMFlow never files a report.
Product walkthrough
This is real SBOMFlow output — a pinned, offline sample run of the bundled example gateway, projected straight from the generated artifacts. Step through the release evidence the way a reviewer would.
One offline sbomflow audit of the sample gateway release
(Example Embedded Linux Gateway 2.4.1) observes
22 components, matches 2 sample advisory
findings (CVE-SAMPLE-OPENSSL-001,
CVE-SAMPLE-BUSYBOX-001), maps evidence to the CRA Annex I
model, records 7 evidence gaps, and leaves
6 observed items awaiting human review. The release
gate stays informational until you enforce a policy — with
--fail-on-gaps the same run blocks with the exact reason
and exit code 1.
The interactive view needs JavaScript. Everything in it also exists as plain files: see evidence outputs and your first offline audit.
Who it's for
Embedded Linux, industrial IoT, robotics, and firmware-driven products heading into the EU market.
Connect build outputs, firmware manifests, and security tests to release evidence — in the pipeline you already run.
Triage vulnerabilities, reachability, and evidence gaps from real artifacts — not guesswork.
Prepare structured evidence and documentation workspaces without overclaiming.
Use consistent artifacts and explicit gates to support repeatable, defensible release decisions.
Assemble traceable, build-backed evidence for EU Cyber Resilience Act work.
Best fit today: small-to-mid-size embedded Linux and industrial IoT manufacturers with firmware CI and product-security ownership, preparing for CRA obligations. SBOMFlow is built for connected and embedded products — not only web apps.
Where it stands, and where it's going
One evidence record, across the life of a connected product — develop, release, operate, prove. The release-evidence core is real and runs offline today, with a strict no-overclaim discipline; it's where design partners start. The operate phase — keeping that record useful after a product ships, when new vulnerabilities and incidents arrive — ships today as an experimental limited preview, and design partners are shaping it toward production. You run the core today as a CLI & CI engine; the surfaces and deeper post-market workflows around it follow as demand pulls them.
A deterministic, offline engine that turns a real build into traceable evidence, with review, approvals, and gates — proven on real product builds.
Hardening the engine on real partner artifacts and running the full evidence-and-sign-off workflow end to end with a handful of early teams.
An early, narrow launch around the CRA reporting go-live — followed by shared review surfaces, team workspaces, and deeper integrations as demand pulls them.
This is our direction, not a commitment. Roadmap items are not yet available, may change, and imply no delivery date or compliance guarantee.
Trust & security
SBOMFlow runs over your source, firmware, and reviewer notes — so its own security posture is documented, not assumed. A CISO can read the full threat model and a control-by-control security-review self-assessment — each control mapped to where it is enforced, stated plainly as a self-assessment and not an external audit — before adopting it.
Your code, SBOMs, and notes are read locally and written only to your output directory. Network egress happens only on explicit, named opt-in paths.
Integration tokens are read only from environment variables, never from config or flags, and never written into any artifact.
The opt-in HTTP client enforces a scheme allowlist, an SSRF address guard (loopback / cloud-metadata / private ranges refused), redirect re-validation, and a response-size cap.
Zero required runtime dependencies, and SBOMFlow runs on itself — its own source tree goes through the same engine to produce its own SBOM. The prepared release workflow builds that SBOM + checksums and uses PyPI Trusted Publishing with attestations when the first tagged public release is approved.
Boundaries that don't move — enforced in the engine, not just on this page:
SBOMFlow runs over your source, firmware, and reviewer notes, so we prove its accuracy the way a real, messy manufacturer estate will: an in-house deterministic laboratory of ten synthetic connected-device businesses — full customer-shaped estates built to test both accuracy and robustness — driven through the production CLI with their answer keys held out of reach.
Full repositories across Yocto, Zephyr, Buildroot, ESP-IDF, OpenWrt, ThreadX, and RPM — with supplier SBOMs, release rooms, linked historical releases, and dependency-scale workspaces. Real-world messy, not tidy scanner fixtures.
Each estate hides deliberately planted inconsistencies, and every answer key lives outside the scan root — so no evaluation can ingest, hash, or be biased by its own ground truth. The tool has to earn the result.
Known-affected cases must be caught — a false-negative guard — and known-clean cases must stay clean. Accuracy is measured against transcribed real advisory ranges, not assumed.
An executable evaluation fails on any silent omission, false merge, false positive, missing provenance, or overclaim — the exact failure modes a customer would catch first.
Malformed lockfiles, nested archives, and encoding edge cases (UTF-16, BOM, CRLF) go through the shipped command; a tripwire fails the run if any path reaches for the network when it shouldn’t.
A poisoned environment proves no secret escapes into any artifact, log, or subprocess, and mutation self-checks confirm the tests actually fail when the engine misbehaves — so a green run means something.
A strong engineering gate — not a security certification or a proof of CRA conformity. It measures how accurately and safely the tool behaves under customer-shaped pressure. It makes no claim about your product.
Read the public security and privacy documentation for data flows, network boundaries, secret handling, and residual risks — and Testing & trust for the verification pipeline behind every release. Stated honestly, with no compliance or conformity claims.
What you get
A consistent set of evidence you actually own — portable files, not a black box. Each one is observed evidence pending human review, not proof of compliance.
With inputs and run context pinned, release artifacts are reproducible; opt-in phase durations are explicitly excluded from determinism checks. Many outputs are optional, and any draft declaration is clearly marked unsigned and incomplete for a person to finish.
FAQ
No. SBOMFlow helps you collect, connect, and review cybersecurity evidence; it is not a certification and grants no regulatory approval. It produces engineering evidence and gap assessments to support CRA-oriented work, and qualified human review is always required.
No. It runs offline by default with no paid APIs, and your code is never sent to third-party services by default. It only reaches the network for specific public vulnerability sources, and only when you explicitly enable them. Outputs carry identifiers, counts, and hashes — never your secrets or source.
We measure it, adversarially. The engine is driven through an in-house laboratory of ten synthetic manufacturer estates whose answer keys are held outside the scan root, with positive and negative controls — known-affected findings must be caught, known-clean components must stay clean — and per-fact scoring that fails on any silent omission, false merge, or overclaim. When something can’t be determined, it’s surfaced for human verification, never quietly dropped. The full verification pipeline is documented in Testing & trust — and it’s an engineering gate, not a claim of perfection.
A generator answers “what’s in this build?” — SBOMFlow answers what happens next. It builds validated SBOMs from what it observes and also ingests the output of tools you already run (Syft, Trivy, Grype, supplier SBOMs), then adds the layer those tools stop at: human review with recorded decisions, multi-role approvals, an explainable release gate, release-to-release drift, and a tamper-evident audit trail — the record of who decided what, and why, that you keep across every release.
Python 3.11+ and a real build tree — that’s it. Zero required runtime dependencies, no accounts, no server, nothing to send anywhere. It runs fully offline on a laptop or in locked-down CI (GitHub Actions, GitLab, Jenkins), and a first audit produces a complete evidence pack from your build in minutes. Start with your first offline audit.
Yes. Every output is a portable file: a static reviewer console and evidence bundle open in any browser with nothing installed, a no-install auditor package is built for exactly that handoff, and a redactable sharing pack covers importers and distributors. Hashes travel with the evidence, so a recipient can verify nothing was altered. See read an evidence bundle.
Pricing is under validation and arranged directly while we work with a small number of design partners — it’s scoped to your product class, repositories, firmware variants, and release cadence rather than per-seat tooling. The offline CLI is free to trial. Tell us about your product and we’ll give you a straight answer.
No. The engine observes; your people review and decide. It is designed to make expert review faster and better-evidenced — not to replace lawyers, consultants, auditors, or your own sign-off.
Not in the way you might expect. SBOMFlow is deterministic: its evidence comes from real builds, files, and human decisions. AI may help draft or explain at the edges, but it is never the source of truth, and the core makes no required AI calls.
No. SBOMFlow never files, transmits, submits, or signs anything, and never contacts a regulator or reporting platform. Any incident or declaration output is a clearly-marked draft for a person to complete and submit.
No. It is built for connected and embedded products — embedded Linux, industrial IoT, robotics, and firmware-driven hardware, including container images — alongside common software ecosystems.
The engine is deep and tested; the product experience is still being built. SBOMFlow runs offline today with a broad capability set and 9,600+ deterministic tests. Shared review surfaces and a hosted experience are roadmap. We're proving the core on real builds before adding gloss.
SBOMFlow is in active development and looking for design partners. If you build connected products, advise on CRA, or invest in the space, the fastest way to reach us is to book a 20-minute CRA evidence review.
You can also follow @SBOMFlow on X or @SBOMFlow on Instagram for progress.
Something we haven’t answered? Ask us directly at hello@sbomflow.com — straight answers only.
Pricing
One thing done well: a traceable CRA/SBOM/vulnerability evidence pack from your real build, with a human-review boundary. Release-readiness support — never a compliance guarantee.
We're taking a small number of design partners for validation work arranged directly. Read the documentation to understand the workflow and evidence outputs. We provide release-readiness support — not legal advice, and not a statement that a product is conformant.
Get in touch
We're looking for a small number of design partners — connected-device manufacturers preparing for the CRA — and, separately, for product-security and PSIRT leads to shape the experimental post-market preview with us. We're also happy to talk with advisors and investors who see the same wave coming. Tell us what your release and post-market process actually looks like; we'll show you where SBOMFlow fits.
Release-evidence design partners · Post-market (PSIRT) design partners · Advisors · Investors · No spam
