Building in the open
Trust centre
SBOMFlow reads your source, firmware, and reviewer notes — so its own behaviour has to be checkable from outside. This page lists the properties you can verify without taking our word for them, then shows exactly how the v0.5.0 build was checked, including what that check did not establish. Everything here is a self-assessment with pointers to the evidence; none of it is a certification claim.
Verifiable from outside
Your code, SBOMs, and notes are read locally and written only to your output directory. Network access happens only on explicit, named opt-in paths, every one of them listed in the public docs — and there is no telemetry to switch off.
With inputs and run context pinned, the same inputs produce the same artifacts, byte for byte; timing measurements are excluded from determinism checks. Run it twice and compare the hashes yourself.
Every result states its data source, and scanned files are hashed. What the engine could not read or could not determine is listed as a gap — never quietly dropped, never read as clean. Zero findings never means safe.
Observed is not reviewed. VEX status, evidence acceptance, and release decisions come only from recorded human review, and the release gate stays informational until you choose to enforce a policy.
Every output is a plain file you own; there is no database and no hidden state behind it. Bundles carry their hashes, and a recipient verifies them offline without installing SBOMFlow.
SBOMs in CycloneDX 1.6 and SPDX 2.3; VEX in OpenVEX, CycloneDX, and CSAF 2.0; SARIF and CSV exports; an optional in-toto attestation over the bundle — readable by the tools and trackers you already run.
Integration tokens are read only from environment variables, never from config or flags, and never written into any artifact. The opt-in network client is hardened against redirection to internal addresses and oversized replies.
Zero required runtime dependencies, and SBOMFlow's own source goes through the same engine to produce its own SBOM. Today's v0.5.0 wheel is unsigned: its published SHA-256 is an integrity check, not a signature. Signed publication with build attestations is prepared for the first public release and is not yet in use.
Boundaries enforced in the engine, not just on this page:
v0.5.0 is a certified private tester build with no known release-blocking defects, subject to the documented restrictions. It is not published to PyPI and is not generally downloadable; approved testers receive the wheel through a controlled channel. Everything below is stated so you can check it rather than take it on trust — including the parts that were not established.
✓ tag v0.5.0 ✓ commit 36ac6478dd85aae9b35b99741ca201b80a249b9b ✓ wheel sbomflow-0.5.0-py3-none-any.whl ✓ sha256 89a26452037dcaf523ff94132cc6c4ae92273f0c9aa82d8c15eab52342b54928 ✓ rebuild three byte-identical builds (one machine, one interpreter, one OS) ✓ install clean environment · zero network markers in the transcript ✓ package 385 of 385 archive entries inspected › unsigned · no build-service attestation · not a conformity or security verdict
Compare the SHA-256 against the file you receive. That comparison proves the bytes match the bytes the build produced — it is an integrity check, not a signature, and it does not establish who built them. We inspected every file inside the build we ship — all 385 — so “nothing found” means nothing was found, not that nothing was looked at.
The full v0.5.0 release record What changed in 0.5.0
What was established, and how:
What was not established — read this part twice:
Every number above has an examined count behind it, and every absence was calibrated against a case where it was shown to appear. A sweep that reports zero without ever having been seen to find one is not evidence, and none of the zeros here are that.
Accuracy is measured adversarially, against what a real, messy manufacturer estate looks like: the synthetic manufacturer laboratory — ten synthetic connected-device businesses, full customer-shaped estates across Yocto, Zephyr, Buildroot, ESP-IDF, OpenWrt, ThreadX, and RPM — driven through the production CLI. A green run has to mean something, so:
A recorded run of this laboratory is published, with its known gaps stated, as the accuracy scorecard. That recorded run was produced by 0.4.0; no run for 0.5.0 is published yet, and none is simulated. Separately, the Evidence Assurance Benchmark scores the installed product itself and publishes a number only when a qualified, independently re-verified receipt exists. Every name, domain, and file in the laboratory is fictional and labelled non-real.
A strong engineering gate — not a security certification or a proof of CRA conformity. It measures how accurately and safely the tool behaves under customer-shaped pressure. It makes no claim about your product.
What we publish, and what we don't
Trust does not require publishing the recipe — and nothing here relies on hiding one. Every security property above is observable from outside; what stays private is engineering detail, not a control. We publish what a buyer needs to evaluate the tool, document what a security review needs to verify it, and keep the implementation recipe out of the public layer.
Outcomes, supported inputs and outputs, standards, network posture, human decision boundaries, capability status, stated limitations. Every figure, digest, date and test-bound status label on these pages is drift-guarded against the code.
Data flows, the network opt-in matrix, secret-handling policy, trust boundaries, validation methods, artifact verification instructions, residual risks — enough for a responsible evaluation without a call with us. Start at security & privacy and security-review readiness.
Detailed architecture, control implementation evidence, internal test reports, and non-public roadmap sequencing are available to qualified prospects and reviewers under an appropriate confidentiality process — ask.
Security reporting
Report suspected vulnerabilities in SBOMFlow to hello@sbomflow.com with "SECURITY" in the subject. We read every report, we won't pursue anyone acting in good faith, and we'll tell you what we find and when it's fixed.
FAQ
No. SBOMFlow helps you collect, connect, and review cybersecurity evidence; it is not a certification and grants no regulatory approval. It produces engineering evidence and gap assessments to support CRA-oriented work, and qualified human review is always required.
It runs offline by default with no paid APIs, and your code is never sent to third-party services by default. It reaches the network only on named opt-ins — public vulnerability sources, and the tracker or notification integrations you explicitly apply. There is no telemetry to switch off. Outputs carry identifiers, counts, and hashes, and are designed never to include your secrets or source; an export preflight refuses secret-shaped content.
We measure it, adversarially — see the laboratory above, and the recorded 0.4.0 run on the accuracy scorecard; no 0.5.0 run is published yet. When something can’t be determined, it’s surfaced for human verification, never quietly dropped. The method is documented in Testing & trust — and it’s an engineering gate, not a claim of perfection.
A generator answers “what’s in this build?” — SBOMFlow answers what happens next. It builds validated SBOMs from what it observes and also ingests the output of tools you already run (Trivy and Grype output, supplier SBOMs, and Syft when it is installed locally), then adds the layer those tools stop at: human review with recorded decisions, multi-role approvals, an explainable release gate, release-to-release drift, and a tamper-evident audit trail.
Python 3.11+ and a real build tree — that’s it. Zero required runtime dependencies, no accounts, no server, nothing to send anywhere. It runs fully offline on a laptop or in locked-down CI (GitHub Actions, GitLab, Jenkins). Once you have the tester build, start with your first offline audit.
Yes. Every output is a portable file: a static reviewer console and evidence bundle open in a browser with nothing installed, a no-install auditor package is built for exactly that handoff, and a redactable sharing pack covers importers and distributors. Hashes travel with the evidence, so a recipient can verify nothing was altered. See read an evidence bundle.
No — the evidence path is deterministic: results come from real builds, files, and human decisions, and the core makes no required AI calls. Separately, SBOMFlow is extending the release record to describe the AI inside your products — that AI Evidence capability is in development and clearly labelled. Sealed output from an external AI-assisted scanner can be imported as labelled, needs-review observations — never as SBOMFlow findings.
No. SBOMFlow never files, transmits, submits, or signs anything, and never contacts a regulator or reporting platform. Any incident or declaration output is a clearly-marked UNSIGNED DRAFT for a person to complete and submit.
No. The engine observes; your people review and decide. It is designed to make expert review faster and better-evidenced — not to replace lawyers, consultants, auditors, or your own sign-off.
The engine is deep and tested; the product experience is still being built. The offline engine is available today with a broad capability set behind thousands of deterministic tests. The current build, v0.5.0, is a certified private tester build with no known release-blocking defects, subject to the documented restrictions — which is a narrower statement than production-ready and is meant to be. Post-market and passport workflows are experimental previews, AI Evidence is in development, and shared review surfaces are planned. On the AI Evidence and use-case pages, status labels are enforced by tests against the capability record, so a planned feature can’t quietly call itself live.
v0.5.0 is available to approved private testers. It is not on PyPI, there is no public download, and there is no installer to point you at. Approved testers receive the wheel through a controlled channel with its SHA-256, install it with the package index and dependency resolution switched off, and compare the digest against the value published above. That comparison proves the bytes are the ones the build produced; it is not a signature, and the build is unsigned. Ask at hello@sbomflow.com.
Something we haven’t answered? Ask us directly at hello@sbomflow.com — straight answers only. Commercial questions live on the design-partners page.
Everything above is written to be checked rather than believed. Start with the sample run — real v0.5.0 output on labelled synthetic data, read the way a reviewer would. Once you have the tester build, run an audit against a build you already know well and read what the run says it did not establish; your first offline audit walks through it.