[Bug] README claims the SBOM is "as required by" the CRA, which is the open question in #519 #532
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck#532
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 acra:regulationproperty namingEU 2024/2847Why 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
cra:regulationproperty 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.