Bild: Generiert mit Gemini Flash

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

6 Min Lesezeit Serie: CRA-Reihe #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.

Inhalt dieses Beitrags
  1. Problem
  2. Kurze Antwort
  3. Tiefgang
  4. Abgelehnte Alternativen
  5. Was Sie jetzt tun sollten
  6. Wie Dernium hilft
  7. Offene Punkte
  8. Verifikation
  9. Häufige Fragen
  10. Reicht eine SBOM, um die CRA-Sorgfaltspflicht zu erfüllen?
  11. Muss ich jeden Baustein gleich gründlich prüfen?
  12. Bin ich für Open-Source-Komponenten überhaupt verantwortlich?
  13. Was muss ich tun, wenn ich in einem fremden Baustein eine Schwachstelle finde?
  14. Warum wird die Bewertung am Baustein und nicht am Produkt geführt?
  15. Mehr aus unserer CRA-Reihe

Problem

Moderne Software besteht zum größten Teil aus fremdem Code: Bibliotheken, Pakete, frei verfügbare Open-Source-Bausteine (offen einsehbarer Code, den jeder mitnutzen darf). Der CRA (Cyber Resilience Act, die EU-Verordnung zu Cybersicherheit von Produkten mit digitalen Elementen) verlangt in Artikel 13 Absatz 5, dass Hersteller beim Einbinden solcher fremden Bausteine - ausdrücklich auch quelloffener - die nötige Sorgfalt walten lassen, damit diese die Sicherheit des Produkts nicht gefährden. Eine bloße Stückliste reicht dafür nicht: sie zählt nur auf, sagt aber nichts darüber, ob jeder Baustein geprüft wurde. Und steckt in einem Baustein eine Schwachstelle, verlangt Absatz 6 zusätzlich, sie an dessen Pflegestelle (den "Upstream", die Person oder Stelle, die den Baustein betreut) zu melden und den eigenen Fix zu teilen. Wer das nicht dokumentiert, kann die erfüllte Pflicht nicht belegen.

Für wen ist das? Für Hersteller, die Fremd- und Open-Source-Komponenten nach dem CRA prüfen müssen.

Kurze Antwort

Der CRA verlangt mehr als eine Liste der verbauten Fremd-Bausteine - er verlangt eine nachweisbare Bewertung jedes einzelnen. Dernium CRA setzt diese Sorgfaltsprüfung (englisch "Due Diligence", die gebotene Sorgfalt bei der Auswahl) direkt auf die Stückliste:

  • Aus den eingelesenen Stücklisten entsteht je Produkt die Liste der fremden Bausteine.
  • Zu jedem Baustein hinterlegen Sie eine Bewertung: ein Risiko, einen Status (offen, akzeptiert, beobachten, ersetzen) und - je nach Risiko - die in Erwägungsgrund 34 genannten Prüfungen.
  • Diese Prüfungen sind: Konformität/CE des Anbieters, Wartung und Update-Historie, Abgleich mit Schwachstellen-Datenbanken, zusätzliche Tests.
  • Dazu kommen Meldekontakt zur Pflegestelle (für Absatz 6), Herkunft und Lizenz.
  • Die Bewertung gilt org-weit je Baustein - einmal geprüft, nicht in jedem Produkt erneut - und überlebt das erneute Einlesen von Stücklisten.

Dernium gibt keine eigene Bewertung ab; Inhalt und Verantwortung bleiben bei Ihnen.

Tiefgang

Die Stückliste listet die fremden Bausteine nur auf, der CRA verlangt eine Bewertung jedes einzelnen - org-weit am Baustein verankert, nicht je Produkt.
Die Stückliste listet die fremden Bausteine nur auf, der CRA verlangt eine Bewertung jedes einzelnen - org-weit am Baustein verankert, nicht je Produkt.

Aufwand nach Risiko, kein Pflicht-Vierkampf. Erwägungsgrund 34 (die erläuternde Begründung zur Verordnung) spricht ausdrücklich von "einer oder mehreren" Prüfungen, je nach Art und Höhe des Risikos des Bausteins (risiko-proportional - so viel Aufwand wie nötig, nicht pauschal alles). Eine reife, breit gepflegte Bibliothek braucht weniger als ein obskures Einzelstück. Die vier Prüffelder sind deshalb Angebote, kein Pflichtformular - Sie füllen sie dem Risiko angemessen aus.

Am Baustein verankert, nicht am Produkt. Eine Bausteinprüfung ist eine Lieferanten-Entscheidung: derselbe Baustein steckt oft in mehreren Produkten und Versionen. Die Bewertung wird daher org-weit an der eindeutigen Paketadresse geführt (englisch "purl", package URL, eine standardisierte Kennung für ein Paket) - genau wie unsere VEX-Aussagen (Vulnerability Exploitability eXchange, die Aussage, ob eine bekannte Schwachstelle im konkreten Produkt überhaupt ausnutzbar ist). Das hat zwei Effekte: Sie prüfen einmal statt mehrfach, und die Bewertung bleibt erhalten, wenn Sie eine Stückliste erneut einlesen.

