Drittkomponenten nach CRA: Sorgfaltspflicht für Fremd- und Open-Source-Bausteine (Art. 13 Abs. 5)

4 Min Lesezeit Serie: compliance #compliance#cra#due-diligence#drittkomponenten#open-source#art13#sbom

Der Cyber Resilience Act verpflichtet Hersteller, beim Einbinden von Komponenten Dritter - ausdrücklich auch Open-Source - Sorgfalt walten zu lassen, damit diese die Sicherheit des Produkts nicht gefährden (Art. 13 Abs. 5). Der Maßstab ist risikoabhängig (Erwägungsgrund 34), und bei einer Schwachstelle in einer Komponente kommt die Upstream-Meldepflicht hinzu (Art. 13 Abs. 6). Dernium CRA-Nachweis führt die Sorgfaltsbewertung je Komponente direkt auf der Stückliste - org-weit, stabil über Re-Ingests. Dieser Beitrag zeigt die Bausteine und wo bewusst die Verantwortung beim Hersteller bleibt.

Problem

Moderne Software besteht zum größten Teil aus fremdem Code: Bibliotheken, Pakete, Open-Source-Bausteine. Der CRA nimmt das ernst und verlangt in Artikel 13 Absatz 5, dass Hersteller beim Einbinden von Komponenten Dritter - ausdrücklich einschließlich freier und quelloffener Software - Sorgfalt walten lassen, damit diese die Cybersicherheit des Produkts nicht gefährden. Eine Stückliste allein erfüllt das nicht: sie zählt die Bausteine auf, sagt aber nichts darüber, ob jeder davon geprüft wurde. Und bei einer Schwachstelle in einer fremden Komponente verlangt Absatz 6 zusätzlich, sie an den Upstream zu melden und den eigenen Fix zu teilen. Wer das nicht dokumentiert, hat die Pflicht vielleicht erfüllt, kann es aber nicht belegen.

Kurze Antwort

Dernium CRA-Nachweis setzt die Sorgfaltsbewertung direkt auf die Stückliste. Aus den eingelesenen SBOMs entsteht je Produkt die Liste der Drittkomponenten; zu jeder hinterlegen Sie eine Bewertung: ein Risiko, einen Status (offen, akzeptiert, beobachten, ersetzen) und - risikoabhängig - die in Erwägungsgrund 34 genannten Prüfungen: Konformität/CE des Anbieters, Wartung und Update-Historie, Abgleich mit Schwachstellen-Datenbanken, zusätzliche Tests. Dazu der Meldekontakt zum Upstream für den Fall des Absatzes 6 sowie Herkunft und Lizenz. Die Bewertung gilt org-weit je Komponente (eine Komponente wird einmal geprüft, nicht in jedem Produkt erneut) und überlebt das erneute Einlesen von Stücklisten. Dernium gibt keine Bewertung ab; Inhalt und Verantwortung bleiben beim Hersteller.

Tiefgang

Risiko-proportional, kein Pflicht-Vierkampf. Erwägungsgrund 34 sagt ausdrücklich „eines oder mehrere" der Prüfungen, abhängig von Art und Höhe des Risikos der Komponente. Eine reife, breit gepflegte Bibliothek braucht weniger Aufwand als ein obskures Einzelstück. Deshalb sind die vier Prüffelder Angebote, kein erzwungenes Vollformular - der Lotse verlangt nicht, alle vier auszufüllen, sondern lässt Sie das dem Risiko angemessen tun.

An den purl gekoppelt, nicht ans Produkt. Eine Komponenten-Prüfung ist eine Lieferanten-Entscheidung: derselbe Baustein steckt oft in mehreren Produkten und Versionen. Die Bewertung wird daher org-weit am Paket-Identifier (purl) geführt - genau wie unsere VEX-Aussagen. Das hat zwei Effekte: Sie prüfen einmal statt mehrfach, und die Bewertung überlebt das erneute Einlesen einer Stückliste (bei dem die internen Komponenten-Datensätze neu entstehen).

