SBOMFlow

Building deterministic cybersecurity evidence tooling for connected-device teams preparing for EU CRA workflows. Offline-first. Human-reviewed.

[SBOMFlow @SBOMFlow]

SBOMFlow is in development.

We’re building deterministic cybersecurity evidence tooling for connected-device manufacturers preparing for EU CRA workflows.

Real builds. SBOMs. Vulnerability evidence. Release gates. Human review.

No compliance theater. Evidence first.

[SBOMFlow @SBOMFlow]

A CVE in your SBOM is not a vulnerability in your product.

VEX in CycloneDX, OpenVEX and CSAF. KEV and EPSS as opt-in context, never as the decision.

not_affected requires a valid CISA justification, or we downgrade it.

https://t.co/pVnZ3VNEII

[SBOMFlow @SBOMFlow]

Genuine question for anyone shipping connected devices:

when an auditor asks "what was in release 4.2.1, and who approved it" — how long does that take you today?

Hours? Days? Nobody knows?

No pitch. Actually collecting answers.

[SBOMFlow @SBOMFlow]

400+ warning codes.

Not features. Distinct ways the engine says "I could not read this", "this is ambiguous", or "a human needs to decide".

Nothing fails silently. That is the design.

https://t.co/pVnZ3VOcyg

[SBOMFlow @SBOMFlow]

Most SBOM tools quietly skip firmware.

Yocto · Buildroot · Zephyr (west) · PlatformIO · Arduino · CMake · vcpkg

Seven embedded build systems, read in the same run as npm, Cargo, Go and Maven. 15 families, 22 manifest formats.

https://t.co/pVnZ3VOcyg

[SBOMFlow @SBOMFlow]

ENISA has confirmed there will be no API for the Single Reporting Platform at this stage.

Submissions are manual, through an online form.

Your 24-hour early warning is a qualified person logging in and typing under time pressure. Build for that.

[SBOMFlow @SBOMFlow]

We publish our own failure list.

Every SBOMFlow run emits a scorecard naming what it did NOT establish. Not what we're proud of — what is still unverified.

If a tool can't tell you that, you can't hand its output to an auditor.

[SBOMFlow @SBOMFlow]

25 days.

On 11 September, reporting an actively exploited vulnerability to ENISA becomes a 24-hour obligation — on products already on the market.

You cannot report what you cannot inventory.

[SBOMFlow @SBOMFlow]

After every firmware release, the question is not only “what shipped?” It is “what changed?”

SBOMFlow compares components, vulnerabilities, evidence gaps, reviewer decisions and gate outcomes—then preserves the result as a portable artifact.

https://t.co/dUUPmmxWuJ

[SBOMFlow @SBOMFlow]

Release evidence is useful only if later edits are visible.

SBOMFlow records reviewer sign-off in an append-only, hash-chained trail—with expiry, revocation and separation of duties built in.

Trust is a property of the record, not the dashboard.

https://t.co/dUUPmmxWuJ

[SBOMFlow @SBOMFlow]

We’re working with connected-device teams preparing repeatable CRA release evidence—not one-off compliance theatre.

If your firmware pipeline runs on Yocto, Zephyr, Buildroot or containers, tell us where your current process breaks.

[email protected]
https://t.co/dUUPmmxWuJ

[SBOMFlow @SBOMFlow]

Security evidence should survive the tool that created it.

SBOMFlow outputs CycloneDX, SPDX, VEX, SARIF, JSON, HTML and signed evidence bundles—then fits into GitHub, GitLab, Jenkins, Jira, ServiceNow and Dependency-Track.

No black-box record.

https://t.co/dUUPmmyukh

[SBOMFlow @SBOMFlow]

A CVE score alone is not release context.

SBOMFlow combines CISA KEV, FIRST EPSS, conservative source reachability and reviewer-owned VEX for each component finding—without letting automation declare a product safe.

Evidence first. Human decision last.

https://t.co/dUUPmmxWuJ

[SBOMFlow @SBOMFlow]

We’re looking for connected-device manufacturers willing to test SBOMFlow against real product builds.

If your team is preparing for CRA workflows and still assembles release evidence manually, we would like to hear how you work.

[email protected]

[SBOMFlow @SBOMFlow]

A cybersecurity evidence tool earns trust by what it refuses to automate.

SBOMFlow will not:
• claim compliance
• approve a release
• invent evidence
• ignore malformed inputs
• file a regulatory report

Evidence first. Human authority preserved.

https://t.co/dUUPmmxWuJ

[SBOMFlow @SBOMFlow]

Two CRA dates connected-device manufacturers should know:

11 September 2026: reporting obligations begin.
11 December 2027: the main obligations apply.

The evidence workflow should exist before the deadline—not be assembled afterwards.

#CyberResilienceAct

[SBOMFlow @SBOMFlow]

If identical inputs can produce a different answer, the release record is not trustworthy.

SBOMFlow produces reproducible artifacts you can diff. Every scanned file is hashed. Every evidence item records its source.

No black-box verdict.

https://t.co/dUUPmmyukh

[SBOMFlow @SBOMFlow]

Most security tooling was built for web applications.

Connected products need a different evidence trail.

SBOMFlow already reads Buildroot, Yocto, Zephyr, containers and 10+ package ecosystems—then traces what reached the release.

https://t.co/dUUPmmyukh

[SBOMFlow @SBOMFlow]

An SBOM is not a release record.

A SBOMFlow release record connects:
• CycloneDX and SPDX SBOMs
• vulnerability context
• CRA-oriented evidence coverage
• reviewer decisions
• release gates
• a hash-verified evidence bundle

See the workflow: https://t.co/dUUPmmxWuJ

[SBOMFlow @SBOMFlow]

One CVE. Two affected components. Two separate findings.

SBOMFlow binds every review and waiver to the exact component and version—so a decision about one component cannot silently suppress another.

Small detail. Serious trust boundary.

https://t.co/dUUPmmyukh

[SBOMFlow @SBOMFlow]

A scanner can observe. It cannot approve.

SBOMFlow keeps machine observations separate from reviewer decisions, approvals and release sign-off.

The engine provides evidence. Your people make the call.

https://t.co/dUUPmmyukh