v0.5.5 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, embedded firmware or the software around them, who have to produce release evidence a reviewer can check — an SBOM, the vulnerability position, and now the traces, core dumps and test reports that show how the build actually behaved — and who can run a command-line tool against their own build, on their own machines, with no data leaving their environment. The EU Cyber Resilience Act is one regime it prepares evidence for; it is not the only reason to use it.

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 501 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 builds from two separate exports of the 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, in a fresh review that worked from the artifacts rather than from the reports about them.
• Two independent reviews of the final changes, each finding reproduced before it was fixed, and each fix carrying a test that fails without it.

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 release's source 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.

Tested against real, public samples#

Before this release was handed to anyone, it was run against real files that real projects and vendors publish, from single documents to a two-release product, and every run was repeated with byte-identical results. These are public samples published by their sources — not customer data, and not a customer validation.

• 30 real ICS security advisories published by CISA, covering products from 20 vendors — among them Siemens, Rockwell Automation, Hitachi Energy, ABB, Delta Electronics and CODESYS. Every file was first checked against CISA's own published SHA-512 checksum.
• Declared devices are matched exactly as the advisories spell them: in range, out of range, or not evaluated when an advisory's version text cannot be compared — never a guess, never "not affected".
• On a real Ubuntu 24.04 base image, advisories that name a source package reach every binary built from it: 184 distinct advisories, matching an independent Debian-version check one for one, none missing and none extra.
• On the real Alpine Linux 3.20.3 root filesystem every installed package was found and every advisory match was confirmed by an independent check (7 of 7, none missed); on the real OpenWrt 23.05.5 firmware root filesystem all 127 packages were found.
• Real large open-source estates: Kubernetes (454 Go modules, every vendored module accounted for), Discourse (1,991 Ruby and npm packages), Home Assistant (1,244 pinned Python packages across every requirements file) and rust-analyzer.
• 16 real CycloneDX SBOMs from the CycloneDX project's public examples (1,660 of 1,660 dependency edges kept) and 25 real SPDX 2.2/2.3 documents from the SPDX project's examples: every component and package imported or excluded with a stated reason.
• Real Grype, Snyk and Trivy scans of the public nginx image, with every result kept (99, 65 and 99), and real OpenVEX and CSAF VEX documents — the openvex project's examples and 20 real Red Hat CSAF VEX documents: every statement accounted for per document, and a statement that cannot be tied to a component is named, never applied.
• A two-release product assembled from real parts (an Alpine OS, OpenWrt firmware, a Rust application, a web application, a supplier SBOM, real VEX and CISA advisories) went through the whole release workflow twice, byte-identical, with 140 components added and 137 removed between releases.

Traces and crash evidence#

• Real Espressif core dumps from 5 chip families (ESP32, -C3, -C6, -S3, -P4): the firmware link — the application's SHA-256 prefix — read from every one, both as the device writes the image and as an ELF core.
• 49 real Arm CoreSight trace snapshot files (Linaro OpenCSD's test snapshots) and 4 real Eclipse ThreadX TraceX traces.
• Real Breakpad minidumps (46 of 46), PX4 flight logs (6 of 6, including the oldest log version), ROS 2 bag metadata (15 of 15) and LTTng/CTF trace metadata (101 of 104 read; the 3 unread are the corrupt cases upstream keeps so that tools refuse them).
• Real Android traces from Google's Perfetto project: the kernel release and device build a trace declares, from a 62 MB trace in under a tenth of a second.
• 24 real Wireshark packet captures, 60 real Foxglove MCAP recordings, 36 real Arduino bootloader HEX images, the MicroPython Raspberry Pi Pico UF2 release, and a Cortex-M firmware built with the GNU Arm toolchain whose HEX, S-record and UF2 images were checked byte for byte against its ELF; a one-byte change is caught.
• 1,000 trace captures from one CI job recorded into a custody set in about 5 seconds; two independent runs produce identical sets, and a single edited record or changed capture is caught.

Defects these samples exposed were fixed at the root before release and rerun — for example, a Rust workspace crate now carries the version it is built at, so an advisory fixed long ago no longer matches it. The whole campaign then ran twice more on the release code: every run clean, every output byte-identical, no crashes.

What materially changed#

The full, grouped list is on What's new. In summary:

• Trace, crash and test evidence joins the release. Keep the traces, core dumps and test reports a release was checked with, by identity, beside the release they belong to — reviewed by a named person, compared from one release to the next, and carried in the bundle a reviewer verifies without the originals. What a file's header declares is read and shown, never trusted on its own and never a gate by itself.
• Many more real formats read, from the files trace recorders, crash handlers, RTOS core-dump backends, trace and robotics tools and firmware image formats actually write — Supported inputs lists every one.
• Vulnerability matching is more exact on real systems: distribution advisories reach the binaries built from a source package; FIPS and extended-support builds are decided by their own stream; local and workspace dependencies are never matched as the public package of the same name; every pip requirements file is read; OSV's per-ecosystem archives are read offline.
• Sources you keep: a local CSAF advisory mirror as a vulnerability source, one answer to which stored release records a newly known-exploited identifier, and a tool's own vulnerability report kept as that tool's claim.
• Supplier evidence: a supplier's SBOM is checked against what the build shows, several SBOMs for one build can be compared fact by fact, and supplier VEX is accounted for document by document.
• Evidence without a regime: a run can assess no requirement regime at all, or your own requirement list; the CRA is one regime among several.
• Handing a release on: ReqIF for requirements-management tools, the package a customer's supplier intake reads, a CSAF advisory drafted from a reviewed case, and preservation holds on stored releases.
• The whole command line was reviewed for consistency, goal-based help and machine-readable output.

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.
• Red Hat CSAF VEX statements are accounted for but never applied. In the real Red Hat documents tested, no statement is applied to a component: they name products through CSAF product relationships, which this release does not yet bind to a component. Each statement is still counted per document. This fails safe — nothing is suppressed — and is a known restriction of this release.
• A declared identity is a file's own statement. SBOMFlow compares what a trace, dump or image declares about itself; that is never proof of where it came from. A trace reader reads headers and identity fields, not the recorded events.
• Native Windows is unproven. The verified platforms are Linux, macOS on Apple Silicon, and Windows via WSL.
• 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 — 61 of the 66 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.

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

What remains gated#

Five pieces 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. Capabilities names them so nobody infers availability from a catalogue entry. SBOM concordance, which shipped that way in v0.5.0, is reachable in this release.

AI runtime assurance is not what SBOMFlow does and is not finished; it remains design-partner gated.

Access status#

• v0.5.5 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. "Certified" is this project's own release process, not a third party's.
• 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.5 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.5.
• Known limitations — the standing list of limitations.
• v0.5.0 release record — the previous release.
• Overview — what SBOMFlow is, in one page.