FAQ & glossary

FAQ#

Does SBOMFlow make my product CRA-compliant? No. SBOMFlow produces engineering release-readiness evidence and reports gaps. It never claims compliance or conformity and is not legal advice.

Do I have to use the CRA view? No. The EU CRA is one requirement regime a run can choose. Every other goal — SBOMs, vulnerability triage, a CI gate, sign-off, release history, handoff, runtime-evidence custody — needs no requirement regime (set requirement_regime: none to run without one). See Use SBOMFlow without CRA assessment and Goals.

Does anything leave my machine? Not by default. A default audit makes zero network requests. Network actions are explicit, named, and opt-in, and send identifiers (not source or firmware). See Security & privacy.

Is there vendor telemetry? No. There is no vendor telemetry. metrics.json is local, opt-in, and yours.

What licence is SBOMFlow under, and where are the evaluation terms? SBOMFlow is proprietary. The licence notice travels with every copy, and the terms for an evaluation, a pilot or a design-partner arrangement are requested rather than published. Evaluation terms & access says where each one is; it is a signpost and states no term of its own.

Can I use it fully air-gapped? Yes. Run offline and use snapshot files for enrichment. For advisories, download OSV's archive for your ecosystem on a connected machine (for example https://storage.googleapis.com/osv-vulnerabilities/Alpine/all.zip), record its SHA-256, copy it across, and pass it as it is: --osv-snapshot all.zip. The digest of the archive you gave is recorded in the run.

Which build inputs are supported? Common lockfiles/manifests, container/firmware inputs, and imported CycloneDX/SPDX SBOMs, plus specialist importers. "Supported" means tested — run sbomflow help build-inputs (or sbomflow help all for every command) to see what is available in your version.

How do I get v0.5.5, and is it on PyPI or Homebrew? v0.5.5 is available to approved private testers, and it is not on any public package index. pip install sbomflow and pip install 'sbomflow[extra]' resolve the name against an index that does not carry this release, so they fail. You receive the wheel through the controlled access channel, check its SHA-256 against the published digest, then install from that local file with --no-index --no-deps. Installation has the exact steps.

Does a matching checksum mean the build is signed? No. The checksums prove the bytes you received match the bytes the build produced. They are not a signature and do not establish who built them. This build is unsigned and carries no continuous-integration attestation.

What does "certified tester build" actually mean? "Certified" here is our own release-certification process, not a third party's. No external body assessed this build. Concretely, it means every mandatory lane in that process ran and passed on one immutable commit — a skipped lane never counts as a passed one — the wheel rebuilt byte-for-byte from the same source tree, and the built wheel installed into a clean environment with the package index disabled and was then exercised end to end. What was and was not established is itemised on the v0.5.5 release record; the previous release has its own record.

It means no known release-blocking defects, subject to the documented restrictions. That is not the same as error-free, which cannot be proven: it is a statement about the defects that were found and closed, not about defects nobody found. It is not a conformity, certification, safety or security verdict about anything — least of all about your product.

How do I uninstall it, and where does my data live? Everything SBOMFlow produced lives in the output directories you named with --output (plus any sbomflow.yaml you created) — nothing is written to hidden locations, and there is no account or server side to close. Uninstall the package and delete those directories; the uninstall & offboarding steps walk through it.

Glossary#

• SBOM — Software Bill of Materials; the inventory of components in a build.
• VEX — Vulnerability Exploitability eXchange; a statement (e.g. not_affected) about whether a vulnerability affects a product. In SBOMFlow, VEX status comes only from human review.
• Evidence gap — a requirement area where evidence was not observed, in a run assessed under a requirement regime. It is not a statement that the requirement is unmet.
• Requirement regime — the set of requirements a run is assessed against, if any. cra (the EU CRA) is the one offered today and the default for a configuration that does not set one; none assesses nothing. See Use SBOMFlow without CRA assessment.
• Not assessed — what a run under requirement_regime: none reports wherever a gap count or coverage figure would appear. It means nothing was assessed, never that there are no gaps.
• Custody set — a directory holding the records of runtime or test evidence SBOMFlow cannot read (traces, dumps, captures), each by its SHA-256, with what people stated about it, named reviewers' decisions and a hash-chained audit log. It proves byte identity, never what a file shows. See Keeping runtime evidence in custody.
• Preserved artifact — one file SBOMFlow keeps by identity instead of reading it (a trace, a crash or core dump, a test report): its SHA-256 and what a person stated about it. A run reads the record only when sbomflow.yaml declares it under preserved_artifacts:, and a named reviewer's decision is bound to its review key, preserved-artifact:sha256:<digest>. See Runtime and test evidence.
• Release gate — an engineering pass/fail control based on manufacturer policy.
• Provenance — the recorded origin (including SHA-256 hashes) of every input.
• Drift — the difference in engineering artifacts between two releases.
• Observed vs reviewed — machine observation is never human review; see Observed vs reviewed.
• Finding — a specific vulnerability matched to a specific component in your build. Its stable identifier is the finding key, so the same finding is traceable across reports, VEX, waivers, and drift.
• Waiver — a reviewer's recorded, reasoned decision to accept a specific finding despite the gate. It is a human decision on record and never changes the observed facts.
• Reachability — conservative, deterministic context on whether a vulnerable component is referenced from your sources. It never sets VEX status and never suppresses a gate; not_observed only means no supported source reference was seen.
• KEV — CISA's Known Exploited Vulnerabilities catalog; an input that marks a vulnerability as known-to-be-exploited. It informs a human determination, never makes one.
• EPSS — FIRST's Exploit Prediction Scoring System; a probability input used for prioritisation, never a decision.
• SSVC — Stakeholder-Specific Vulnerability Categorization (CISA); SBOMFlow can suggest an SSVC action priority for human review, never a patch mandate.

Preferred terminology#

SBOMFlow keeps one word per concept so the CLI, reports, and docs read the same way. The glossary above is the canonical vocabulary. Preferred terms, and the wording the docs avoid:

A documentation check fails the build if deprecated wording appears in published prose, so the vocabulary above cannot silently drift.

Getting help & disclosure#

• Read any error offline: sbomflow help error <code>.
• Report a security issue responsibly via the project's security policy.
• File a bug, docs issue, or question with the repository's issue templates. A useful bug report takes under five minutes: include sbomflow --version and the output of sbomflow doctor . --json (local environment facts only — review it first). Never paste customer source, firmware, or credentials; SBOMFlow is offline-first, so a report should never need private artifacts.