Absatz 6 ist mitgedacht. Finden Sie eine Schwachstelle in einem Baustein, verlangt der CRA, sie an dessen Pflegestelle zu melden und einen Fix mit ihr zu teilen. Damit das im Ernstfall schnell geht, hält die Bewertung den Meldekontakt 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, eine Stelle mit eigenem, leichterem Pflichtenregime) gepflegt wird, verschiebt die Verantwortung nicht: wer den Baustein in ein kommerzielles Produkt einbaut, trägt die Sorgfaltspflicht aus Absatz 5 selbst.

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

Abgelehnte Alternativen

  • Stückliste als Sorgfaltsnachweis ausgeben. Eine Stückliste inventarisiert, sie bewertet nicht. Ohne die Beurteilungsschicht fehlt der Nachweis nach Absatz 5.
  • Erzwungenes Vollformular je Baustein. 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 denselben Baustein über Produkte hinweg mehrfach prüfen lassen und bei jedem erneuten Einlesen verwaisen. Deshalb org-weit an der Paketadresse.
  • Steward-Pflege als Entlastung darstellen. Wäre rechtlich falsch; die Pflicht des Integrators bleibt.

Was Sie jetzt tun sollten

  1. Lesen Sie für jedes Produkt eine Stückliste (SBOM) ein, die mindestens alle direkten Abhängigkeiten enthält. Das ist die Grundlage, auf der jede Bewertung aufsetzt.
  2. Verschaffen Sie sich einen Überblick, welche Bausteine über mehrere Produkte hinweg dieselben sind - diese bewerten Sie einmal org-weit und sparen sich die Mehrfacharbeit.
  3. Priorisieren Sie nach Risiko: Bewerten Sie obskure, selten gepflegte oder besonders kritische Bausteine zuerst und gründlich, breit gepflegte Standardbibliotheken knapper.
  4. Hinterlegen Sie zu jedem Baustein den Meldekontakt der Pflegestelle, damit Sie eine gefundene Schwachstelle nach Absatz 6 ohne Suche melden können.
  5. Behandeln Sie die Bewertung als lebendes Dokument: Wenn sich Update-Stand, bekannte Schwachstellen oder die Pflegelage eines Bausteins ändern, passen Sie Status und Risiko an.

Wie Dernium hilft

Sie lesen Ihre Stücklisten ohnehin ein; daraus fällt die Bausteinliste ab, und Sie hängen je Baustein eine angemessene Bewertung an. Ein Abdeckungs-Zähler zeigt, wie viele Bausteine bereits entschieden sind. Eine Erklärschicht benennt den risiko-proportionalen Maßstab und die Absatz-6-Meldepflicht, und eine klare Linie trennt, was wir 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 jedes Bausteins - und die Entscheidung, welche Prüfungen dem Risiko angemessen sind - verantworten Sie. Das Werkzeug strukturiert und erinnert; es bewertet nicht und ist keine Rechtsberatung.
  • Die Stückliste muss mindestens die direkten Abhängigkeiten abdecken; tiefere, weitergereichte 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.

Häufige Fragen

Reicht eine SBOM, um die CRA-Sorgfaltspflicht zu erfüllen?

Nein. Eine SBOM ist eine Inventarliste: sie zählt auf, welche fremden Bausteine verbaut sind, sagt aber nichts darüber aus, ob jeder davon geprüft wurde. Artikel 13 Absatz 5 verlangt eine Bewertung jedes Bausteins. Die SBOM ist die notwendige Grundlage, der Nachweis selbst ist die Bewertungsschicht obendrauf.

Muss ich jeden Baustein gleich gründlich prüfen?

Nein. Der Maßstab ist risiko-proportional: so viel Aufwand wie das Risiko des jeweiligen Bausteins erfordert. Erwägungsgrund 34 nennt vier mögliche Prüfungen, verlangt aber ausdrücklich nur "eine oder mehrere" davon, je nach Art und Höhe des Risikos. Eine breit genutzte, gut gepflegte Bibliothek braucht weniger als ein selten gepflegtes Einzelstück.

Bin ich für Open-Source-Komponenten überhaupt verantwortlich?

Ja. Quelloffene Bausteine fallen ausdrücklich unter die Sorgfaltspflicht. Auch wenn ein Projekt von einem Open-Source-Verwalter mit eigenem, leichterem Pflichtenregime betreut wird, bleibt die Verantwortung bei Ihnen, sobald Sie den Baustein in ein kommerzielles Produkt einbauen.

Was muss ich tun, wenn ich in einem fremden Baustein eine Schwachstelle finde?

Artikel 13 Absatz 6 verlangt, die Schwachstelle an die Pflegestelle des Bausteins (den Upstream) zu melden und einen von Ihnen entwickelten Fix mit ihr zu teilen. Deshalb ist es sinnvoll, den Meldekontakt jedes Bausteins schon im Vorfeld festzuhalten, damit dieser Schritt im Ernstfall ohne Verzögerung gelingt.

Warum wird die Bewertung am Baustein und nicht am Produkt geführt?

Weil derselbe Baustein häufig in mehreren Produkten und Versionen steckt. Wird die Bewertung an der eindeutigen Paketadresse geführt, prüfen Sie ihn einmal statt mehrfach, und die einmal getroffene Entscheidung bleibt erhalten, auch wenn Sie eine Stückliste erneut einlesen oder in einem anderen Produkt verwenden.

Mehr aus unserer CRA-Reihe