LibreKAT/Ocideck

Watch

Fork 0

[Question] Does the CRA reporting duty apply to OciDeck? #519

New issue

Closed

opened 2026-07-22 09:28:35 +00:00 by brenno · 1 comment

brenno commented

2026-07-22 09:28:35 +00:00

Owner

tool/check_service_norms.dart measures our own internal response norms for security reports (first response 5 working days, verdict 10, resolution 90 days) and states explicitly that it does not measure CRA conformity. That exposes a question the tool deliberately left alone.

The Cyber Resilience Act ((EU) 2024/2847, art. 14) obliges manufacturers, from 11 September 2026, to report an actively exploited vulnerability in their product to the CSIRT and ENISA: an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days. Different clocks, different recipients and a different trigger than our own norms — and nothing in the repository tracks them or even mentions them.

This is a weighing question first, not a build task.

Establish whether OciDeck falls within scope at all. The hinge is the position of free and open source software not placed on the market within the meaning of the regulation. The answer is not self-evidently yes. A related decision already exists — LibreKAT is open source, not a manufacturer, and holds the standards voluntarily in behaviour — but the art. 14 reporting duty is a separate question that decision does not answer.
If it applies: determine what is needed (contact point, procedure, who reports, where the trail is kept) and whether that should be measured or only recorded.
If it does not: record the conclusion with the reasoning somewhere that does not read as a public promise — so not in docs/ (bundled as an asset, and docs_registration_test forces a reader tile) and not in SECURITY.md. See the header of tool/check_service_norms.dart for the reasoning behind that placement.

Do not invent article numbers: check against the text of the regulation and date the conclusion.

`tool/check_service_norms.dart` measures our own internal response norms for security reports (first response 5 working days, verdict 10, resolution 90 days) and states explicitly that it does **not** measure CRA conformity. That exposes a question the tool deliberately left alone. The Cyber Resilience Act ((EU) 2024/2847, art. 14) obliges manufacturers, from 11 September 2026, to report an **actively exploited** vulnerability in their product to the CSIRT and ENISA: an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days. Different clocks, different recipients and a different trigger than our own norms — and nothing in the repository tracks them or even mentions them. **This is a weighing question first, not a build task.** 1. Establish whether OciDeck falls within scope at all. The hinge is the position of free and open source software not placed on the market within the meaning of the regulation. The answer is not self-evidently yes. A related decision already exists — LibreKAT is open source, not a manufacturer, and holds the standards voluntarily *in behaviour* — but the art. 14 reporting duty is a separate question that decision does not answer. 2. If it applies: determine what is needed (contact point, procedure, who reports, where the trail is kept) and whether that should be measured or only recorded. 3. If it does not: record the conclusion **with the reasoning** somewhere that does not read as a public promise — so not in `docs/` (bundled as an asset, and `docs_registration_test` forces a reader tile) and not in `SECURITY.md`. See the header of `tool/check_service_norms.dart` for the reasoning behind that placement. Do not invent article numbers: check against the text of the regulation and date the conclusion.

brenno added the

triage

label

2026-07-22 09:28:35 +00:00

brenno commented

2026-07-22 10:54:40 +00:00

Author

Owner

Analysis — no conclusion; the decision is deliberately left to the maintainer. All provisions cited below were checked against the authentic text of Regulation (EU) 2024/2847 (CELEX 32024R2847, OJ L of 20.11.2024), retrieved on 2026-07-22. No article or recital number in this comment is from memory. Dutch implementation details (which body is the designated CSIRT coordinator, whether the ENISA single reporting platform is operational) were not verified and are marked as open below. This is an analysis by a maintainer's tooling, not legal advice.

1. The legal structure of the question

Article 14 addresses "a manufacturer". Whether the duty attaches therefore runs through two separate doors:

Door 1 — manufacturer. The Regulation applies to products with digital elements made available on the market (art. 2(1)). "Making available on the market" means supply for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge (art. 3, point 22). Free-of-charge supply is thus not the exemption; absence of commercial activity is. Recital 18 is explicit on what that means for FOSS:

provision of FOSS not monetised by its manufacturers is not a commercial activity;
financial support from third parties, or contributions by manufacturers, does not in itself make it commercial;
the mere presence of regular releases does not in itself make it commercial;
development by a not-for-profit organisation is not commercial provided the organisation is set up so that all earnings after costs are used to achieve not-for-profit objectives.

