Point it at a release
Run it against the product or firmware build you ship, on a laptop or in your CI. By default, nothing leaves your network.
Release evidence for software and connected devices
SBOMFlow keeps one portable record for every release you ship: what was built, what the engine observed, and what a named person decided. It runs offline, on your own build, and it never makes the decision for you.
New in v0.5.5: runtime traces and crash dumps from every tool are part of the release record, and the release was checked against real, public traces, firmware and advisories before it shipped. See what changes
$ sbomflow audit ./release-build ✓ scan components · dependencies · file hashes ✓ sbom cyclonedx · spdx (validated) ✓ vulns matched offline · context recorded, never a verdict ✓ runtime traces · crash dumps · test logs · tied to the firmware ✓ review queue · named reviewer · recorded decision ✓ regime optional — cra, or none at all ✓ gate you decide what blocks a release ✓ bundle portable, hash-verified handoff › observed evidence — pending human review
What you get
The proof of a release usually lives everywhere except the release: in CI, in scanners, in tickets and in shared drives. SBOMFlow brings it into one record, so you can answer for a release long after it ships.
The components, dependencies and files in the release you actually ship, read from the build itself and written as standard CycloneDX and SPDX.
Vulnerabilities, evidence gaps and changes since the last release, each with its source. An observation, never a verdict.
Every acceptance, VEX status, waiver and approval carries a name and a time. Nothing the engine sees becomes a decision on its own.
What we offer
Each offering has its own page: what it does for you, what stays your decision, and its honest status today.
Review, approvals, release gates and release-to-release comparison, handed over as one bundle anyone can verify offline.
Available Build inputsYocto, Buildroot, Zephyr and other firmware builds, container images and language lockfiles, read from the build you ship.
Available SecurityOffline matching against sources you keep, with exploitation context, a named decision on every finding, and VEX you can hand to customers.
Available Supply chainEach supplier’s SBOMs and VEX statements, kept apart and attributed. A supplier’s word never replaces your own decision.
Available Test, trace & crashTraces and crash dumps from every tool, tied to the firmware image they ran on, decided by a named person and compared release to release.
Experimental After releaseWhen a new advisory lands, see which shipped releases may be exposed, and record what your team decided and did.
Experimental preview AI insideModels, datasets, agents and AI services in the same record, under the same review rules as everything else.
In development One optional regimeOne optional view of the same record: Cyber Resilience Act coverage and gaps. Choose no regime and nothing regulatory is added.
AvailableHow it works
Run it against the product or firmware build you ship, on a laptop or in your CI. By default, nothing leaves your network.
Findings, gaps and changes wait for a person. A named reviewer accepts, rejects or waives each one, and the release gate follows the policy you set.
Share one bundle with a customer, an auditor or your own team. They can check it offline, without installing anything, and the next release is compared against it.
Stage states are synthetic samples, drawn from the same labelled sample data as the sample run.
The boundary
It prepares engineering evidence and shows the gaps in it. Whether that meets a regulation is for your people and your assessor, and every regulatory output is an unsigned draft.
It runs offline by default, with no telemetry to switch off. It reaches the network only when you name an opt-in.
The engine records what it saw. Acceptance, VEX status and the release call belong to a named person.
Data flows, network opt-ins, how the engine is tested and what we have not yet established are all in the trust centre.
Checkable facts
A figure that drifts from the engine fails the build. The 600+ documented warning codes are how the engine refuses to fail silently. Every published number, how it was measured, and the numbers we have not measured yet are on the metrics page.
Next step
We are inviting a small number of design partners to shape the release-evidence system for connected products and the software they run. A first engagement starts from your real build and ends with a reviewer-ready record, and a straight answer on fit.
v0.5.5 is a private tester build: certified with no known release-blocking defects, subject to documented restrictions, which is not the same as error-free.
A person reads hello@sbomflow.com and will answer yes, no, or not yet.
Release evidence · Post-market (PSIRT) · AI evidence · Advisors · No spam