Public marketing
Outcomes, supported inputs and outputs, standards, network posture, human decision boundaries, capability status, honest limitations. Everything on these pages is drift-guarded against the code.
Trust centre
Trust the tool before you trust the evidence.
SBOMFlow runs over your source, firmware, and reviewer notes — so its own security posture is documented, not assumed. Everything on this page is stated as a self-assessment with pointers to the evidence; none of it is a certification claim.
Posture
Four facts a security review can start from.
01
Nothing leaves by default
Your code, SBOMs, and notes are read locally and written only to your output directory. Network egress happens only on explicit, named opt-in paths, and every network-capable path is listed in the public docs.
02
Secrets stay in the environment
Integration tokens are read only from environment variables, never from config or flags, and never written into any artifact. A poisoned-environment control proves no secret escapes into outputs, logs, or subprocesses.
03
Hardened network surface
The opt-in HTTP client enforces a scheme allowlist, an SSRF address guard (loopback, cloud-metadata, and private ranges refused), redirect re-validation, and a response-size cap.
04
Its own supply chain is thin
Zero required runtime dependencies, and SBOMFlow runs on itself — its own source tree goes through the same engine to produce its own SBOM. The prepared release workflow builds that SBOM + checksums and uses PyPI Trusted Publishing with attestations when the first tagged public release is approved.
Boundaries that don't move — enforced in the engine, not just on this page:
- Outputs are engineering evidence and gap assessments, never conformity claims.
- Observed is not reviewed — what the engine sees never becomes acceptance on its own.
- The reviewer has the final word on VEX status, evidence, and release decisions.
- It never files, transmits, or signs anything to a regulator — drafts stay unsigned and yours.
- AI is never the source of truth; the core makes no required AI calls.
- Provenance is mandatory — every result states its data source, and scanned files are hashed.
Tested for accuracy the way customers will actually use it
Engineering gateWe prove accuracy the way a real, messy manufacturer estate will: an in-house deterministic laboratory of ten synthetic connected-device businesses — full customer-shaped estates across Yocto, Zephyr, Buildroot, ESP-IDF, OpenWrt, ThreadX, and RPM — driven through the production CLI with their answer keys held out of reach. Positive controls (known-affected findings must be caught) and negative controls (known-clean components must stay clean) run with per-fact scoring that fails on any silent omission, false merge, false positive, missing provenance, or overclaim. Hostile inputs go through the shipped command, a tripwire fails any run that reaches for the network when it shouldn't, and mutation self-checks confirm the tests fail when the engine misbehaves — so a green run means something.
A recorded run of this laboratory is published, with its known gaps stated: the accuracy scorecard. 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
A deliberate three-layer disclosure model.
Trust does not require publishing the recipe. We publish what a buyer needs to evaluate the tool, document what a security review needs to verify it, and keep implementation detail that would only help an attacker — or a copycat — out of the public layer.
Public technical docs
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.
Private review
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
Found something? Tell us directly.
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 honestly what we find and when it's fixed.
FAQ
Straight answers, no overclaiming.
Does SBOMFlow make us CRA compliant?
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.
Will it expose or leak our source, firmware, or IP?
It runs offline by default with no paid APIs, and your code is never sent to third-party services by default. It only reaches the network for specific public vulnerability sources, and only when you explicitly enable them. Outputs carry identifiers, counts, and hashes — never your secrets or source.
How do you know its results are accurate?
We measure it, adversarially — see the laboratory above, and the recorded run on the accuracy scorecard. When something can’t be determined, it’s surfaced for human verification, never quietly dropped. The full pipeline is documented in Testing & trust — and it’s an engineering gate, not a claim of perfection.
How is this different from an SBOM generator or vulnerability scanner?
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 (Syft, Trivy, Grype, supplier SBOMs), 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.
What do we need to run it?
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). Start with your first offline audit.
Can auditors or customers read the evidence without installing SBOMFlow?
Yes. Every output is a portable file: a static reviewer console and evidence bundle open in any 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.
Is this an AI tool?
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.
Does it file CRA reports for us?
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 draft for a person to complete and submit.
Does it replace our legal, security, or compliance review?
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.
Is it production-ready?
The engine is deep and tested; the product experience is still being built. The offline engine runs today with a broad capability set behind thousands of deterministic tests. Post-market and passport workflows are experimental previews, AI Evidence is in development, and shared review surfaces are planned. Status labels on this site are enforced by tests — a planned feature can’t quietly call itself live.
Something we haven’t answered? Ask us directly at hello@sbomflow.com — straight answers only. Commercial questions live on the design-partners page.