[Bug] README claims the SBOM is "as required by" the CRA, which is the open question in #519 #532

Closed
opened 2026-07-22 10:54:57 +00:00 by brenno · 0 comments
Owner

Describe the bug

Three places describe the SBOM as an artefact the Cyber Resilience Act requires of us:

  • README.md:90 — "…covering every component, as required by the EU Cyber Resilience Act"
  • docs/SECURITY_DESIGN.md:75 — "the artefact required by the EU Cyber Resilience Act"
  • tool/sbom_build.dart:561 — emits a cra:regulation property naming EU 2024/2847

Why this is worth changing

Self-description does not determine legal scope — the facts do. But this wording states, in the project's most-read file, that a CRA obligation applies to us. That is precisely the question #519 is open on, and it is not settled: the manufacturer door looks shut on the current facts, while the open-source-software-steward route (art. 3(14) with art. 24(3)) is genuinely unsettled.

A sentence like this gets quoted back. It will end up in a supplier questionnaire, in a procurement answer, or in correspondence with a market surveillance authority, as evidence that the publisher considered itself in scope. That is an odd position to have taken by accident, in a README, before the analysis was done.

It also cuts against the project's stated line: hold the standards in behaviour, not in written promises. Building an SPDX SBOM because it is the right artefact is behaviour. Writing "as required by" turns it into a claim.

Proposed solution

State the same fact without asserting the obligation:

  • "the SBOM the CRA describes", or
  • "aligned with the EU Cyber Resilience Act", or
  • simply drop the clause — an SPDX 2.3 SBOM covering every component needs no external justification.

The cra:regulation property in the generated SBOM is defensible either way, since it names the standard the format follows rather than a duty; worth a look while nearby, not necessarily a change.

Deliberately not decided here

Which wording to use is a positioning choice for the maintainer, tied to #519. This issue records the finding and the reasoning; it does not pick the sentence.

Found during the #519 analysis, by reading the repository rather than by search — there may be more occurrences.

**Describe the bug** Three places describe the SBOM as an artefact the Cyber Resilience Act *requires of us*: - `README.md:90` — "…covering every component, **as required by** the EU Cyber Resilience Act" - `docs/SECURITY_DESIGN.md:75` — "the artefact **required by** the EU Cyber Resilience Act" - `tool/sbom_build.dart:561` — emits a `cra:regulation` property naming `EU 2024/2847` **Why this is worth changing** Self-description does not determine legal scope — the facts do. But this wording states, in the project's most-read file, that a CRA obligation applies to us. That is precisely the question #519 is open on, and it is not settled: the manufacturer door looks shut on the current facts, while the open-source-software-steward route (art. 3(14) with art. 24(3)) is genuinely unsettled. A sentence like this gets quoted back. It will end up in a supplier questionnaire, in a procurement answer, or in correspondence with a market surveillance authority, as evidence that the publisher considered itself in scope. That is an odd position to have taken by accident, in a README, before the analysis was done. It also cuts against the project's stated line: hold the standards **in behaviour, not in written promises**. Building an SPDX SBOM because it is the right artefact is behaviour. Writing "as required by" turns it into a claim. **Proposed solution** State the same fact without asserting the obligation: - "the SBOM the CRA describes", or - "aligned with the EU Cyber Resilience Act", or - simply drop the clause — an SPDX 2.3 SBOM covering every component needs no external justification. The `cra:regulation` property in the generated SBOM is defensible either way, since it names the standard the format follows rather than a duty; worth a look while nearby, not necessarily a change. **Deliberately not decided here** Which wording to use is a positioning choice for the maintainer, tied to #519. This issue records the finding and the reasoning; it does not pick the sentence. Found during the #519 analysis, by reading the repository rather than by search — there may be more occurrences.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck#532
No description provided.