Building in the open
Release evidence for connected-device manufacturers
SBOMFlow is the system of record for connected-device release evidence. It turns the build you actually ship into one portable, reviewable record — what shipped, what changed, which risks matter, what remains unverified, and who approved it.
$ sbomflow audit ./firmware-build ✓ scan components · dependencies · file hashes ✓ sbom cyclonedx · spdx (validated) ✓ vulns matched offline · context recorded, never a verdict ✓ 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
The problem
Build data lives in CI. SBOMs and supplier files live somewhere else. Vulnerabilities live in scanners and trackers. Models and AI services often aren't recorded at all. Approvals live in tickets and spreadsheets. Then a regulator, auditor, or customer asks — and the evidence is assembled by hand, under deadline pressure, with little of it tracing back to the exact build that shipped or the person who accepted it.
A scanner answers what is in a build. The question at release is what you knew, who decided, and whether you can produce the same answer in two years — SBOMFlow keeps that record, and a person makes every decision in it.
Why now
These are the dates the official sources currently state — not our reading of them. Reporting obligations arrive first, and they land on releases you have already shipped.
Verify against the primary sources: European Commission — Cyber Resilience Act ↗ European Commission — CRA reporting ↗ Regulation (EU) 2024/2847 (EUR-Lex) ↗
SBOMFlow prepares the engineering evidence and exposes the gaps. It never files a report and never decides whether you meet the regulation — what that means in practice.
Who it is for
Best fit today: small-to-mid-size embedded Linux and industrial IoT manufacturers with firmware CI and product-security ownership, preparing for CRA obligations.
Release-backed CRA evidence without a compliance scramble.
EngineeringGate releases in the CI you already run — explainably.
SecurityTriage with exploitation context; keep evidence alive after release.
ReviewStructured evidence and documentation workspaces — gaps stated, never papered over.
ReleaseRepeatable artifacts, explicit gates, defensible decisions.
AI/ML · in developmentShape how AI evidence joins the release record.
How it works
Everything a release ships — conventional and AI-enabled — lands in the same record, under the same review discipline, with its real status labelled throughout.
Run SBOMFlow against the actual product or firmware build you ship, plus any SBOMs and evidence you already have.
Components, dependencies, and file hashes become validated SBOMs; every piece of evidence traces to the exact bytes it came from.
Advisory correlation with exploitation context, model-file evidence, and CRA-oriented coverage — inputs for human judgment, never automatic rulings.
A review queue, multi-role approvals with separation of duties, and an explainable release gate you configure. Observed never becomes accepted on its own.
Release memory, drift between any two releases, shareable bundles a recipient can verify offline — and post-market continuity (experimental preview) when new advisories arrive.
Stage states are synthetic samples, drawn from the same pinned fixture as the walkthrough below.
See it
Real output from a pinned sample run, read the way a reviewer would — or open the full walkthrough.
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 gap
enforcement switched on, the same run blocks and records the
reason.
The interactive view needs JavaScript. Everything in it also exists as plain files: see evidence outputs and your first offline audit.
The release story
Scroll at your own pace, or jump between stages. Every stage visual is illustrative and synthetic.
Example GatewayRelease 2.4.1Synthetic demonstration
Acceptance, VEX status, and the release call belong to your reviewers. Nothing promotes itself — the open connection stays open until a person closes it.
Every release, remembered the same way.
The boundary
SBOMFlow keeps the record. The boundaries below don't depend on trust — they are built into the engine.
The engine runs to the edge of a decision and then stops. It has no way to go further on its own — not a policy choice, a boundary. Everything below the line waits for a person.
CVE-SAMPLE-OPENSSL-001 in openssl 3.0.11the engine stops here
No decision has been made, and none will be. A reviewer records one — with their name on it.
Illustrative · sample advisory labelled non-real
(CVE-SAMPLE-*) · the buttons stand in for a recorded
reviewer decision
The full picture — data flows, network opt-ins, secret handling, testing assurance, residual risks — lives in the trust centre.
Checkable facts — and what is not established
Drift guards fail the build when the figures on this page and the engine disagree. The 500+ documented warning codes are how the engine refuses to fail silently. The full verification pipeline is public: Testing & trust. What is not established: the recorded adversarial-laboratory run on the accuracy scorecard was produced by 0.4.0, and no run for 0.5.0 is published yet.
What one run reads
A connected product is not a web app with firmware attached. One run reads 15 build and package families across 22 manifest formats, including the embedded build systems general-purpose SBOM tooling tends to skip.
Yocto · Buildroot · Zephyr (west) · PlatformIO · Arduino · CMake · vcpkg
Python · npm · Cargo · Go · Maven · Gleam
Dockerfile · Compose · OCI image evidence (opt-in)
Product, firmware and host manifests as first-class inputs — an unrecognised file is warned about, never silently dropped
Every family above is a supported manifest in the engine’s own input catalogue, not a marketing list — the inputs reference names each one.
Before you ask
No, and no tool can. SBOMFlow prepares engineering evidence and shows you the gaps in it. Whether that satisfies the regulation is a judgement for your people, your assessor, and where required a notified body.
Not by default. The engine is offline unless you name an opt-in — every network-capable path is an explicit flag or config key, and there is no telemetry to switch off.
No. v0.5.0 is a certified private tester build with no known release-blocking defects, subject to documented restrictions — which is not the same as error-free. Status is stated per capability, never in general: available, experimental, in development, or planned.
The longer list — accuracy, IP exposure, what you need to run it, whether it replaces your review — is answered on the trust centre.
What is coming
v0.5.0 is what you can run today. The next release is a focused, backward-compatible improvement train, planned in the open. Nothing below has shipped, and none of it changes an existing artifact’s shape — that is what “backward-compatible” is holding us to.
Planned work, not shipped capability. The scope record and its kill criteria are public in the board that drives them — a card only becomes buildable when the ready queue says so, and only reaches this page when it runs.
Next step
v0.5.0 is a private tester build: certified with no known release-blocking defects, subject to documented restrictions — which is not the same as error-free. We're inviting a small number of design partners across three tracks: connected-device release evidence, post-market / PSIRT evidence continuity (experimental preview), and AI-enabled product evidence (in development). A first engagement starts from your real build and ends with a reviewer-ready evidence pack — and a straight answer on fit.
SBOMFlow is built by Amzat Karim, a London-based software engineer working on deterministic release evidence for connected products. A person reads hello@sbomflow.com and will answer yes, no, or not yet. Who is behind SBOMFlow
Release-evidence design partners · Post-market (PSIRT) design partners · AI evidence design partners · Advisors · No spam
Once you have the tester build
One command detects the project, scaffolds a config it refuses to overwrite, and runs a fully offline audit. It discloses the scan root, the detected inputs and its network posture before the first write — nothing happens to your tree that you have not been shown first.
$ sbomflow quickstart .