CRA und Open-Source-Komponenten: Was Hersteller beim Einsatz fremder Bibliotheken beachten müssen

Fast jede moderne Software besteht größtenteils aus fremdem Code. Bibliotheken, Frameworks und kleine Hilfspakete aus der Open-Source-Welt stecken in praktisch jedem Produkt. Der Cyber Resilience Act (CRA) ändert jetzt, wer dafür geradesteht.

CRA und Open-Source-Komponenten gehören ab sofort zusammen gedacht. Die EU-Verordnung macht Hersteller für die Sorgfalt bei fremden Bauteilen verantwortlich. Das gilt auch, wenn die Komponente kostenlos und öffentlich war.

Viele Unternehmen wissen nicht genau, was in ihrer Software steckt. Genau das wird mit dem CRA zum echten Problem.

Was der Cyber Resilience Act von Herstellern verlangt

Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen. Darunter fällt fast jede Software, die verkauft oder vertrieben wird. Er verpflichtet Hersteller zu einem bestimmten Sicherheitsniveau über den gesamten Lebenszyklus.

Diese Pflicht endet nicht an der eigenen Code-Grenze. Wer eine Open-Source-Bibliothek einbaut, übernimmt Verantwortung für sie. Der CRA verlangt eine dokumentierte Sorgfaltsprüfung, bevor eine Komponente zum Einsatz kommt.

Zur Sorgfaltsprüfung zählen bekannte Sicherheitslücken, die Update-Historie und die Lizenzbedingungen der Komponente. Auch die Frage, wie aktiv ein Open-Source-Projekt noch gepflegt wird, gehört dazu. Ein verwaistes Projekt ohne Updates ist ein Warnsignal.

Besonders wichtig: Die Pflicht gilt während der ganzen Nutzungsdauer des Produkts. Ein Hersteller muss neue Lücken in eingesetzten Komponenten aktiv beobachten. Das unterscheidet den CRA von vielen bisherigen Regelwerken, die nur den Entwicklungszeitpunkt betrachteten.

Ab wann gelten die CRA-Pflichten für Open-Source-Komponenten?

Der Cyber Resilience Act ist im Dezember 2024 in Kraft getreten. Zwischen Inkrafttreten und vollständiger Pflicht liegen aber mehrere Jahre Übergangszeit.

Meldepflichten für aktiv ausgenutzte Sicherheitslücken und schwere Vorfälle gelten bereits ab September 2026. Hersteller müssen solche Fälle dann innerhalb kurzer Fristen an die zuständige Behörde melden.

Die vollständigen Konformitätspflichten, inklusive der Sorgfalt bei Open-Source-Komponenten, greifen ab Dezember 2027. Das klingt nach viel Zeit. Erfahrungsgemäß dauert eine gründliche Bestandsaufnahme aber länger, als die meisten Unternehmen zunächst denken. Wer jetzt startet, umgeht den Zeitdruck kurz vor dem Stichtag.

Welche Konsequenzen drohen ohne saubere Open-Source-Pflege?

Wer die Sorgfaltspflicht ignoriert, riskiert mehr als nur eine technische Lücke.

Bußgelder und Marktausschluss

Verstöße gegen den CRA sind teuer. Bußgelder reichen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Umsatzes. Marktaufsichtsbehörden können betroffene Produkte außerdem vom Markt nehmen.

Sicherheitslücken wandern unbemerkt mit

Eine veraltete Bibliothek bringt ihre Lücken in jedes Produkt mit, das sie nutzt. Wird eine Lücke öffentlich bekannt, zählt oft jede Stunde ohne Patch. Angreifer scannen das Internet gezielt nach bekannten, ungepatchten Komponenten.

Lizenzrisiken, die niemand auf dem Schirm hat

Manche Open-Source-Lizenzen verpflichten zur Offenlegung des eigenen Codes. GPL und AGPL gehen hier deutlich weiter als MIT oder Apache. Wer das übersieht, riskiert ein Bußgeld und möglichen Streit mit Lizenzgebern. Mehr dazu lesen Sie in unserem Artikel zur Lizenz-Compliance bei Legacy-Projekten.

Vertrauensverlust bei Kunden und Partnern

Ein öffentlich bekannter Vorfall bleibt selten intern. Kunden, Partner und manchmal die Presse erfahren davon. Das beschädigt das Vertrauen in ein Produkt oft länger, als die eigentliche Lücke offen war.

Wie Sie die Pflichten mit vertretbarem Aufwand erfüllen

