Deterministic cybersecurity evidence engine

Deterministic cybersecurity evidence for connected-device teams.

SBOMFlow turns real builds, SBOMs, vulnerability data, reachability checks, release gates, and human review into traceable evidence for EU Cyber Resilience Act readiness workflows.

Offline by default Standard-library core CLI-first alpha Human review stays central

What it does today How the workflow runs

evidence/ offline

$ sbomflow audit . --output evidence --zip
✓ scan       components · dependency edges · file hashes
✓ sbom       cyclonedx-sbom.json · spdx-sbom.json
✓ vulns      offline sample feed · CVE-SAMPLE-*
✓ cra        annex i (2024/2847) · observed vs reviewed
✓ gate       informational — non-blocking by default
✓ bundle     evidence/evidence-bundle.html
✓ validate   structural checks passed

Offline demo · sample data labelled non-real human review required

Built on open standards CycloneDX 1.6 SPDX 2.3 Package URL OSV CISA KEV FIRST EPSS OpenVEX CISA SSVC CRA 2024/2847

The problem

Release evidence is scattered. Traceability is the hard part.

When a connected product ships into the EU, its security evidence is spread across build logs, SBOM tools, advisory feeds, trackers, spreadsheets, PDFs, consultants, and manual reviews. Assembling it at release time is slow — and little of it traces back to the exact build.

Build logs SBOM tools Vulnerability reports Jira / trackers Spreadsheets PDFs Consultants Manual reviews Firmware manifests Lockfiles

Connected-device teams don't need another paragraph of AI-generated compliance text. They need to answer concrete questions at release time: what shipped in this build, which vulnerabilities actually matter, what evidence exists, who reviewed it, and what changed since the last release.

Every answer has to trace back to a specific build artifact — and to the human who accepted it.

What SBOMFlow is

A deterministic evidence engine — not an AI compliance chatbot.

SBOMFlow observes; humans review. It derives evidence from real product files and builds, not from a prompt. Today it is a CLI-first foundation for connected-device, embedded, firmware, and product-security workflows.

Reproducible

Deterministic

Stable IDs, SHA-256 file hashes, and reproducible SBOM identity. The same inputs produce the same artifacts on every run.

No paid APIs

Offline-first

The standard-library core runs in locked-down CI and customer VPCs with no paid APIs. Network calls happen only when you explicitly request them.

Observed ≠ reviewed

Reviewer-aware

Machine-observed status is kept separate from human review status, which defaults to unreviewed. Observed evidence is never collapsed into a compliance conclusion.

Composition & SBOMs

Scans a product directory and reads an optional sbomflow.yaml config.
Extracts components from manifests and lockfiles — npm, Pipenv, Poetry, Cargo, Go, Composer, pnpm, Yarn Classic, and Bundler.
Reads embedded build outputs — Buildroot, Yocto image & license manifests, and Zephyr west.yml.
Normalizes Package URLs (purl) and preserves observed dependency edges.
Records package-manager provenance from supported lockfiles — resolved / tarball URLs, SRI integrity, and checksums — as observed facts; nothing is fetched, unpacked, or verified.
Generates SBOMs — CycloneDX 1.6 and SPDX 2.3, structurally validated and deterministic.

Vulnerability & exploitation context

Matches vulnerabilities offline against a clearly-labelled sample feed (CVE-SAMPLE-*), or the real OSV API with --use-osv.
Enriches with CISA KEV & FIRST EPSS — offline snapshot by default, live only on request.
Conservative reachability triage from source imports/includes (Python, JS/TS, Go, Rust, C/C++) — context only, never a verdict.
Reviewer-driven VEX and a suggested CISA SSVC priority — both opt-in and human-owned.

CRA-oriented mapping

Maps evidence to a versioned, officially-sourced CRA Annex I graph for Regulation (EU) 2024/2847.
Records the declared product class and route note — it does not classify the product for you.
Opt-in Annex VII technical-documentation pack with an UNSIGNED DRAFT EU declaration workspace.
Opt-in CRA Article 14 reporting drafts that are never filed, transmitted, or submitted.

Evidence, gates & handoff

Reviewer-aware evidence pack with deterministic, ticket-friendly missing-evidence gaps.
Release gate — informational by default; blocks only under explicit --fail-on-* policies.
Release history & drift across builds, variants, and channels.
Issues, reviewer bundles, and offline Jira / ServiceNow / GitHub issue plans for handoff.

