[Feature] Settle the steward question: is Stichting LibreKAT an open-source steward under Article 24? #550

New issue

Closed

opened 2026-07-22 13:43:17 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 13:43:17 +00:00

Owner

assurance/CRA-2024-2847-positie.md decides one thing well: the foundation is not a manufacturer, because OciDeck is not made available on the market. It is silent on the other role the regulation defines, and that silence is now load-bearing.

Why it surfaced. The ORC WG framework in orcwg/cra-attestations hangs almost entirely on the steward. proposals/gen-two-tier-approach.md recommends that stewards issue attestations for projects they give "sustained and ongoing support"; it treats non-stewarded projects as the hard case needing new intermediaries. Filling in AU.01 of a light-weight attestation (#549) means stating what the issuing entity is, and "a foundation, but not a steward" is a claim, not a blank.

Why the answer is not obviously no. Article 3(14) describes a legal person, other than a natural person, that provides sustained support for the development of specific open source products intended for commercial activity, and has as its purpose to ensure the viability of those products. Stichting LibreKAT is a legal person, publishes OciDeck, funds no one and sells nothing — but the tool is aimed at penetration testers, whose work is commercial. "Not for sale" is not the same as "not intended for commercial activity". The manufacturer analysis turned on placing on the market; the steward definition does not use that hinge, so the manufacturer conclusion does not carry over.

What follows either way. Article 24 obligations for a steward are a cybersecurity policy, vulnerability handling, cooperation with market surveillance authorities, and reporting actively exploited vulnerabilities to ENISA/CSIRT. Most of that we already do — SECURITY.md, the disclosure terms measured by tool/check_service_norms.dart, the public tracker. The one thing that does not exist is a route for the ENISA/CSIRT notification, and that is a real hole if the answer turns out to be yes.

Deliverable. A section in assurance/CRA-2024-2847-positie.md that decides the steward question the way the manufacturer question was decided: the finding, the reasoning, and what changes if it flips. Plus the sixth entry in the list of moments when this decision goes back on the table. Same register as the rest of the file — a working document, no conformity claim, no audit.

Order. This one lands before #549, because it determines what AU.01 may say.

[`assurance/CRA-2024-2847-positie.md`](assurance/CRA-2024-2847-positie.md) decides one thing well: the foundation is **not a manufacturer**, because OciDeck is not made available on the market. It is silent on the other role the regulation defines, and that silence is now load-bearing. **Why it surfaced.** The ORC WG framework in [orcwg/cra-attestations](https://github.com/orcwg/cra-attestations) hangs almost entirely on the steward. `proposals/gen-two-tier-approach.md` recommends that stewards issue attestations for projects they give "sustained and ongoing support"; it treats non-stewarded projects as the hard case needing new intermediaries. Filling in AU.01 of a light-weight attestation (#549) means stating what the issuing entity *is*, and "a foundation, but not a steward" is a claim, not a blank. **Why the answer is not obviously no.** Article 3(14) describes a legal person, other than a natural person, that provides sustained support for the development of specific open source products intended for commercial activity, and has as its purpose to ensure the viability of those products. Stichting LibreKAT is a legal person, publishes OciDeck, funds no one and sells nothing — but the tool is aimed at penetration testers, whose work is commercial. "Not for sale" is not the same as "not intended for commercial activity". The manufacturer analysis turned on *placing on the market*; the steward definition does not use that hinge, so the manufacturer conclusion does not carry over. **What follows either way.** Article 24 obligations for a steward are a cybersecurity policy, vulnerability handling, cooperation with market surveillance authorities, and reporting actively exploited vulnerabilities to ENISA/CSIRT. Most of that we already do — `SECURITY.md`, the disclosure terms measured by `tool/check_service_norms.dart`, the public tracker. The one thing that does *not* exist is a route for the ENISA/CSIRT notification, and that is a real hole if the answer turns out to be yes. **Deliverable.** A section in `assurance/CRA-2024-2847-positie.md` that decides the steward question the way the manufacturer question was decided: the finding, the reasoning, and what changes if it flips. Plus the sixth entry in the list of moments when this decision goes back on the table. Same register as the rest of the file — a working document, no conformity claim, no audit. **Order.** This one lands before #549, because it determines what AU.01 may say.

brenno added the

triage

enhancement

docs

labels

2026-07-22 13:43:17 +00:00

brenno referenced this issue

2026-07-22 13:45:03 +00:00

[Feature] Map Annex I Part I as well, including a documented risk assessment #556

brenno referenced this issue from a commit

2026-07-22 15:40:44 +00:00

docs(cra): beslis de rentmeestervraag, en zeg erbij hoe zeker dat is