v0.5.0 release record

This is the record of one release: what it is, who it is for, what changed in it, what was established before it was handed to anyone, what was not established, and how to ask for a copy. It is the public form of the same record the release was decided against internally — the same sections, at the disclosure level a public page can carry.

Nothing on this page is a conformity, certification, safety or security verdict about your product. It describes how this tool was built and checked.

Who this release is for#

Engineering, product-security and release teams shipping connected devices or embedded software into the EU, who have to produce release evidence a reviewer can check — and who can run a command-line tool against their own build, on their own machines, with no data leaving their environment.

It is for people who want the evidence assembled and the gaps named, and who expect a human to make the decisions. If you want a tool that reaches a compliance verdict for you, this is not that tool, and the boundaries below and on Capabilities say so at more length.

What it does#

SBOMFlow reads a build you already produce and turns it into a deterministic, offline-by-default release-evidence pack: an SBOM with stable component identity, vulnerability observations with recorded provenance, evidence gaps named rather than hidden, an explicit release gate, and a bundle a reviewer can verify independently. It observes; a human reviews. It never files a regulatory report and never claims conformity. Capabilities lists what is reachable, in development, and deliberately never done.

Release identity#

Every figure in this section and the next comes from the release-facts source the build publishes; none of it is typed by hand on this page.

One immutable candidate revision. No result recorded below was produced from a different revision, and results from different revisions are never combined.

The artifact#

Every one of the wheel's 385 archive entries was inspected, so the examined count and the total are the same number — which is the only reason a finding count of zero says anything at all.

Installation & access has the verify-then-install steps in full.

What certification established#

• Every mandatory release-certification lane ran and passed. None was skipped, and a skipped lane would never have counted as a pass.
• The build is deterministic in this environment. Three byte-identical builds of the same source tree produced the same wheel digest, from independent producers — including a rebuild in a separate working tree that had no part in producing the release artifact.
• A clean install works with the index switched off. The wheel installs into a fresh environment with the package index and dependency resolution both disabled, and the installed command was then exercised end to end.
• The install transcript carries no network markers. Five markers were swept for and none appeared — and each of the five was first shown to appear in a transcript of a networked install, so the zero is a measurement rather than a search that was quietly broken.
• The identity, the digest and the reproducibility were each re-established independently, not relayed from one report to the next.

Installed proofs#

The clean-machine journey — install the wheel into a fresh environment, run a review, enforce a gate, build a bundle, verify it, tamper with it, recover — ran end to end on this candidate and is documented step by step in the clean-machine installed journey.

Two facts about that run matter more than the pass:

• The journey environment deliberately has no optional extras. The wheel is installed without dependency resolution, so no optional extra is present. That proves the zero-dependency baseline; it proves nothing about any extra-gated surface.
• The four-layer bundle verification qualified at two of its four layers. The two content layers ran. The two signature layers need the cryptography extra that this environment cannot have, so the journey's own verdict stays NOT TRUSTED. That is the honest result of an unsigned bundle checked without the signing extra — not a covered surface, and not a failure.

What materially changed#

The full, grouped list is on What's new. In summary, v0.5.0 is a release about refusing to overstate, not about new surface area:

• Gates stopped collapsing "could not" into "did not need to." An unreadable gate file no longer prints as "no policy enforced"; an enforced AI control that could not run now blocks with its own reason code instead of contributing a pass.
• Release comparison can be made mandatory. A run that had nothing to compare against can now stop the pipeline instead of reporting "no drift", and a comparison with a missing side no longer reports the absent release as change.
• Vulnerability evidence carries better source provenance, and input handling is bounded on more paths.
• Sharing and redaction are stricter: the redaction contract now names supplier and originator identities and contact addresses, and no longer commits to bytes it cannot guarantee.
• AI and model evidence became reachable from ordinary commands — an AI evidence record on every analyze and audit, opt-in AI/ML BOM output, and an AI-entity view in explain. Nothing runs, loads, evaluates or scores a model, and no AI system is certified.
• Packaging and clean-machine installation were hardened, which is what made the verification above possible.

Limitations of this release#

• "No known release-blocking defects" is not "error-free". It means every defect found was closed, or accepted with its restriction written down. It is not a statement about defects nobody found.
• Native Windows is unproven. The verified platforms are Linux, macOS, and Windows via WSL. macOS on Intel is unverified — no run has been performed, so nothing is known either way.
• Optional trust layers are not claimed where their extra was absent. A check that could not run because an optional component was not installed reports that it was skipped; it never reports a pass.
• Most artifact schemas are experimental — twenty-four of the twenty-nine documented artifacts, listed in Artifact schemas, and they may change without notice.
• Some warning codes are registered but not currently emitted. The warning catalogue says so on the entry's own line.
• Three recovery playbooks are deferred. See Recovery playbooks.

Known limitations is the standing list; the entries above are the ones specific to this build.

What remains gated#

Five headline pieces of v0.5.0 are library foundations: the code exists, it has tests, and its warning codes are published — and no command, flag or configuration key reaches any of them. They are named so nobody infers availability from a catalogue entry:

• SBOM concordance
• AI feature traceability
• upstream AI lifecycle events
• the framework-adapter contract
• training-run receipts

AI runtime assurance is not what SBOMFlow does and is not finished; it remains design-partner gated. Dataset evidence, prompt evidence and redacted AI evidence sharing are planned, and nothing is built.

Access status#

• v0.5.0 is available to approved private testers. It is a certified private tester build with no known release-blocking defects, subject to the restrictions supplied with it.
• It is not on a public package index and not generally downloadable. Any instruction of the shape pip install sbomflow resolves a name that no index carries for this release, and it will fail.
• Approved testers receive the wheel, its SHA-256 digest, install instructions that keep the index disabled, and the written restrictions that apply to the build.
• Access is by approval, at no charge and with no commitment. It is a testing programme, not a purchase, and no organisation is represented as a customer.

How to request access#

Email hello@sbomflow.com — Request access to the v0.5.0 tester build — with a line about your product and your build system (Yocto, Zephyr, Buildroot, or other). We will arrange a short call to understand your release workflow and set you up.

The engine runs fully offline on your own machines, so nothing about your source, firmware, or findings ever leaves your environment. Evaluating it does not send us your code.

Related pages#

• Installation & access — receive, verify and install the build.
• Testing & trust — how the release was verified, in detail.
• What's new — the full change list for v0.5.0.
• Known limitations — the standing limitation list.
• Overview — what SBOMFlow is, in one page.