Artikel 15

Stewards sind juristische Personen, die FOSS mit kommerzieller Zweckbestimmung nachhaltig unterstützen, ohne es in Verkehr zu bringen (Art. 3 Nr. 14, Art. 24). Die Leitlinien staffeln die Melde-Pflichten nach Art der Unterstützung: rein nicht-technischer Support, Infrastruktur-Hosting oder aktive Engineering-Beiträge.

Kernaussagen

• Die Rolle gilt pro FOSS-Projekt: Dieselbe Organisation kann für Produkt A Steward und für Produkt B Hersteller sein (z. B. Community- vs. Bezahlversion).
• Nur nicht-technischer Support (Branding, Governance, Events, Donations): keine Meldepflicht für aktiv ausgenutzte Schwachstellen — Informationen aber an die Maintainer weitergeben; freiwillige Meldung nach Art. 15 erwägen.
• Infrastruktur-Steward (Repos, Versionskontrolle, Signing Keys): schwerwiegende Vorfälle mit Auswirkung auf die Produktsicherheit an ENISA/CSIRT melden (Art. 14 Abs. 3), Nutzer ggf. informieren.
• Engineering-Steward (Entwickler, Releases, Vulnerability-Handling): aktiv ausgenutzte Schwachstellen melden (Art. 14 Abs. 1) und Nutzer informieren (Art. 14 Abs. 8).
• Not-for-Profit-Entitäten, deren Erträge satzungsgemäß gemeinnützigen Zwecken dienen, bringen ihre FOSS auch bei Monetarisierung nicht in Verkehr — es gelten Steward-Pflichten (Beispiel 24: Browser mit Suchmaschinen-Partnerschaft).

Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026 für alle Produkte im CRA-Scope — auch für vor dem 11. Dezember 2027 in Verkehr gebrachte und für Produkte nach Supportende. „Bewusstwerden“ heißt: hinreichende Gewissheit nach unverzüglicher Erstbewertung — ab dann laufen die Fristen (24 h Frühwarnung, 72 h Meldung, 14 Tage bzw. 1 Monat Abschlussbericht).

Kernaussagen

• Keine retroaktive Meldung: Aktive Ausnutzung, die dem Hersteller schon vor dem 11.09.2026 bekannt war, ist nicht meldepflichtig; wird die Ausnutzung erst danach bekannt, greift die Pflicht.
• Dritt-Komponenten: Meldepflichtig ist nur eine aktiv ausgenutzte Schwachstelle, die im eigenen Produkt ausnutzbar ist bzw. ausgenutzt wurde — sonst nur freiwillige Meldung (Art. 15) plus Upstream-Meldung an den Komponenten-Maintainer (Art. 13 Abs. 6).
• Der Begriff „Bewusstwerden“ ist bewusst konsistent mit der NIS-2-Durchführungsverordnung und den GDPR-Guidelines ausgelegt.
• Nutzerinformation (Art. 14 Abs. 8) ist risikobasiert: keine indiskriminierte Veröffentlichung — bei sensiblen Umgebungen darf die Detailinformation auf betroffene Nutzer beschränkt werden; breitere Offenlegung nach Behebung, Pflicht-Veröffentlichung fixer Schwachstellen nach Anhang I Teil II Nr. 4.
• Die Meldepflichten laufen — anders als die Schwachstellenbehandlung — auch nach Ende des Supportzeitraums weiter.

Die Leitlinien präzisieren drei Pflichten: das Upstream-Melden von Komponenten-Schwachstellen und Teilen von Security-Fixes (Art. 13 Abs. 6), das Verbot, Produkte mit bekannten ausnutzbaren Schwachstellen in Verkehr zu bringen (Anhang I Teil I), und die „effektiven und regelmäßigen Tests“ (Anhang I Teil II Nr. 3) — die keine mechanische Testwiederholung verlangen, sondern anlassbezogene Review und Anpassung.

Kernaussagen

• Upstream nur für die tatsächlich integrierte Version und gemäß CVD-Prozessen des Maintainers; keine Pflicht bei bereits bekannter Schwachstelle (Duplikate vermeiden: Datenbanken/Advisories prüfen) oder bei verwaisten Projekten ohne Maintainer.
• Nur Schwachstellen der Komponente selbst sind zu melden — nicht solche, die erst durch die eigene Integration entstehen.
• Security-Fixes maschinenlesbar und lizenzkompatibel teilen; weder muss der Maintainer den Fix annehmen, noch der Hersteller den Fix des Maintainers übernehmen.
• „Bekannt“ ist eine Schwachstelle bei Listung in relevanten öffentlichen Datenbanken (z. B. Europäische Schwachstellendatenbank), bei Coordinated Disclosure, eigenen Tests (inkl. KI-gestützter Analyse) oder prominenter Medienberichterstattung — eine kurze Prüf-/Verifikationszeit ist zulässig.
• Kurz vor Release entdeckte Schwachstellen: risikobasierte Entscheidung, ob das Release verschoben wird — abwägen mit den Risiken der Verzögerung (z. B. wenn das Release andere Schwachstellen schließt).

Jede Person mit Kenntnis einer Schwachstelle oder eines Vorfalls — Sicherheitsforscher, Bug-Bounty-Teilnehmer, Importeure, Endkunden. Die Meldung erfolgt an die zuständige CSIRT oder direkt an die ENISA.

Nein, sofern die Meldung in gutem Glauben erfolgt. Artikel 15 schützt freiwillige Melder ausdrücklich vor zivil- und strafrechtlichen Folgen, soweit nationales Recht das zulässt.

Artikel 15 schafft den rechtlichen Rahmen, der Bug-Bounty-Meldungen an Behörden absichert. Bug-Bounties an Hersteller bleiben davon unberührt; die freiwillige Behörden-Meldung ist ein zusätzlicher Kanal.