Building in the open
The release record
This is the core of SBOMFlow: one deterministic, portable record for every release — what was built, what the engine observed, and what a named person decided. A run reads the build you actually ship and builds that record through eight stages, from collecting the evidence to handing it over. Every other offering adds its evidence to this same record.
The engine behind this page is verified by 24,200+ deterministic offline tests — testing & trust. The current build is v0.5.0, available to approved private testers; what changed in it is in what’s new, and the capability matrix in the docs — its AI rows generated from the code — wins any disagreement with this page.
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. That question is not particular to devices, and it is not particular to any one regulation: it is asked by a customer's security review, a supplier questionnaire, an incident two years later, and an auditor — long before any regulator asks it.
The record at a glance
Everything a release ships — conventional and AI-enabled — lands in the same record, under the same review discipline, with its real status labelled throughout.
The lifecycle
Every stage adds to the same record. Nothing is copied between tools, nothing is re-keyed by hand, and nothing downstream can quietly upgrade what an earlier stage observed into a decision.
SBOMFlow reads the release as it shipped: firmware trees from Yocto, Buildroot and Zephyr, container images, lockfiles across the common and embedded ecosystems, and the SBOMs your suppliers send. Every file is hashed and every fact keeps its source. An input it recognises but does not read is named, never dropped.
Embedded & container builds Supplier evidence Supported inputs
What was collected becomes one composition, with stable identities, dependencies and licences, and from it validated, reproducible CycloneDX and SPDX. Supplier claims stay separate from what your build shows, and anything missing is shown as missing, never invented.
Components are checked against vulnerability advisories offline, with OSV and NVD only when you opt in. Every finding shows how confident the match is and where it came from. A match the engine cannot settle goes to a person, and a supplier’s “not affected” never closes your finding.
If you choose a requirement regime, the same evidence is mapped to it. Today that is the EU Cyber Resilience Act, with SBOM field checks against the NTIA 2021 minimum elements and BSI TR-03183-2. It is an engineering gap assessment, never a conformity conclusion — choose no regime and this step does not run.
Vulnerability review EU CRA readiness, one optional regime Observed vs reviewed
Every stage writes into one release record: an evidence pack, provenance for every fact, and an append-only audit trail designed to expose later changes. There is no hidden state, and the record reproduces byte for byte from the same inputs.
A local store keeps every release, so you can compare any two — new and resolved findings, component changes, support dates — and see your whole portfolio at once. That is what makes SBOMFlow a system of record rather than a scanner.
Evidence outputs Operating scenarios
Everything the engine observed waits for a person, marked observed and never accepted. Reviewers accept or reject evidence, set VEX status from their own decisions, and record waivers that surface before they expire.
Sign-off is multi-role, with separation of duties: nobody approves their own work, and every approval binds to the exact artifacts it covers. The release gate informs until you enforce a policy, then blocks and records exactly why.
A record is only worth handing over if the recipient can check it. Every output validates offline, audit trail included, and the evidence bundle carries the hash of everything in it, with an optional attestation and signature. A per-release assurance passport is available as an experimental preview.
The record leaves in the formats the people around you already use: CycloneDX and SPDX; OpenVEX, CycloneDX VEX and CSAF; SARIF and CSV; and annotations on pull and merge requests in GitHub Actions, GitLab and Jenkins. Findings sync to GitHub, Jira, ServiceNow and Dependency-Track — dry-run by default, applied only when you say so.
Beyond the eighth stage
Three offerings add evidence under different conditions — when the evidence is a captured file rather than something the engine can read, when a new advisory lands on a release you already shipped, and when the release carries models, services and agents as well as packages. Each has its own page and its real status.
Soak-test logs, rig traces, acceptance captures and core dumps kept beside the release by their exact bytes, with a named reviewer’s decision bound to them. The engine never interprets what the files contain, and they never move the release gate.
When a new advisory arrives after you ship, a case finds which shipped releases may be exposed — candidates, never automatic “affected” verdicts — and records every triage, fix, risk acceptance and communication with the name of the person behind it. SBOMFlow never files, publishes or sends anything.
Models, datasets, prompts, services and agents in the same record. An ordinary run already identifies shipped model files from their bytes — never executing them — and can compare what you declare about your AI with what it found. The stage stays in development as a whole; each link in the chain carries its own status on the AI Evidence page.
What you get
Plain files you own — no database, no dashboard, no black box. Each one is observed evidence pending human review, never proof of conformity.
With inputs and run context pinned, release artifacts are reproducible; timing measurements are excluded from determinism checks. Many outputs are optional, and any draft declaration is clearly marked unsigned and incomplete for a person to finish. Full inventory: evidence outputs · artifact schemas.
v0.5.0 is what you can run today. The next release is a focused, backward-compatible improvement: sharper provenance on every finding, wider format coverage, and records that stay provable for years. Nothing here has shipped, and an evidence pack written today will still read afterwards.
Engineering continues under that discipline. The way to influence what comes next is the design-partner programme.
A first audit runs offline on a laptop and writes the full artifact set from your real firmware or software build — a record of what was observed, not a claim that your evidence is sufficient. v0.5.0 is available to approved private testers.