Release evidence for software and connected devices

Every release. One defensible record.

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.

v0.5.5 · private tester build Deterministic Offline by default Human-reviewed Open formats

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

release-evidence/ offline
$ 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
Illustrative run · sample data labelled non-real human review required
Built on open standards and published sources CycloneDX SPDX OSV NVD CISA KEV FIRST EPSS Debian tracker Alpine secdb OpenVEX CSAF SARIF CRA 2024/2847

What you get

One record per release. Three questions, kept apart.

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.

What was built

The components, dependencies and files in the release you actually ship, read from the build itself and written as standard CycloneDX and SPDX.

What the engine observed

Vulnerabilities, evidence gaps and changes since the last release, each with its source. An observation, never a verdict.

What a named person decided

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

Start with the record. Add what your product needs.

Each offering has its own page: what it does for you, what stays your decision, and its honest status today.

How it works

Three steps, on the build you already have.

01

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.

your first offline audit

productexample gateway (sample)
release2.4.1
networknone used ✓
offline by default
02

Review what it found, and decide

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.

review & gates

queueobserved items awaiting review
decidea named reviewer records it
gateinformational until you enforce a policy
observed ≠ accepted
03

Hand over one record

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.

read an evidence bundle

bundleSBOMs · findings · decisions · gate
verifyhashes travel with it ✓
nextdrift shows what changed
portable · verifiable

Stage states are synthetic samples, drawn from the same labelled sample data as the sample run.

The boundary

Three things SBOMFlow never does.

Claim conformity, or file a report

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.

Phone home

It runs offline by default, with no telemetry to switch off. It reaches the network only when you name an opt-in.

Decide for you

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

Every figure here traces to running code.

28,600+
Deterministic offline tests
→ re-run them yourself; a skipped test is never counted as a pass
14
Mandatory evidence artifacts
→ written by every successful analysis run, so nothing is assembled by hand; more when the inputs call for them
600+
Stable, documented warning codes
→ nothing fails silently; uncertainty is stated, never swallowed

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

Bring one real release. See its record.

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.

Who is behind SBOMFlow

Release evidence · Post-market (PSIRT) · AI evidence · Advisors · No spam