Provenance & audit

SHA-256 hashes every scanned file into artifact-manifest.json for provenance.
Surfaces scan warnings — malformed or unsupported inputs are reported, never silently dropped.
Append-only audit log of the run lifecycle — IDs and counts only, no secrets or source.
Zero required third-party runtime dependencies — standard library only.

Who it's for

Built for the people who sign off on a release.

Product owners

Connected-device manufacturers

Embedded Linux, industrial IoT, robotics, and firmware-driven products heading into the EU market.

Engineering

Firmware & embedded teams

Connect build outputs, firmware manifests, lockfiles, and security tests to release evidence.

Security

Product-security teams

Triage vulnerabilities, reachability, VEX decisions, and evidence gaps from real artifacts.

Review

Compliance & quality reviewers

Prepare structured evidence and technical-documentation workspaces without overclaiming.

Release

Release managers

Use deterministic artifacts and explicit gates to support repeatable release decisions.

Readiness

CRA readiness owners

Assemble traceable, build-backed evidence for EU Cyber Resilience Act workflows.

Best fit today: 50–500-person embedded Linux or industrial IoT manufacturers with firmware CI and product-security ownership, preparing for CRA obligations. SBOMFlow is aimed at connected and embedded products — not only web apps.

How the workflow works

From real build artifacts to reviewer-ready evidence.

Analyze local artifacts

Point SBOMFlow at a real build or product directory. It reads source, lockfiles, embedded build manifests, configuration, and any local evidence you supply.

input · your build tree

Extract components & signals

Identify components, observed dependency edges, and high-precision evidence signals — exact file names, config keys, and CI action references, not vague prose.

purl-normalized

Generate SBOMs & provenance

Emit CycloneDX and SPDX SBOMs and SHA-256 hash every scanned file, so each piece of evidence traces back to the specific bytes it came from.

cyclonedx · spdx · sha-256

Add vulnerability context

Match advisories and — only when you ask — enrich with OSV, CISA KEV, and FIRST EPSS. Reachability stays conservative context, never an exploitability verdict.

offline by default

Map CRA-oriented readiness

Connect machine-observed signals to the versioned Annex I requirement model, keeping manual-only areas explicitly separate rather than guessed.

annex i · 2024/2847

Preserve the review boundary

Observed status never becomes acceptance. VEX not_affected / fixed and evidence acceptance come only from human review files.

observed ≠ accepted

Produce deterministic artifacts

Write the evidence pack, release gate, issues, reviewer bundle, and audit log — reproducible outputs for a release decision a human still owns.

13 default artifacts

Current foundation

An honest early alpha, built spine-first.

SBOMFlow is a working alpha foundation, not a finished platform. The point of this stage is a correct, deterministic core — so later work can't quietly become an untestable AI wrapper. There is no UI yet; the CLI and release-gate workflow come first.

CLI-first

Interface today

Offline by default

Network posture

Standard library

Runtime dependencies

13 default artifacts

Per analyze run

Deterministic

Output contract

Reviewer-aware

Evidence model

v0.2 · early alpha · coming soon

Status

What it's trying to become

Toward the release-evidence system for connected-device security.

The aim is to help manufacturers move from one-off compliance scrambles to repeatable, source-backed evidence on every release.

Now · Alpha

Deterministic CLI core

Build analysis, SBOMs, vulnerability context, CRA Annex I mapping, release gates, and reviewer handoff — offline and tested.

Next · Beta

Part of the release workflow

Deeper Annex I & Annex VII document validation
Stronger parsers for manufacturer-owned evidence
Build-attestation / provenance signature verification
Authenticated Jira & ServiceNow sync
Harmonized-standard mapping for Annex I

Later · Product

Continuous evidence platform

Broader validation against real customer build artifacts
Deeper reachability across source, build & firmware
SPDX 3.0.1 output as tooling matures
A product / portfolio UX — after the CLI is proven

Roadmap items are directional and not yet available. They are drawn from the project's development plan; order and scope may change. Nothing here implies a delivery date or a compliance guarantee.

Principles

Boundaries that don't move.

