Building in the open
Product walkthrough
This is what you will experience: real SBOMFlow output from a pinned, offline sample run of the bundled example gateway, shown straight from the files it produced. No mock dashboard and no invented numbers — every figure on this page comes from that run, and the run was produced by the 0.5.0 engine on labelled synthetic data.
The run
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.
How a reviewer reads this
The release identity, its composition summary, and the state of the evidence — every later view traces back to this one record.
Each sample finding carries its match confidence and provenance. Notice what's absent: no automatic verdicts, no severity theatre.
Where observed evidence maps to the Annex I model, where it's manual-only, and where the gaps are — stated as facts, not scores.
The observed items a human still has to look at. This queue is the product's honesty made visible: nothing here resolves itself.
Informational until a policy is enforced, then explainable: the rule, the reason, and the result your CI sees. If your policy file cannot be read, the run says so instead of quietly running without it.
What changed against the previous sample release — added, removed, resolved, still open — the memory that makes evidence compound. “Nothing changed” and “nothing was compared” are reported as different results.
What this sample deliberately is not: proof about any real product, a compliance conclusion, or a hosted dashboard. It is the shape of the files you would own. Once you have the tester build, run the same thing on your own build with your first offline audit, or read the evidence-bundle guide your reviewers would use.
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.
Python 3.11+ and a real build tree — no accounts, no server, nothing sent anywhere, and no required runtime dependencies. A first audit writes the full artifact set: complete means every file is written, never a claim that the observation is complete. v0.5.0 is available to approved private testers.
