Der größte Teil eines Softwareprodukts mit digitalen Elementen ist Code, den sein Hersteller nicht geschrieben hat: Bibliotheken, Frameworks, ein Betriebssystem, eine Datenbank, ein Cloud-Dienst. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, macht den Hersteller nicht für die eigene Konformität dieser Komponenten verantwortlich. Er macht ihn für das Produkt als Ganzes verantwortlich und knüpft drei Pflichten an die Komponenten darin. Artikel 13(5): Sorgfaltspflicht bei der Integration. Artikel 13(6): Schwachstellen, die Sie darin finden, an den Betreuer melden und die Korrekturen, die Sie schreiben, weitergeben. Anhang I Teil I Nummer 2(a), gelesen mit Artikel 13(1): das Produkt ohne bekannte ausnutzbare Schwachstellen in Verkehr bringen. Die Verordnung sagt jede in einem Satz. Die Leitlinien der Kommission vom 27. Juli 2026, C(2026) 5252, Abschnitte 3.4, 7.3 und 9.2, sagen, was jede verlangt, und dieser Artikel ist diese Abschnitte, mit den FAQ der Kommission zur Umsetzung, Version 1.4, Abschnitt 5.4, wo sie etwas hinzufügen.

Wer für eine Komponente verantwortlich ist: nur, wer sie in Verkehr bringt

Randnummer 87 der Leitlinien klärt die Frage, die Betreuer und Integratoren beide stellen: „Ob der CRA auf eine bestimmte FOSS-Komponente anwendbar ist, hängt allein davon ab, ob die natürliche oder juristische Person, die sie veröffentlicht, sie in Verkehr bringt.“ Die Integration einer Komponente in ein monetarisiertes Produkt „hat keine Auswirkung auf den Status dieser FOSS-Komponente“, und Randnummer 86 ergänzt, dass Hersteller „nicht für die eigene Konformität solcher Komponenten mit dem CRA verantwortlich werden, selbst wenn die Hersteller Quellcode zu deren Pflege beitragen“. Wann ein Projekt in Verkehr gebracht wird, ist eine Frage für seinen Herausgeber. Was der Integrator schuldet, steht in Randnummer 88: Konformität „für ihre eigenen Produkte mit digitalen Elementen“, Sorgfaltspflicht nach Artikel 13(5) „gegenüber den FOSS-Komponenten, die sie integrieren“, und die Meldungen und Korrekturen des Artikels 13(6).

Sorgfaltspflicht, Artikel 13(5): festlegen, was Sie von der Komponente brauchen, dann prüfen

Abschnitt 7.3 zieht die Linie zwischen Risikobewertung und Sorgfaltspflicht. Die Risikobewertung nach Artikel 13(2) deckt das Produkt und die Risiken ab, die es von außen erreichen, „etwa externe Netze, Umgebungsfaktoren oder andere externe Aspekte“, und für diese „verlangt der CRA von den Herstellern nicht, die externe Umgebung zu kontrollieren oder zu steuern“, sondern nur, „solche Risiken zu ermitteln und durch die Konzeption und Entwicklung des Produkts zu mindern“ (Randnummer 168). Das Beispiel in Randnummer 169 ist ein Backend, das nicht Teil des Produkts ist, aber genutzt werden könnte, um ihm böswillige Befehle zu senden: Die Antwort liegt auf Produktebene, „kryptografische Authentifizierung von Fernbefehlen, Prüfung der Integrität von Konfigurationsänderungen oder Erzeugung sicherheitsrelevanter Protokolle“, und die Verordnung „erlegt keine Pflichten dazu auf, wie die Backend-Infrastruktur organisiert, besetzt oder betrieben wird“.

Die Sorgfaltspflicht ist die andere Pflicht, und sie „bezieht sich auf Elemente, die Teil des Produkts mit digitalen Elementen selbst sind, insbesondere integrierte Software- oder Hardwarekomponenten eines Dritten“ (Randnummer 170). Ihr Inhalt steht in einem Satz derselben Randnummer: Sie „kann nur erreicht werden, indem festgelegt wird, was das Produkt mit digitalen Elementen von seinen Komponenten benötigt, um seine Cybersicherheitsziele zu erreichen, und risikobasiert geprüft wird, ob diese Komponenten den Bedürfnissen des Produkts entsprechen“. Randnummer 171 macht es konkret: Wenn das Produkt „auf kryptografische Funktionen, Aktualisierungsmechanismen oder sichere Kommunikation angewiesen ist, die eine Komponente bereitstellt, muss der Hersteller im Rahmen seiner Sorgfaltspflicht diese Bedürfnisse ermitteln und prüfen, ob die Komponente sie erfüllt“. Der Nachweis „kann aus Dokumentation des Komponentenherstellers bestehen, etwa technischen Spezifikationen, Sicherheitsdokumentation oder einschlägiger Konformitäts- oder Zusicherungsdokumentation“, und „gegebenenfalls kann der Hersteller auch Tests durchführen“.