Recital 20 adds that merely hosting software on open repositories or collaboration platforms is not making available on the market.

Door 2 — open-source software steward. A "steward" is a legal person, other than a manufacturer, that systematically provides sustained support for the development of specific FOSS products intended for commercial activities, and ensures their viability (art. 3, point 14; recital 19 names foundations explicitly). This regime exists precisely for FOSS that is published but not made available on the market (recital 19). Crucially, art. 24(3):

"The obligations laid down in Article 14(1) shall apply to open-source software stewards to the extent that they are involved in the development of the products with digital elements."

So a foundation that escapes the manufacturer definition can still carry the actively-exploited-vulnerability notification duty through the steward regime — and the second sentence of art. 24(3) additionally applies the severe-incident duty (art. 14(3)) where such incidents affect network and information systems provided by the steward for the development of the product, i.e. the project's own forge. Two softeners are in the text: stewards are exempt from all administrative fines (art. 64(10)(b) — "any infringement of this Regulation by open-source software stewards"), and market surveillance authorities retain only cooperation/corrective instruments (art. 24(1)-(2)). Article 14 applies from 11 September 2026 (art. 71(2)); notifications go via the single reporting platform (art. 16) to the CSIRT designated as coordinator of the Member State of main establishment, simultaneously accessible to ENISA (art. 14(7)).

2. Facts from this repository that bear on the question

Publisher is Stichting LibreKAT, a Dutch foundation; licence is EUPL-1.2 (LICENSE.md).
No releases exist: no release tag, no binaries distributed, no update mechanism, no version display; users build from source from the default branch (SECURITY.md).
No monetisation is visible anywhere in the repository: "No support contract, no paid tier, no second line" (docs/TROUBLESHOOTING_GUIDE.md); no donation or sponsorship links; CODE_OF_CONDUCT.md states the project acts on public values, not commercial interests.
Distribution is source-only via the project's own Forgejo forge — squarely the recital 20 situation.
A security contact point already exists (security@librekat.nl, SECURITY.md), with a documented triage model and internal, deliberately unpublished response norms measured by tool/check_service_norms.dart — which states in its header that it does not measure CRA conformity.
The product includes the MIAUW penetration-test reporting module, aimed at professional pentest practice — relevant to the steward hinge "intended for commercial activities" (see §3).
The publisher operates one ancillary service (cveapi.librekat.nl, a free CVE mirror) and the development forge itself — relevant to art. 24(3), second sentence, if steward status is assumed.
Tension worth naming: README.md:90 describes the SBOM as shipped "as required by the EU Cyber Resilience Act" (similar framing in docs/SECURITY_DESIGN.md:75, and cra:regulation properties emitted by tool/sbom_build.dart). Self-description does not determine legal scope — the facts do — but this wording reads as self-identification with a manufacturer obligation and will be quoted back in any questionnaire. Tracked separately.

3. The arguments, both ways

That art. 14 does not attach (manufacturer door stays shut). On the repository's facts, every recital-18 indicator points the same way: no monetisation, no paid tier, source-only distribution on the project's own forge, a foundation publisher. If the foundation's statutes contain the earnings-after-costs clause, the not-for-profit limb of recital 18 applies on top. On those facts OciDeck is not "made available on the market", LibreKAT is not a "manufacturer" within art. 3(13) read with art. 3(22), and art. 14 — addressed to manufacturers — does not attach. Even a future tagged release with binaries would not, by itself, change this (recital 18: regular releases alone are not commercial activity).

That a reporting duty may attach anyway (steward door). Stichting LibreKAT matches the structural elements of art. 3(14) uncomfortably well: a legal person, not a manufacturer, providing systematic and sustained support (it hosts the forge, governs and steers development — the exact activities recital 19 lists), and ensuring the product's viability. The open element is "intended for commercial activities". Recital 19 glosses that as integration into commercial services or into monetised products — an integration-flavoured reading under which an end-user application would fall outside. But OciDeck's pentest module is explicitly built for professional — that is, commercial — engagements, and whether end-use in commercial activities satisfies the phrase is genuinely unsettled. Commission guidance on the Regulation's scope "with a particular focus on … free and open-source software" is mandated (art. 26(2)(a)) but, as far as could be established here, not yet available. If steward status is assumed, art. 24(3) makes art. 14(1) apply "to the extent that they are involved in the development" — and this foundation is the developer, so the duty would bite in practice, with the 24h/72h/14d cadence of art. 14(2), plus the severe-incident duty for the forge infrastructure. The counterweights: no administrative fines can be imposed on stewards for any infringement (art. 64(10)(b)), and the steward regime's remaining obligations (art. 24(1): a documented cybersecurity policy fostering secure development and vulnerability handling) describe things this project largely already does in behaviour.

