Use SBOMFlow without CRA assessment

The EU Cyber Resilience Act is one requirement regime SBOMFlow can apply. It is not a precondition. A run under requirement_regime: none produces the same SBOMs, vulnerability and VEX evidence, release gate, human review, reviewer bundle and custody records, and assesses no requirement at all.

Every command on this page is offline.

Choose no requirement regime#

Any one of these does it:

  • For one run: pass --requirement-regime none to analyze, audit, init or quickstart.
  • For a product: set requirement_regime: none in its sbomflow.yaml.
  • For a new product: sbomflow init DIR --requirement-regime none writes a config that already says so, without the CRA-only keys.

The run records the choice in its own evidence pack, so every later reader — review, next-actions, the reviewer bundle, a comparison with the next release — reads it from the run rather than from your current config.

Walk it#

The bundled gateway example stands in for your product:

bash
cp -R examples/embedded-linux-gateway gateway
cd gateway
sbomflow analyze . --output evidence --requirement-regime none
sbomflow validate evidence
sbomflow review evidence
sbomflow next-actions evidence
sbomflow explain evidence --gate
sbomflow audit . --output evidence-gated --requirement-regime none --fail-on-vulnerabilities
sbomflow sync-issues evidence --repo example-org/gateway
sbomflow init new-product --requirement-regime none
  • review reads unresolved_gaps=not assessed, and next-actions states that its list holds no gap action because no requirement was assessed.
  • The audit with --fail-on-vulnerabilities exits 1: the gate blocked the release on the example's findings. That is the gate working, and it works the same with no regime.
  • sync-issues is a dry run by default and plans no missing-evidence issue.
  • init new-product writes new-product/sbomflow.yaml with requirement_regime: "none" and a comment saying how to switch to cra.

What changes#

  • No CRA outputs. cra-coverage.json and cra-guidance-crosswalk.json are not written, and audit composes no technical-documentation pack, EU declaration draft or Article 14 draft.
  • Evidence gaps read "not assessed". The pack's evidence_gaps list is empty and its requirement_graph says why: nothing was assessed, by operator choice. An empty list here means not assessed, never "no gaps", and every surface that would show a gap count says "not assessed" instead of 0.
  • What needs a requirement assessment is refused, by name. --fail-on-gaps, --emit-techdoc, --emit-incident-report, the --incident-* options, a product.class other than default, and the technical_documentation, annex_i_evidence and due_diligence config keys are each refused with a message naming what to remove. standards-view and emit-user-info refuse the output directory, because they are views over a CRA assessment.
  • --fail-on-evidence-regression keeps only its review re-check part. The requirement-derived parts are dropped, and the drop is recorded in release-gate.json under regime_excluded_policies.
  • Release comparisons do not report a gap delta. When either release ran under none, the drift report, release notes and portfolio say the gap change was not compared, never zero.
  • Tracker labels. sync-issues and sync-jira default to the labels sbomflow,release-evidence instead of sbomflow,cra-evidence. An explicit --labels still wins.

The full list of what each artifact and reader shows for such a run is in Evidence outputs.

What never changes#

  • The SBOMs (CycloneDX and SPDX), the component inventory and its provenance.
  • Vulnerability matching, and VEX status that only a human review sets.
  • The release gate for the policies that do not need a requirement assessment, such as --fail-on-vulnerabilities.
  • Human review, approvals and the audit trail.
  • The reviewer bundle and its verification.
  • Custody sets and preserved artifacts — see Keeping runtime evidence in custody, whose example runs with requirement_regime: none.
  • Offline by default: a run makes no network request unless you opt in.

Compatibility#

An existing sbomflow.yaml with no requirement_regime key keeps cra, the default, and its runs are unchanged. To assess the CRA later, set requirement_regime: cra or remove the key; sbomflow help goal cra prints the steps.

See also#