Zwei Folgen für eine Abhängigkeitsliste. Erstens ist Sorgfaltspflicht verhältnismäßig und spezifisch: Sie fragt, was jede Komponente für die Sicherheit des Produkts leistet, und prüft das, nicht alles über jedes Paket. Eine Logging-Bibliothek und eine TLS-Bibliothek bekommen nicht dieselbe Akte. Zweitens findet die Prüfung „bei der Integration“ statt (Randnummer 172), und die Komponenten werden „als extern gelieferte Komponenten behandelt, deren Eigenschaften durch Sorgfaltspflicht geprüft werden“, nicht neu entworfen. Randnummer 173: „Wo der Hersteller Funktionen selbst entwickelt, muss er die grundlegenden Anforderungen unmittelbar umsetzen. Wo der Hersteller von anderen entwickelte Komponenten integriert, muss er durch Sorgfaltspflicht sicherstellen, dass diese Komponenten so verwendet werden können, dass das Produkt mit digitalen Elementen als Ganzes konform ist.“

Meldung nach oben und Weitergabe von Korrekturen, Artikel 13(6): vier Grenzen, die die Leitlinien setzen

Artikel 13(6) verlangt von einem Hersteller, der eine Schwachstelle in einer integrierten Komponente erkennt, sie „der Person oder Stelle zu melden, die die Komponente herstellt oder pflegt“, und jede Korrektur, die er entwickelt, weiterzugeben. Abschnitt 9.2.1 grenzt die Pflicht auf vier Arten ein.

Nur die Version, die Sie integrieren, über den Kanal des Betreuers, und nicht doppelt. Randnummer 223: Hersteller „sind nur in Bezug auf die Version der Komponente, die sie integrieren, zur Meldung nach oben verpflichtet“; wo der Betreuer „Sicherheitsrichtlinien, Verfahren zur koordinierten Offenlegung oder bestimmte Meldekanäle“ hat, geht die Meldung darüber; und „Hersteller sind nicht zur Meldung nach oben verpflichtet, wenn sie bestätigen können, dass die Person oder Stelle, die eine Komponente herstellt oder pflegt, von der Existenz einer Schwachstelle weiß“. Die Leitlinien bitten Hersteller, „öffentlich zugängliche Schwachstellendatenbanken, projektspezifische Sicherheitshinweise oder etablierte Issue-Tracker vor der Meldung nach oben zu prüfen“, um Betreuern Duplikate zu ersparen.

Nur Schwachstellen in der Komponente, nicht in Ihrer Integration davon. Randnummer 224: Die Pflicht umfasst „diejenigen Schwachstellen, die in der integrierten Komponente selbst bestehen, und nicht Schwachstellen, die sich aus der Integration zwischen der Komponente und anderem vom Hersteller entwickelten Code ergeben“. Wo die Integration ein Verhalten der Komponente offenlegt, das isoliert nicht erkennbar war, wird empfohlen, den Betreuer zu informieren, nicht verlangt.

Nicht, wo es keinen Betreuer gibt. Randnummer 225: Keine Meldung nach oben ist geschuldet, „wo die Komponente keinen Betreuer mehr hat oder wo der Hersteller für neue Versionen oder Sicherheitskorrekturen nicht mehr auf den ursprünglichen Betreuer angewiesen ist“; stattdessen wird empfohlen, die Nutzer der Komponente über „bestehende Community-Mechanismen (wie Mailinglisten oder Issue-Tickets) oder öffentliche Schwachstellenverzeichnisse“ zu informieren.