These are engineering invariants for the project — the reasons SBOMFlow stays trustworthy instead of becoming compliance theater.

No compliance theater

Reports are engineering gap assessments, not conformity claims.

No AI as source of truth

AI may draft or explain; evidence and humans decide. Core runs make no required model calls.

No legal conformity claims

SBOMFlow never asserts a product is CRA-compliant or legally conformant.

No network by default

Only explicit --use-osv / --use-kev / --use-epss paths may reach out.

Provenance is mandatory

Every report states its data source; scanned files are SHA-256 hashed.

Observed is not reviewed

Machine-observed status never becomes human acceptance on its own.

The reviewer boundary holds

VEX not_affected / fixed and acceptance come only from human review.

Sample data isn't intelligence

The offline feed is labelled non-real (CVE-SAMPLE-*) and never treated as real.

Example artifacts

Outputs you can read, diff, and hand to a reviewer.

Each analyze run writes a fixed set of deterministic files. They are observed evidence pending human review — not proof of compliance.

evidence-pack.json

Full machine-readable pack, with data-source provenance.

cyclonedx-sbom.json

CycloneDX 1.6 SBOM, structurally validated.

spdx-sbom.json

SPDX 2.3 SBOM with a deterministic namespace.

assessment-report.html

Human-readable report separating observed vs reviewed evidence.

cra-coverage.json

Annex I coverage by official reference, status, and gaps.

reachability.json

Conservative source-reference reachability triage.

release-gate.json

Pass/fail, violated policy, and the exact exit-code reason.

release-record.json

Release identity and generated-artifact hashes.

issues.json / issues.md

Actionable, stable-keyed issues derived from the gaps.

artifact-manifest.json

Every scanned file with its size and SHA-256.

scan-warnings.json

Non-fatal scan problems, surfaced rather than hidden.

audit-log.jsonl

Ordered, append-only run trail.

evidence-bundle.html / .jsonopt-in

Portable reviewer handoff bundle (default in audit).

vex.json / cyclonedx-vex.jsonopt-in

Reviewer-driven OpenVEX and CycloneDX VEX.

release-drift.jsonopt-in

Release-to-release deltas, VEX-aware.

ssvc.jsonopt-in

Suggested CISA SSVC priority for human review.

13 files are written on every analyze run; the marked artifacts are opt-in. The technical-documentation pack and CRA Article 14 drafts are also opt-in — any declaration output is an UNSIGNED DRAFT.

FAQ

Straight answers, no overclaiming.

Does SBOMFlow make us CRA compliant?

No. SBOMFlow is a deterministic evidence engine, not a compliance certification. It produces engineering gap assessments and traceable artifacts to support CRA-oriented work. It makes no conformity claim, and qualified human review is always required.

Does it replace legal or security review?

No. The engine observes; humans review and decide. Machine-observed status defaults to unreviewed, and acceptance, VEX not_affected/fixed, and any legal interpretation come only from people.

Does it require cloud APIs?

No — not for baseline operation. It runs offline with a standard-library core and no paid APIs. Network calls happen only when you explicitly enable OSV, CISA KEV, or FIRST EPSS, and customer code is not sent to third-party services by default.

Does it use AI as the source of truth?

No. Evidence comes from real files, builds, SBOMs, vulnerability data, and human decisions. AI may help draft or explain, but it is never the source of truth — and core runs make no required model calls.

Does it file CRA reports for us?

No. SBOMFlow never files, transmits, submits, or signs a report, and never contacts a CSIRT, ENISA, or the Single Reporting Platform. CRA Article 14 outputs are always UNSIGNED DRAFTS for a human to complete and submit.

Is it only for web apps?

No. It is aimed at connected and embedded products — embedded Linux, industrial IoT, robotics, and firmware-driven hardware — with support for build systems like Buildroot, Yocto, and Zephyr alongside common package ecosystems.

Is it production-ready?

Not yet. This is an early, deterministic alpha foundation (v0.2) with an offline test suite — not a finished enterprise platform. The CLI and release-gate workflow come first; a product UI is future work.

Is the offline vulnerability data real?

No. The default offline feed is a clearly-labelled sample (CVE-SAMPLE-*) for demos and tests. For real intelligence, enable OSV — and KEV/EPSS — explicitly. Those remain inputs for human triage, never automatic decisions.