Absatz 6 ist mitgedacht. Finden Sie eine Schwachstelle in einer Komponente, verlangt der CRA, sie an die Person oder Stelle zu melden, die die Komponente pflegt, und einen entwickelten Fix mit ihr zu teilen. Damit das im Ernstfall schnell geht, hält die Bewertung den Meldekontakt des Upstreams fest.

Open-Source entlastet Sie nicht. Quelloffene Bausteine fallen ausdrücklich unter die Sorgfaltspflicht. Dass ein Projekt von einem „Open-Source-Verwalter" (Steward, Art. 24) mit eigenem, leichterem Pflichtenregime gepflegt wird, verschiebt die Verantwortung nicht: wer die Komponente in ein kommerzielles Produkt einbaut, trägt die Sorgfaltspflicht aus Absatz 5 selbst. Der Status des Upstreams und Ihre Pflicht sind zwei verschiedene Dinge.

Aufsetzend auf der Stückliste, aber mehr als sie. Die SBOM (Anhang I Teil II Nr. 1) ist die Inventarschicht und muss mindestens die direkten Abhängigkeiten abdecken; die Sorgfaltsbewertung ist die Beurteilungsschicht darauf. Eine vollständige Stückliste allein ist noch keine erfüllte Sorgfaltspflicht - sie listet, Absatz 5 verlangt zu bewerten.

Abgelehnte Alternativen

  • Stückliste als Sorgfaltsnachweis ausgeben. Eine SBOM inventarisiert, sie bewertet nicht. Ohne die Beurteilungsschicht fehlt der Nachweis nach Absatz 5.
  • Erzwungenes Vollformular je Komponente. Widerspräche dem risiko-proportionalen Maßstab des Erwägungsgrunds 34 und erzeugte Pseudo-Arbeit für unkritische Bausteine.
  • Bewertung je Produkt führen. Würde dieselbe Komponente über Produkte hinweg mehrfach prüfen lassen und bei jedem SBOM-Re-Ingest verwaisen. Deshalb org-weit am purl.
  • Steward-Pflege als Entlastung darstellen. Wäre rechtlich falsch; die Pflicht des Integrators bleibt.

Wie Dernium hilft

Sie lesen Ihre Stücklisten ohnehin ein; daraus fällt die Komponentenliste ab, und Sie hängen je Baustein eine angemessene Bewertung an. Ein Abdeckungs-Zähler zeigt, wie viele Komponenten bereits entschieden sind. Eine Erklärschicht benennt den risiko-proportionalen Maßstab und die Absatz-6-Meldepflicht, und eine klare Linie trennt, was wir aus der Stückliste beisteuern, von dem, was Sie als Hersteller beurteilen. So wird die Drittkomponenten-Sorgfalt ein geführter, belegbarer Schritt statt einer Tabelle nebenher.

Offene Punkte

  • Die inhaltliche Beurteilung jeder Komponente - und die Entscheidung, welche Prüfungen dem Risiko angemessen sind - verantwortet der Hersteller. Das Werkzeug strukturiert und erinnert; es bewertet nicht und ist keine Rechtsberatung.
  • Die Stückliste muss mindestens die direkten Abhängigkeiten abdecken; tiefere, transitive Bausteine sind über dem gesetzlichen Mindestmaß, aber sicherheitlich oft das Entscheidende.

Verifikation

Die Sorgfaltspflicht für Drittkomponenten steht in Artikel 13 Absatz 5, die Upstream-Meldung und Fix-Weitergabe in Absatz 6; der risiko-proportionale Maßstab samt der vier Prüfungen ist in Erwägungsgrund 34 beschrieben. Die Stücklisten-Pflicht folgt aus Anhang I Teil II Nr. 1, das leichtere Pflichtenregime der Open-Source-Verwalter aus Artikel 24.

Mehr aus unserer CRA-Reihe