Die Korrektur weitergeben; nicht dafür sorgen müssen, dass sie übernommen wird. Randnummern 226 bis 229: Eine Korrektur, die Sie für eine Komponentenschwachstelle entwickeln, muss nach oben weitergegeben werden, „gegebenenfalls in maschinenlesbarem Format“ und bei einer Open-Source-Komponente „auf eine mit der Lizenz dieser Komponente vereinbare Weise“. Aber Hersteller „sind nach dem CRA nicht verpflichtet, sicherzustellen, dass ihre Sicherheitskorrekturen zwingend angenommen“ oder „in das Code-Repository der Komponente integriert werden“, sind nicht verpflichtet, im Gegenzug die Korrektur des Betreuers anzunehmen, und wo sie die Schwachstelle durch eine Änderung an anderer Stelle ihres eigenen Systems mindern, „verlangt der CRA vom Hersteller nicht, die Änderung eines anderen Teils des Systems nach oben weiterzugeben“.

Wann die Schwachstelle einer Komponente von Ihnen an die Behörden zu melden ist

Die Pflichtmeldung nach Artikel 14 ist eine andere Pflicht als die Meldung nach oben, und die beiden werden leicht verwechselt. Randnummer 218 der Leitlinien und FAQ 5.4 ziehen die Linie: Ein Hersteller meldet eine aktiv ausgenutzte Schwachstelle, „die in seinem Produkt enthalten ist“; wo die Schwachstelle einer Komponente eines Dritten „in seinem Produkt mit digitalen Elementen nicht ausgenutzt werden kann (z. B. weil der anfällige Code nicht erreichbar ist)“ oder „in seinem Produkt nicht ausgenutzt wurde“, unterliegt sie „für diesen Hersteller nicht der Meldepflicht“. Die FAQ ergänzen, dass der Hersteller der Komponente sie ebenfalls meldet, „wenn diese Komponente in Verkehr gebracht wurde“, und dass der Integrator „diese Schwachstelle weiterhin freiwillig nach Artikel 15 melden kann“. Eine gelistete CVE in einer Abhängigkeit startet also zwei Dinge: die Erreichbarkeitsprüfung, die entscheidet, ob die 24-Stunden-Uhr begonnen hat, und, wenn Sie etwas gefunden haben, was der Betreuer nicht weiß, die Meldung nach Artikel 13(6).

Bekannte ausnutzbare Schwachstellen im Moment der Auslieferung

Die erste grundlegende Anforderung in Anhang I Teil I Nummer 2(a) ist, das Produkt „ohne bekannte ausnutzbare Schwachstellen“ bereitzustellen, und Abschnitt 9.2.2 beantwortet die zwei Wörter, die die Verordnung offenlässt. „Ausnutzbar“ ist Artikel 3(41): „eine Schwachstelle, die das Potenzial hat, von einem Angreifer unter praktischen Betriebsbedingungen wirksam genutzt zu werden“, was Randnummer 231 Schwachstellen gegenüberstellt, die „nur unter theoretischen Bedingungen (z. B. in einem Labor oder einer Simulation)“ ausnutzbar sind. „Bekannt“ sind die Randnummern 233 und 234, und es ist weit: Eine Schwachstelle „sollte als bekannt gelten, wenn sie in einschlägigen öffentlich zugänglichen Schwachstellendatenbanken gelistet ist, etwa der europäischen Schwachstellendatenbank“ oder „anderen bedeutenden Schwachstellendatenbanken“; wenn der Hersteller „durch nicht öffentliche Informationen darauf aufmerksam gemacht wurde, etwa durch koordinierte Offenlegung durch einen Sicherheitsforscher oder durch eigene interne Tests und Analysen, einschließlich beispielsweise bei der Nutzung KI-gestützter Dienste“; und „wenn sie in zuverlässigen Medien öffentlich und prominent berichtet wurde“.

Randnummer 235 hält es verhältnismäßig: Ein Bericht „bedeutet an sich nicht, dass sie in der Praxis ausnutzbar oder auf das konkrete Produkt anwendbar ist“, der Hersteller „muss sie untersuchen und den Wahrheitsgehalt dieser Informationen und die Anwendbarkeit bestätigen“, und „zwischen dem ersten Bericht über die Schwachstelle und ihrer Bestätigung kann eine begrenzte Zeit vergehen“. Die Randnummern 236 und 237 behandeln das Release, das einen Tag entfernt ist, wenn eine neue CVE in einer Abhängigkeit auftaucht: Die Pflicht „gilt im Moment des Inverkehrbringens“, sie ist „eine risikobasierte Pflicht“, und der Hersteller entscheidet auf Grundlage „der Schwere, Ausnutzbarkeit und möglichen Auswirkung der Schwachstelle“, ob das Produkt in Verkehr gebracht werden kann oder die Schwachstelle zuerst behoben werden muss, und „kann auch die Risiken einer Verschiebung der Produktfreigabe berücksichtigen“, etwa wo das Release andere ausnutzbare Schwachstellen behebt. Einmal auf dem Markt, gelten die Behandlungspflichten des Anhangs I Teil II ohnehin.

