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.

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.

Can I use it fully air-gapped? Yes. Run offline and use snapshot files for enrichment.

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 to see what is available in your version.

Is it released on PyPI/Homebrew yet? Not yet. Install from a clone today.

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. It is not a statement that the requirement is unmet.
• 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.