4. If the duty applies (or is voluntarily followed): what would actually be needed

The trigger is narrow — becoming aware of an actively exploited vulnerability in OciDeck (art. 14(1)) — a different event, clock and recipient than anything the existing service norms measure.

Who reports: the existing single-correspondent model in SECURITY.md already answers this.
Where: the single reporting platform (art. 16), via the CSIRT designated as coordinator of the Member State of main establishment — for a Dutch foundation, the Netherlands. Not verified here: which Dutch body holds that designation, and whether the ENISA platform is operational before 11-09-2026.
The trail: the tracker already carries a "Binnengekomen:" convention read by tool/check_service_norms.dart; an "actively exploited" marker on a tracking issue would date the awareness moment, which is what the 24-hour clock hangs on. That is recording, not measuring.
Measured or only recorded: with zero incidents to date there is nothing to measure; a short written procedure (trigger, who, where, the three deadlines) is the whole deliverable.

5. If the duty does not apply: where the conclusion should land

Not in docs/ (bundled as an asset with a forced reader tile — a public promise) and not in SECURITY.md, per the reasoning in the header of tool/check_service_norms.dart. The natural home is assurance/, which exists for exactly this kind of dated, non-promissory internal reasoning — e.g. assurance/CRA-2024-2847-positie.md, containing the facts relied on, the two doors above, the date, and explicit re-evaluation triggers: any monetisation connected to OciDeck; distribution of binaries through a channel that is not the project's own repository; a hosted instance offered to others; publication of the art. 26 Commission guidance on FOSS scope; and any change to the foundation's statutes. A one-line pointer from the check_service_norms.dart header would connect the tool's disclaimer to the recorded position.

6. What cannot be established from the repository

The statutes of Stichting LibreKAT (the recital-18 earnings-after-costs clause).
Any off-repository monetisation connected to OciDeck (paid engagements, sponsored development, services around the product). This is the legal hinge, and only the foundation can answer it.
Whether the Commission's art. 26 guidance has appeared, the identity of the Dutch CSIRT coordinator, and the operational status of the art. 16 platform — all to be verified against current sources before 11 September 2026.
The steward-scope question ("intended for commercial activities" for an end-user tool with a professional audience) is unsettled law. A position can be taken and recorded; certainty cannot honestly be claimed either way, and a real lawyer should look at it if the foundation's factual answers put it near the line.

Provisions verified against CELEX 32024R2847 on 2026-07-22: art. 2(1); art. 3, points 13, 14, 21, 22; art. 14(1)-(7); art. 16; art. 24; art. 26(2)(a); art. 64(10)(b); art. 71(2); recitals 18, 19, 20.