Varianten und Produktfamilien

Ein kurzer Abschnitt, der die meiste Arbeit spart. Abschnitt 7.4: Wo Produkte „dieselbe Architektur, dasselbe sicherheitsrelevante Design und dieselbe Zweckbestimmung teilen und denselben Cybersicherheitsrisiken ausgesetzt sind“, kann der Hersteller „sich auf (i) eine einzige Cybersicherheitsrisikobewertung“, „(ii) einen einzigen Satz technischer Dokumentation und (iii) ein einziges Konformitätsbewertungsverfahren stützen“ und „eine einzige EU-Konformitätserklärung“ ausstellen, die „die Produktvarianten, für die sie gilt, eindeutig benennt“ (Randnummer 175). Randnummer 176 gibt den Test: Unterschiede in „Farbe, Formfaktor, Speichergröße oder anderen nicht sicherheitsrelevanten Merkmalen“ spalten die Familie nicht; Unterschiede in „Kommunikationsschnittstellen, Software-Stacks, Aktualisierungsmechanismen oder Fernkonnektivität“ tun es und müssen sich in den Dokumenten widerspiegeln.

Was je Komponente festzuhalten ist

Die Aufzeichnung, die alle drei Pflichten erfüllt, passt in die SBOM, die Sie für Anhang I Teil II Nummer 1 ohnehin erzeugen, eine Zeile je Komponente:

  1. Name, integrierte Version und der Sicherheitskontakt oder Offenlegungskanal des Betreuers.
  2. Was das Produkt für seine Sicherheit von ihr braucht, im Sinne von Randnummer 171: nichts, oder Kryptografie, Updates, Authentifizierung, Transport und so weiter.
  3. Der Nachweis, den Sie für dieses Bedürfnis halten, und wann Sie ihn erhalten haben: die Dokumentation des Betreuers, ein Zusicherungsnachweis, Ihr eigener Test.
  4. Die Erreichbarkeit der bekannten Schwachstellen der Komponente in Ihrem Produkt und das Datum der letzten Prüfung gegen die Datenbanken, die Randnummer 233 nennt.
  5. Erfolgte Meldungen nach oben und weitergegebene Korrekturen, mit Datum, oder die Bestätigung, dass der Betreuer bereits Bescheid wusste.

Diese Tabelle ist die Sorgfaltspflichtakte, der Input für die Erreichbarkeitsprüfung, wenn eine CVE erscheint, und der Teil der technischen Dokumentation, den eine Behörde zuerst liest, wenn die Frage lautet „wussten Sie davon“.

Quellen

  • Verordnung (EU) 2024/2847, Artikel 3(41), Artikel 13(1), (2), (5) und (6), Artikel 14(1), Artikel 15, Anhang I Teil I Nummer 2(a) und Teil II Nummer 1, Erwägungsgrund 34.
  • Europäische Kommission, Leitlinien der Kommission zur Anwendung der Verordnung (EU) 2024/2847, C(2026) 5252 final vom 27. Juli 2026, Anhang, Abschnitt 3.4 (Randnummern 85 bis 88), Abschnitte 7.3 und 7.4 (Randnummern 167 bis 177), Abschnitt 9.1 Randnummer 218, Abschnitte 9.2.1 und 9.2.2 (Randnummern 222 bis 237).
  • Europäische Kommission, FAQ zum Cyber Resilience Act, Version 1.4 vom 4. September 2026, Abschnitt 5.4.

Dies ist keine Rechtsberatung. Die Abschnitte 7.3 und 9.2 umfassen zusammen sieben Seiten und beantworten die Abhängigkeitsfrage genauer als die Seite jedes Werkzeuganbieters; lesen Sie sie mit geöffnetem Lockfile.