Ein PHP-Upgrade oder eine Sicherheitsprüfung wirkt oft größer als sie ist. Bei Open-Source-Pflichten gilt dasselbe. Mit einem klaren Vorgehen lässt sich der Aufwand gut planen.

Schritt 1: Überblick schaffen

Ohne Überblick gibt es keine Sorgfalt. Der erste Schritt ist eine vollständige Liste aller eingesetzten Komponenten. Diese Liste heißt Software-Stückliste oder SBOM, kurz für Software Bill of Materials.

Eine SBOM zeigt, welche Bibliothek in welcher Version tatsächlich läuft. Ohne sie bleibt jede spätere Prüfung Stückwerk. Mehr zum Aufbau einer SBOM lesen Sie in unserem Artikel zur SBOM-Pflicht.

Schritt 2: Lücken und Updates laufend prüfen

Eine einmalige SBOM reicht nicht aus. Sie muss regelmäßig mit aktuellen Sicherheitsdatenbanken abgeglichen werden.

Automatisierte Scanner prüfen jede Komponente gegen bekannte CVEs, also öffentlich dokumentierte Sicherheitslücken. So fallen veraltete oder verwundbare Bibliotheken schnell auf. Diese Prüfung gehört in den laufenden Betrieb, nicht nur ans Projektende.

Schritt 3: Lizenzen dokumentieren

Jede Komponente bringt eine eigene Lizenz mit. MIT und Apache sind in der Praxis meist unproblematisch. GPL und AGPL verlangen oft deutlich mehr vom Hersteller.

Ein Lizenz-Audit zeigt, welche Pflichten konkret entstehen und wo Handlungsbedarf besteht. Unser Artikel zu Open Source im Unternehmen beschreibt, worauf es dabei ankommt.

Schritt 4: Verantwortlichkeit klären

Sorgfalt braucht eine klare Zuständigkeit. Ohne sie bleibt die Pflege an niemandem konkret hängen und wird irgendwann vergessen.

Ein kleines Unternehmen braucht dafür keine eigene Abteilung. Oft reicht ein fester Prozess mit einem externen Partner. Der übernimmt die Prüfung regelmäßig und dokumentiert sie.

Wer zählt als Hersteller unter dem CRA?

Der Begriff "Hersteller" ist im CRA weit gefasst. Nicht nur klassische Softwarehäuser fallen darunter.

Auch ein Unternehmen, das eine Eigenentwicklung mit Open-Source-Komponenten verkauft oder betreibt, zählt als Hersteller. Entscheidend ist, dass ein Produkt mit digitalen Elementen am Markt bereitgestellt wird. Interne Software ohne Marktbezug fällt in der Regel nicht darunter.

Auch bei eingekaufter Standardsoftware bleibt die Sorgfaltspflicht beim Hersteller bestehen, der sie letztlich vertreibt. Die Verantwortung lässt sich also nicht einfach an einen Zulieferer weiterreichen.

Was CRA-Pflichten für Open-Source-Komponenten in der Praxis kosten

Der Aufwand hängt stark vom bestehenden Code ab. Ein neues Projekt mit wenigen, aktuellen Bibliotheken ist vergleichsweise schnell geprüft.

Eine gewachsene Anwendung mit Hunderten Abhängigkeiten braucht deutlich mehr Zeit. Hier hat sich über Jahre einiges angesammelt, das jetzt sichtbar wird. Das ist kein Grund zur Sorge, sondern der erste konkrete Schritt zur Lösung.

Die erste SBOM-Erstellung kostet meist den größten Teil des Aufwands. Kleine Projekte sind oft für wenige hundert Euro geprüft. Größere, gewachsene Systeme können mehrere tausend Euro kosten, abhängig von der Anzahl der Abhängigkeiten.

Danach lässt sich die Pflege weitgehend automatisieren und läuft im laufenden Betrieb mit. Wer früh startet, spart sich späteren Zeitdruck vor dem Stichtag im Dezember 2027.

Fazit: Handeln, bevor die Behörde fragt

Der CRA macht die Nutzung von Open-Source-Komponenten vor allem sichtbarer, nicht automatisch riskanter. Wer seine Komponenten kennt und pflegt, erfüllt die Pflicht fast nebenbei.

Wer das Thema jetzt aufschiebt, sammelt offene Fragen für die nächste Prüfung an. Ein geordneter Überblick ist deutlich günstiger als eine Lücke, die erst eine Behörde findet.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir verschaffen Ihnen einen klaren Überblick über Ihre Open-Source-Komponenten.