**Analysis — no conclusion; the decision is deliberately left to the maintainer.** All provisions cited below were checked against the authentic text of Regulation (EU) 2024/2847 (CELEX 32024R2847, OJ L of 20.11.2024), retrieved on 2026-07-22. No article or recital number in this comment is from memory. Dutch implementation details (which body is the designated CSIRT coordinator, whether the ENISA single reporting platform is operational) were *not* verified and are marked as open below. This is an analysis by a maintainer's tooling, not legal advice. ### 1. The legal structure of the question Article 14 addresses "a manufacturer". Whether the duty attaches therefore runs through two separate doors: **Door 1 — manufacturer.** The Regulation applies to products with digital elements *made available on the market* (art. 2(1)). "Making available on the market" means supply for distribution or use on the Union market **in the course of a commercial activity**, *whether in return for payment or free of charge* (art. 3, point 22). Free-of-charge supply is thus not the exemption; absence of commercial activity is. Recital 18 is explicit on what that means for FOSS: - provision of FOSS **not monetised by its manufacturers** is not a commercial activity; - financial support from third parties, or contributions by manufacturers, does not in itself make it commercial; - the mere presence of **regular releases** does not in itself make it commercial; - development by a **not-for-profit organisation** is not commercial *provided the organisation is set up so that all earnings after costs are used to achieve not-for-profit objectives*. Recital 20 adds that merely hosting software on open repositories or collaboration platforms is not making available on the market. **Door 2 — open-source software steward.** A "steward" is a legal person, *other than a manufacturer*, that systematically provides sustained support for the development of specific FOSS products **intended for commercial activities**, and ensures their viability (art. 3, point 14; recital 19 names foundations explicitly). This regime exists precisely for FOSS that is *published but not made available on the market* (recital 19). Crucially, art. 24(3): > "The obligations laid down in Article 14(1) shall apply to open-source software stewards to the extent that they are involved in the development of the products with digital elements." So a foundation that escapes the manufacturer definition can still carry the actively-exploited-vulnerability notification duty through the steward regime — and the second sentence of art. 24(3) additionally applies the severe-incident duty (art. 14(3)) where such incidents affect **network and information systems provided by the steward for the development** of the product, i.e. the project's own forge. Two softeners are in the text: stewards are exempt from **all administrative fines** (art. 64(10)(b) — "any infringement of this Regulation by open-source software stewards"), and market surveillance authorities retain only cooperation/corrective instruments (art. 24(1)-(2)). Article 14 applies from **11 September 2026** (art. 71(2)); notifications go via the single reporting platform (art. 16) to the CSIRT designated as coordinator of the Member State of main establishment, simultaneously accessible to ENISA (art. 14(7)). ### 2. Facts from this repository that bear on the question - Publisher is **Stichting LibreKAT**, a Dutch foundation; licence is **EUPL-1.2** (`LICENSE.md`). - **No releases exist**: no release tag, no binaries distributed, no update mechanism, no version display; users build from source from the default branch (`SECURITY.md`). - **No monetisation is visible anywhere in the repository**: "No support contract, no paid tier, no second line" (`docs/TROUBLESHOOTING_GUIDE.md`); no donation or sponsorship links; `CODE_OF_CONDUCT.md` states the project acts on public values, not commercial interests. - Distribution is source-only via the project's own Forgejo forge — squarely the recital 20 situation. - A security **contact point already exists** (`security@librekat.nl`, `SECURITY.md`), with a documented triage model and internal, deliberately unpublished response norms measured by `tool/check_service_norms.dart` — which states in its header that it does **not** measure CRA conformity. - The product includes the **MIAUW penetration-test reporting module**, aimed at professional pentest practice — relevant to the steward hinge "intended for commercial activities" (see §3). - The publisher operates one ancillary service (`cveapi.librekat.nl`, a free CVE mirror) and the development forge itself — relevant to art. 24(3), second sentence, *if* steward status is assumed. - Tension worth naming: `README.md:90` describes the SBOM as shipped "**as required by** the EU Cyber Resilience Act" (similar framing in `docs/SECURITY_DESIGN.md:75`, and `cra:regulation` properties emitted by `tool/sbom_build.dart`). Self-description does not determine legal scope — the facts do — but this wording reads as self-identification with a manufacturer obligation and will be quoted back in any questionnaire. Tracked separately. ### 3. The arguments, both ways **That art. 14 does not attach (manufacturer door stays shut).** On the repository's facts, every recital-18 indicator points the same way: no monetisation, no paid tier, source-only distribution on the project's own forge, a foundation publisher. If the foundation's statutes contain the earnings-after-costs clause, the not-for-profit limb of recital 18 applies on top. On those facts OciDeck is not "made available on the market", LibreKAT is not a "manufacturer" within art. 3(13) read with art. 3(22), and art. 14 — addressed to manufacturers — does not attach. Even a future tagged release with binaries would not, by itself, change this (recital 18: regular releases alone are not commercial activity). **That a reporting duty may attach anyway (steward door).** Stichting LibreKAT matches the structural elements of art. 3(14) uncomfortably well: a legal person, not a manufacturer, providing systematic and sustained support (it hosts the forge, governs and steers development — the exact activities recital 19 lists), and ensuring the product's viability. The open element is "**intended for commercial activities**". Recital 19 glosses that as integration into commercial services or into monetised products — an integration-flavoured reading under which an end-user application would fall outside. But OciDeck's pentest module is explicitly built for professional — that is, commercial — engagements, and whether *end-use* in commercial activities satisfies the phrase is genuinely unsettled. Commission guidance on the Regulation's scope "with a particular focus on … free and open-source software" is mandated (art. 26(2)(a)) but, as far as could be established here, not yet available. If steward status is assumed, art. 24(3) makes art. 14(1) apply "to the extent that they are involved in the development" — and this foundation *is* the developer, so the duty would bite in practice, with the 24h/72h/14d cadence of art. 14(2), plus the severe-incident duty for the forge infrastructure. The counterweights: no administrative fines can be imposed on stewards for any infringement (art. 64(10)(b)), and the steward regime's remaining obligations (art. 24(1): a documented cybersecurity policy fostering secure development and vulnerability handling) describe things this project largely already does in behaviour. ### 4. If the duty applies (or is voluntarily followed): what would actually be needed The trigger is narrow — becoming aware of an **actively exploited** vulnerability in OciDeck (art. 14(1)) — a different event, clock and recipient than anything the existing service norms measure. 1. **Who reports:** the existing single-correspondent model in `SECURITY.md` already answers this. 2. **Where:** the single reporting platform (art. 16), via the CSIRT designated as coordinator of the Member State of main establishment — for a Dutch foundation, the Netherlands. *Not verified here:* which Dutch body holds that designation, and whether the ENISA platform is operational before 11-09-2026. 3. **The trail:** the tracker already carries a "Binnengekomen:" convention read by `tool/check_service_norms.dart`; an "actively exploited" marker on a tracking issue would date the awareness moment, which is what the 24-hour clock hangs on. That is *recording*, not measuring. 4. **Measured or only recorded:** with zero incidents to date there is nothing to measure; a short written procedure (trigger, who, where, the three deadlines) is the whole deliverable. ### 5. If the duty does not apply: where the conclusion should land Not in `docs/` (bundled as an asset with a forced reader tile — a public promise) and not in `SECURITY.md`, per the reasoning in the header of `tool/check_service_norms.dart`. The natural home is **`assurance/`**, which exists for exactly this kind of dated, non-promissory internal reasoning — e.g. `assurance/CRA-2024-2847-positie.md`, containing the facts relied on, the two doors above, the date, and explicit **re-evaluation triggers**: any monetisation connected to OciDeck; distribution of binaries through a channel that is not the project's own repository; a hosted instance offered to others; publication of the art. 26 Commission guidance on FOSS scope; and any change to the foundation's statutes. A one-line pointer from the `check_service_norms.dart` header would connect the tool's disclaimer to the recorded position. ### 6. What cannot be established from the repository - The **statutes** of Stichting LibreKAT (the recital-18 earnings-after-costs clause). - Any **off-repository monetisation** connected to OciDeck (paid engagements, sponsored development, services around the product). This is the legal hinge, and only the foundation can answer it. - Whether the Commission's art. 26 guidance has appeared, the identity of the Dutch CSIRT coordinator, and the operational status of the art. 16 platform — all to be verified against current sources before 11 September 2026. - The steward-scope question ("intended for commercial activities" for an end-user tool with a professional audience) is **unsettled law**. A position can be taken and recorded; certainty cannot honestly be claimed either way, and a real lawyer should look at it if the foundation's factual answers put it near the line. --- *Provisions verified against CELEX 32024R2847 on 2026-07-22: art. 2(1); art. 3, points 13, 14, 21, 22; art. 14(1)-(7); art. 16; art. 24; art. 26(2)(a); art. 64(10)(b); art. 71(2); recitals 18, 19, 20.*

brenno referenced this issue

2026-07-22 10:54:57 +00:00

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

brenno referenced this issue from a pull request that will close it,

2026-07-22 11:20:44 +00:00

docs: CRA is hier geen verplichting maar een leidraad — en de tekst zegt dat nu #536

brenno referenced this issue from a commit

2026-07-22 11:20:45 +00:00

docs(cra): leg de positie vast — geen verplichting, wel leidraad

brenno closed this issue

2026-07-22 11:20:46 +00:00

brenno referenced this issue