Building in the open
About
SBOMFlow is founded and built by Amzat Karim, a London-based software engineer working on deterministic cybersecurity release evidence for connected products — SBOM, vulnerability, VEX, AI-evidence and CRA-oriented workflows. Everywhere else on this site we say what the engine observed and what it refused to claim. This page says who stands behind that, how it is built, and what the current build is still not.
Why this exists
A composition tool answers what is inside a build. The question a manufacturer has to answer at release is a different one: what did we know, when did we know it, who decided, and can we produce the same answer again in two years’ time. That is a record-keeping problem with an engineering shape — deterministic inputs, stable identifiers, provenance on every recorded fact, and a human decision stored as a decision instead of inferred from a scanner’s exit code.
So SBOMFlow is a deterministic, offline-by-default system of record for connected-device cybersecurity release evidence. For each firmware or software release it collects composition (SBOM), vulnerability context, reviewer decisions and an audit trail into reviewer-ready, portable evidence you own as plain files. The standing temptation in this category is to sell certainty; we would rather write “evidence not observed” and let a person decide what that means for their product.
The current build
Composition, vulnerability context, reviewer decisions and an audit trail land in one reviewer-ready evidence pack for a named product and release. The outputs are plain files in open formats — yours to keep, hand on and re-open without us.
Network access is never implicit. It takes an explicit opt-in flag, an explicit update command, an explicit apply step, or a configuration file that switches a source on. Local snapshot and file inputs stay offline, which is what makes the engine usable inside a locked-down build network.
SBOMFlow declares zero required runtime dependencies; a few optional extras add signing, schema validation and reachability, and a check whose extra is absent reports itself as skipped rather than quietly passing. Python 3.11 or newer and a real build tree are the whole environment — no account, no server, nothing to send anywhere. Install and optional extras →
v0.5.0 is available to approved private testers — a certified private tester build with no known release-blocking defects, subject to the documented restrictions. It is not on PyPI and there is no public download. What the tool does step by step is on the product page; how it was verified, and what that verification did not establish, is on the trust centre.
How it is built
Machine observation is never human review. A finding is suppressed only because a person reviewed it and recorded that decision — never because the engine decided on their behalf. Observed status and reviewed status are separate fields, and they stay separate all the way into the evidence pack.
A CVE match is evidence that something may apply, not a ruling that it does. Every finding records how it was matched, so the reviewer can judge the strength of the evidence rather than inherit a scanner’s confidence. Weak matching is visible as weak matching.
A release gate that quietly passes is worse than no gate. Until a human chooses a policy to enforce, the gate is informational and says exactly that — it reports that no policy is enforced rather than printing something that reads like approval.
SBOMFlow never files, transmits, signs or submits a regulatory report, and never contacts a CSIRT, ENISA or a reporting platform. CRA Article 14 outputs are always unsigned drafts for a person to complete and send. Exploitation signals are inputs to a human determination, never the determination.
The tool helps you see and assemble the engineering evidence that CRA obligations concern. It is not legal advice and makes no conformity claim. When it reports a gap, that means evidence was not observed — not that a requirement is unmet. Your lawyers, auditors and product-security leads keep the judgment; we try to make it faster and better-evidenced.
What we will not overstate
Every mandatory release-certification lane ran and passed for v0.5.0, and three byte-identical builds of the same tree were produced — on one machine, one interpreter and one operating system. That is same-environment reproducibility, and it is not a cross-platform claim. Here is the rest of it, stated in the same breath rather than in a footnote.
Known and published:
How the release was certified, lane by lane, is written up under testing & trust and the v0.5.0 release notes.
The founder
The engineering philosophy is visible in the product rather than stated about it: an offline evidence engine that records what it observed and what it refused to claim, a test suite that is allowed to refuse a release, and documentation written so a reviewer who has never met the author can check the work. The commercial side is deliberately behind that — pricing is under validation, access to v0.5.0 is by approval rather than download, and we would rather be told the evidence pack is unreadable than be told it looks impressive.
An invitation
One inbox, four conversations. None of them is a sales sequence, and none of the people below is represented on this site as a customer, partner, backer or collaborator.
You ship connected devices and want to see what the evidence record looks like for one of your real releases. Evaluate one release
Validation work arranged directly, from a build you actually ship, with every artifact staying yours. How an engagement runs
Reproducibility boundaries, explicit uncertainty, machine assistance kept apart from source-of-truth evidence, and honest limitations — open to discussion. Start a research discussion
Verifiable release evidence for connected products, at private-tester stage. This site states no customers, traction, revenue or funding; a conversation starts from what is here. Open an investment conversation
Connect with Amzat
These are Amzat’s professional profiles, not company accounts — the right places to see who is building this and to start a conversation that is not a support ticket. Email stays the only intake channel for SBOMFlow itself: there is no form behind this page and no sequence waiting on the other side of it. A person reads the inbox and answers yes, no, or not yet.