Anhang I Teil II: Welche acht Anforderungen gelten für die Schwachstellenbehandlung?
Acht Pflichten ab 11. Dezember 2027; Nr. 5 und 6 braucht es wegen der Meldepflicht schon seit 11. September 2026.
- Nr. 1: Schwachstellen und Komponenten ermitteln und dokumentieren – einschließlich einer Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten erfasst
- Nr. 2: Schwachstellen unverzüglich beheben, auch durch Sicherheitsaktualisierungen
- Nr. 3: regelmäßige Tests und Überprüfungen der Produktsicherheit
- Nr. 4: Informationen zu behobenen Schwachstellen veröffentlichen
- Nr. 5: eine Strategie zur koordinierten Offenlegung von Schwachstellen
- Nr. 6: einen Kontaktweg für Schwachstellenmeldungen
- Nr. 7: sichere Mechanismen zur Verteilung von Updates
- Nr. 8: Sicherheitsupdates unverzüglich und unentgeltlich verbreiten
Diese Anforderungen gelten ab 11. Dezember 2027 für neue Produkte und für Bestandsprodukte nach einer wesentlichen Änderung. Praktisch braucht ein Hersteller Nr. 5 und Nr. 6 aber schon heute, weil er sonst die seit 11. September 2026 geltende Meldepflicht nicht erfüllen kann – die Frist ändert das nicht, die Reihenfolge der Arbeit schon.
Was muss in die Software-Stückliste (SBOM)?
Komponenten mit Namen, Versionen und Abhängigkeiten, mindestens die oberste Ebene, in einem maschinenlesbaren Format wie SPDX oder CycloneDX, zehn Jahre aufbewahrt.
| Frage | Antwort nach CRA und Leitlinien |
|---|---|
| Was muss hinein? | Komponenten mit Namen und Version, so präzise, dass sie gegen Schwachstellendatenbanken abgeglichen werden können; Herkunft (kommerziell/quelloffen); Abhängigkeitsbeziehungen. Die SBOM ist zu aktualisieren, wenn Schwachstellen behoben werden. |
| Welches Format? | Ein „gängiges maschinenlesbares Format“. SPDX (ISO/IEC 5962) und CycloneDX (ECMA-424) sind die etablierten Optionen; der CRA schreibt keines vor. BSI TR-03183 Teil 2 konkretisiert formale Anforderungen. |
| Wie tief? | Mindestens die obersten Abhängigkeiten. Transitive Abhängigkeiten sind empfehlenswert: Eine Schwachstelle in einer undokumentierten transitiven Komponente bleibt eine Schwachstelle des Produkts. |
| Wer bekommt sie? | Keine Veröffentlichungspflicht. Die Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern (Art. 13 Abs. 25); bei Klasse I und II prüft sie die notifizierte Stelle. |
| Wie lange aufbewahren? | Die technische Dokumentation einschließlich SBOM und die EU-Konformitätserklärung mindestens zehn Jahre nach dem Inverkehrbringen oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13). |
Welche Pflichten gelten für Komponenten Dritter?
Art. 13 Abs. 5 verlangt Sorgfalt bei der Integration von Komponenten Dritter, einschließlich quelloffener Software: Sie dürfen die Sicherheit des Produkts nicht beeinträchtigen. Art. 13 Abs. 6 wird regelmäßig übersehen, weil er kein Meldeweg zur Behörde ist, sondern einer zum Lieferanten: Stellt der Hersteller eine Schwachstelle in einer Komponente fest, meldet er sie der Person oder Stelle, die die Komponente pflegt – und behebt sie, soweit er kann, selbst.
1. Welche Gesellschaft, welches Produkt und welche Version umfasst Ihre Auskunft? 2. Wie begründen Sie Ihre CRA-Rolle und die betrachtete Produktgrenze? 3. In welchem Format und welchem Rhythmus erhalten wir die SBOM zum ausgelieferten Stand? 4. Wie informieren Sie uns über aktiv ausgenutzte Schwachstellen – schnell genug für unsere 24-Stunden-Frühwarnung? 5. Welche Supportzusagen und Vorankündigungen für Abkündigungen bestehen? 6. Wer liefert im Vorfall welche belastbaren Informationen über welchen Kontaktweg? Für DORA bleibt daneben die eigene Dienstleisterprüfung bestehen; ein Zertifikat ist eine Informationsquelle, kein Ersatz.
Open Source: Wann greift der CRA?
Bei Geschäftstätigkeit. Art. 24 und 25 CRA enthalten ein abgeschwächtes Regime für quelloffene Software. Adressat ist der Verwalter quelloffener Software: eine juristische Person, die die Entwicklung quelloffener Software unterstützt, die im Rahmen einer Geschäftstätigkeit bereitgestellt wird, ohne selbst Hersteller zu sein. Ihn treffen eine dokumentierte Cybersicherheitspolitik, Schwachstellenbehandlung und Kooperation mit Behörden; von Bußgeldern ist er nach Art. 64 Abs. 10 lit. b vollständig ausgenommen. Die Trennlinie verläuft nicht zwischen quelloffen und proprietär, sondern zwischen Geschäftstätigkeit und ihrer Abwesenheit: Das Teilen von Quellcode in einem öffentlichen Verzeichnis ist regelmäßig kein Inverkehrbringen; wer dieselbe Software im Rahmen einer Geschäftstätigkeit bereitstellt, ist Hersteller. Für ein Institut, das intern gepflegte Bibliotheken veröffentlicht, ist das die Stelle, an der es prüft, ob es selbst in die Rolle des Verwalters gerät.
Warum erspart ISO 27001 Arbeit, aber keine Pflicht?
Der Satz „Wir sind nach ISO/IEC 27001 zertifiziert, damit ist der CRA weitgehend abgedeckt“ vermengt zwei Ebenen: die Ebene, auf der ein Regelwerk Arbeit erspart, und die Ebene, auf der es eine Rechtsfolge auslöst. Eine Rechtsfolge – die Konformitätsvermutung nach Art. 27 – löst nur eine harmonisierte Norm aus, deren Fundstelle im Amtsblatt zitiert ist, oder ein durch delegierten Rechtsakt ausgewiesenes Zertifizierungsschema. Beides fehlt zum Stand dieser Seite. ISO/IEC 27001, IEC 62443, ISO/IEC 29147 und 30111 tragen keine Rechtsfolge, wohl aber Nachweiswert: Sie liefern die Prozesse und Belege, die Anhang VII Nr. 5 verlangt.
Wo keine harmonisierte Norm angewandt wird, sind in der technischen Dokumentation die anderen Lösungen zu beschreiben, mit denen jede Anforderung des Anhangs I erfüllt wird. Die Pflicht wandert damit von der Norm zum Einzelnachweis. Wer eine Norm anwenden könnte, verweist auf sie; wer keine anwenden kann, legt je Anforderung und je Produkt einzeln dar. Die Marktüberwachung fragt nach dem Nachweis für die Anforderung des Anhangs I, nicht nach dem Zertifikat für das Managementsystem (Art. 13 Abs. 22). Eine Produktakte, die Produktversion, Komponentenstand, Risikobewertung, Tests und Freigaben verknüpft, ist deshalb heute mehr wert als jede Normkonformitäts-Behauptung.
Wie wird die SBOM in der Praxis genutzt?
Eine Bank prüft eine Bibliothekswarnung anhand der SBOM; eine Versicherung fordert vom Lieferanten eine Komponentenliste mit Build-Bezug nach.
Eine Warnung nennt mehrere Bibliotheksversionen. Die SBOM zum ausgelieferten App-Stand zeigt, welche Version enthalten ist; die Anbieterauskunft belegt, ob eine Ausnutzung bekannt ist. Erst daraus folgt die Entscheidung: Behebung nach Anhang I Teil II Nr. 2, Rückmeldung an den Komponentenanbieter nach Art. 13 Abs. 6 – und nur bei aktiver Ausnutzung die Frühwarnung nach Art. 14.
Der Anbieter der Schaden-App liefert eine Komponentenliste ohne Build-Bezug. Sie erfüllt Anhang I Teil II Nr. 1 nicht, weil sie nicht zum ausgelieferten Stand passt. Ergebnis: Nachforderung mit Format, Identifikatoren und Aktualisierungsrhythmus – als Vertragspflicht, nicht als Bitte.
Häufige Fragen
Ist SPDX oder CycloneDX gesetzlich vorgeschrieben?
Nein. Der CRA verlangt ein gängiges maschinenlesbares Format; SPDX und CycloneDX erfüllen das. Die Kommission kann Formate durch delegierten Rechtsakt vorgeben; bisher ist das nicht geschehen.
Muss die SBOM veröffentlicht werden?
Nein. Sie ist Teil der technischen Dokumentation und auf begründetes Verlangen der Marktüberwachungsbehörde herauszugeben. Vertragliche Weitergabe an Kunden ist davon zu unterscheiden.
Reicht ein ISO-27001- oder IEC-62443-Zertifikat als CRA-Nachweis?
Es erspart Arbeit, löst aber keine Konformitätsvermutung aus. Die Vermutung setzt eine im Amtsblatt zitierte harmonisierte Norm oder ein ausgewiesenes europäisches Zertifizierungsschema voraus – beides gibt es zum Stand dieser Seite nicht.
Ist eine SBOM dasselbe wie das KI-Inventar?
Nein. Die SBOM beschreibt die Komponenten eines Produkts, das KI-Inventar die eingesetzten KI-Systeme des Instituts. Beide sollten verknüpft, aber nicht vermischt werden.
Ing. Mag. Patrick Eiler
Patrick Eiler berät Banken und Versicherungen in Wien zu aufsichtlichem Meldewesen, Datenarchitektur und KI-Compliance. Über zwanzig Jahre in Banken, Versicherungen und Finanzdienstleistung; Vortragender beim Hypo-Verband (Fachsitzung 23. September 2026).