Die CRA fordert jahrelange Sicherheitsupdates: Ihre Abhängigkeiten halten möglicherweise nicht so lange

Wichtigste Erkenntnisse

• Gemäß dem Cyber-Resilience-Gesetz müssen Sie Sicherheitslücken in Ihrem Produkt, einschließlich derer in dessen Abhängigkeiten, mindestens fünf Jahre lang beheben, es sei denn, es ist davon auszugehen, dass das Produkt nur für einen kürzeren Zeitraum genutzt wird.
• Viele Open-Source-Frameworks bieten Support für eine Version über einen Zeitraum von ein bis drei Jahren an, sodass ein Produkt, das auf Basis einer aktuellen Version auf den Markt gebracht wurde, möglicherweise schon während der Supportphase keinen Zugriff mehr auf Sicherheitsupdates des Upstream-Projekts hat.
• Vier Möglichkeiten, um auch nach Ablauf des Upstream-Supports weiterhin Sicherheitsupdates zu erhalten: Wechsel zu einer neueren Version, Ersetzen der Abhängigkeit, eigenständige Behebung des Problems oder Kauf der Updates.
• Die Meldepflicht gilt seit dem 11. September 2026, sodass eine aktiv ausgenutzte Sicherheitslücke in einer Abhängigkeit, deren Lebensdauer bereits abgelaufen ist, bereits heute meldepflichtig ist, auch wenn noch kein Upstream-Fix vorliegt, auf den verwiesen werden kann. Die Regeln zum Supportzeitraum treten am 11. Dezember 2027 in Kraft.

Der Supportzeitraum gemäß dem EU-Gesetz zur Cyber-Resilienz (CRA) muss mindestens fünf Jahre betragen, es sei denn, ein Produkt wird voraussichtlich nur für einen kürzeren Zeitraum genutzt. Bei neueren Versionen beliebter Frameworks wie Laravel, Django und Spring Boot wurden bereits 1 bis 3 Jahre nach ihrer Veröffentlichung keine Open-Source-Sicherheitspatches mehr bereitgestellt. Wenn Sie Software vertreiben, die auf diesen Frameworks basiert, werden die Upstream-Patches bereits vor Ablauf Ihres Supportzeitraums eingestellt, und Sie müssen die Patches für den verbleibenden Zeitraum selbst bereitstellen.

Ein Supportzeitraum ist der Zeitraum, in dem ein Hersteller für die Behebung von Sicherheitslücken in einem Produkt verantwortlich ist. Im Sinne des CRA gilt als Hersteller jeder, der das Produkt im Rahmen einer gewerblichen Tätigkeit unter seinem eigenen Namen oder seiner eigenen Marke vermarktet, unabhängig davon, ob dies gegen Entgelt oder unentgeltlich geschieht. Die Pflicht des Herstellers zur Behebung von Sicherheitslücken erstreckt sich auf das gesamte Produkt, einschließlich seiner Komponenten. Die Personen, die die zugrunde liegenden Bibliotheken pflegen, unterliegen in der Regel keiner entsprechenden Verpflichtung, sodass sie nicht dazu verpflichtet sind, die von Ihnen ausgelieferte Version weiterhin zu aktualisieren.

Die wichtigsten Verpflichtungen treten am 11. Dezember 2027 in Kraft. Das mag noch weit entfernt erscheinen, bis man die Anforderungen an den Supportzeitraum mit der Dauer vergleicht, für die die heute ausgewählten Frameworks weiterhin Updates erhalten werden.

Was der CRA-Unterstützungszeitraum erfordert

Das Gesetz zur Cyber-Resilienz ist die Verordnung (EU) 2024/2847. Im Sinne dieses Gesetzes gilt als Hersteller jede natürliche oder juristische Person, die ein Produkt entwickelt oder entwickeln lässt und es unter ihrem eigenen Namen oder ihrer eigenen Marke vermarktet, sei es gegen Entgelt oder unentgeltlich. Der Supportzeitraum wird darin als der Zeitraum definiert, während dessen der Hersteller sicherstellen muss, dass Schwachstellen des Produkts wirksam behoben werden.

Gemäß Artikel 13 des CRA sind Hersteller verpflichtet, den Zeitraum so festzulegen, dass er der voraussichtlichen Nutzungsdauer des Produkts entspricht. Dabei sind die angemessenen Erwartungen der Nutzer, die Art des Produkts und dessen Verwendungszweck zu berücksichtigen. Der Zeitraum muss mindestens fünf Jahre betragen. Die einzige Ausnahme bilden Produkte, deren Nutzungsdauer voraussichtlich kürzer ist; in diesem Fall entspricht der Zeitraum der erwarteten Nutzungsdauer. Ist vernünftigerweise davon auszugehen, dass ein Produkt länger als fünf Jahre genutzt wird, muss der Zeitraum entsprechend verlängert werden. In den Erwägungsgründen des Gesetzes werden Router, Betriebssysteme und industrielle Steuerungssysteme als Beispiele genannt.

Mit diesem Zeitraum gehen drei Verpflichtungen einher. Hersteller müssen Sicherheitsupdates unverzüglich und kostenlos bereitstellen. Die einzige Ausnahme bildet ein maßgeschneidertes Produkt, bei dem sich der Hersteller und ein gewerblicher Nutzer auf eine Gebühr für Updates einigen können. Das Enddatum, zumindest mit Angabe von Monat und Jahr, muss zum Zeitpunkt des Kaufs klar sein. Und jedes Sicherheitsupdate bleibt mindestens 10 Jahre lang verfügbar oder für die restliche Dauer des Supportzeitraums, falls dieser länger ist. Alle drei Bestimmungen gelten sowohl für Korrekturen an den Open-Source-Komponenten innerhalb des Produkts als auch für Ihren eigenen Code. Das veröffentlichte Enddatum ist eine öffentliche Verpflichtung; erkundigen Sie sich daher, wie lange Ihre Abhängigkeiten weiterhin Upstream-Korrekturen erhalten, bevor Sie es festlegen.

Hinweis: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den Hauptanforderungen des CRA nur dann, wenn sie nach diesem Datum einer wesentlichen Änderung unterzogen werden. Das bedeutet eine Änderung nach der Markteinführung, die sich auf die Einhaltung der Produktanforderungen des Gesetzes auswirkt oder den Zweck ändert, für den das Produkt bewertet wurde. Artikel 14, der die Berichterstattung regelt, funktioniert anders: Die darin festgelegten Pflichten gelten für unter das Gesetz fallende Produkte, die bereits auf dem Markt sind, und sind seit dem 11. September 2026 in Kraft.

Wie lange übliche Abhängigkeiten andauern

Drei Framework-Versionen – jeweils eine aus Python, PHP und Java – haben kürzlich das Ende ihres Lebenszyklus erreicht. In diesem Artikel bezeichnet „Ende des Lebenszyklus “ das Datum, ab dem ein Projekt keine Sicherheitspatches mehr für eine Version bereitstellt.

Jedes Projekt formuliert dies anders. Django spricht vom Ende des erweiterten Supports, Laravel gibt an, ab wann keine Sicherheitskorrekturen mehr bereitgestellt werden, und Spring bezeichnet es als das Ende des Open-Source-Supports. Für Sie bedeuten diese Begriffe dasselbe, da für die von Ihnen ausgelieferte Version keine Upstream-Korrekturen mehr bereitgestellt werden.

Keines der drei Frameworks erhielt fünf Jahre lang Sicherheitsupdates vom Upstream-Entwickler – das ist das Minimum, das die CRA von Ihnen verlangt. Das Veröffentlichungsdatum des Frameworks ist jedoch weniger wichtig als das Markteinführungsdatum Ihres Produkts, da Ihr Supportzeitraum erst dann beginnt, wenn Sie das Produkt auf den Markt bringen. Prüfen Sie am Tag der Markteinführung, wie lange der Upstream-Support für das Framework noch läuft. Nehmen wir ein Produkt, das am 11. Dezember 2027 auf den Markt kommt – dem Tag, an dem die Regeln für den Supportzeitraum in Kraft treten: Sein Supportzeitraum muss mindestens bis zum 11. Dezember 2032 reichen. Basiert es auf Laravel 13, das am 17. März 2026 veröffentlicht wurde, würde es bis zum 17. März 2028 – also etwa drei Monate nach Beginn dieses Zeitraums – weiterhin Sicherheitspatches vom Upstream erhalten. Wäre es auf Django 5.2, einer Version mit langfristigem Support, aufgebaut, würde es diese bis April 2028 erhalten, also etwa vier Monate nach Beginn des Zeitraums. Neuere Framework-Versionen werden noch vor Dezember 2027 erscheinen: Laravel veröffentlicht etwa jedes Jahr eine Hauptversion, und Django 6.2 ist für April 2027 vorgesehen, mit erweitertem Support bis April 2030 – etwas mehr als zwei Jahre nach Beginn desselben Zeitraums. Unabhängig davon, mit welcher Version Sie starten: Die Korrekturen vom Upstream enden Jahre vor Ablauf Ihres Supportzeitraums, und die Korrekturen für die verbleibenden Jahre müssen von Ihnen selbst bereitgestellt werden.

Sie können auf eine neuere Version umsteigen – und viele Teams werden dies auch tun –, doch diese technischen Arbeiten müssen vor oder während Ihres Supportzeitraums abgeschlossen sein. Drei Frameworks machen noch nicht den gesamten Stack aus, und einige Ihrer Abhängigkeiten werden länger als fünf Jahre bestehen bleiben. Ihre Aufgabe besteht darin, die Veröffentlichungsdaten der einzelnen Komponenten mit Ihren eigenen abzugleichen.

Wer ist für den von Ihnen ausgelieferten Open-Source-Code verantwortlich?

Die CRA sagt zwei Dinge über Komponenten aus, die Sie nicht selbst geschrieben haben. „Komponente“ ist der Begriff für die Abhängigkeiten, die Sie einbinden. Artikel 13 verpflichtet Hersteller dazu, bei der Integration von Komponenten von Drittanbietern, einschließlich Open-Source-Komponenten, die gebotene Sorgfalt walten zu lassen, damit diese Komponenten die Sicherheit des Produkts nicht gefährden. Und wenn ein Hersteller eine Schwachstelle in einer Komponente entdeckt, muss er diese den Betreibern der Komponente melden und in seinem eigenen Produkt beheben. Wenn der Hersteller einen Fix entwickelt, muss er den Code oder die Dokumentation an diese Betreiber weitergeben, gegebenenfalls in einem maschinenlesbaren Format.

Betreiber werden je nach ihrer Identität unterschiedlich behandelt. Ein Open-Source-Software-Steward ist eine juristische Person – mit Ausnahme eines Herstellers –, die bestimmte Open-Source-Produkte, die für kommerzielle Aktivitäten bestimmt sind, systematisch unterstützt und deren Fortbestand sichert. Zu dieser Gruppe können Stiftungen und Unternehmen gehören, die Open-Source-Software in einem geschäftlichen Kontext veröffentlichen. Artikel 24 verpflichtet Verwalter dazu, eine Cybersicherheitsrichtlinie einzuführen und zu dokumentieren, die eine sichere Entwicklung und einen wirksamen Umgang mit Sicherheitslücken gewährleistet, sowie mit den Marktüberwachungsbehörden zusammenzuarbeiten. Darüber hinaus werden begrenzte Meldepflichten festgelegt. Open-Source-Projekte, die nicht kommerziell genutzt werden, fallen im Allgemeinen nicht unter die Verpflichtungen der Hersteller, und einzelne Mitwirkende an Projekten, die sie nicht selbst betreiben, sind davon ausgenommen.

Aus der Verordnung: Wenn ein Hersteller die Dauer seines Supportzeitraums festlegt, darf er gemäß Artikel 13 die Supportzeiträume von Komponenten Dritter berücksichtigen, die Kernfunktionen bereitstellen. Dies kann einen längeren Zeitraum rechtfertigen. Die Mindestdauer von fünf Jahren darf dabei jedoch nicht unterschritten werden; ein Framework, bei dem nach zwei Jahren keine vorgelagerten Korrekturen mehr bereitgestellt werden, berechtigt Sie daher nicht dazu, einen Zeitraum von zwei Jahren anzugeben. Die Mindestdauer von fünf Jahren gilt weiterhin.

Insgesamt gesehen ist der Vorlieferant Ihnen in der Regel keine Supportleistung schuldig, und die CRA macht Sie als Hersteller für die Behebung von Sicherheitslücken im Endprodukt verantwortlich.

Was Sie tun können, wenn eine Abhängigkeit das Ende ihrer Lebensdauer erreicht

Sobald die Arbeit im vorgelagerten Bereich eingestellt wird, muss jemand die Korrekturen vornehmen, und die CRA legt nicht fest, wer dafür zuständig ist. Damit bleiben vier Möglichkeiten, für die jeweils unterschiedliche Kosten entstehen.

Umstellung auf eine neuere Version: Dies funktioniert, wenn Sie selbst bestimmen können, wann Kunden neue Versionen erhalten, und es kostet in jedem Zyklus Entwicklungszeit. Bei einer Anwendungsarchitektur mit mehreren Frameworks, die unterschiedlichen Zeitplänen unterliegen, summieren sich diese Migrationen.

Ersetzen Sie die Abhängigkeit: Eine gepflegte Alternative beseitigt das Problem, sofern eines vorliegt, und Sie können sich die Neuprogrammierung leisten.

Beheben Sie das Problem selbst: Ihr Team portiert Sicherheitskorrekturen auf die von Ihnen ausgelieferte Version zurück. Dazu sind Mitarbeiter erforderlich, die sich mit dem Code gut auskennen, und gemäß Artikel 13 sind Sie verpflichtet, die Sicherheitslücke den Betreuern zu melden und ihnen Ihre Korrektur zur Verfügung zu stellen.

Kaufen Sie die Patches: Einige Anbieter verkaufen erweiterten Support für ältere Versionen. In der Ankündigung von Spring selbst heißt es beispielsweise, dass der kommerzielle Support für Spring Framework 6.2 bis Mitte 2032 läuft. Die Support-Daten von Spring listen den Enterprise-Support für Spring Boot 3.5 – die in der obigen Tabelle aufgeführte Version – bis zum 30. Juni 2032 auf. Auch unabhängige Anbieter verkaufen Patches für Versionen, deren Lebenszyklus abgelaufen ist. Der Umfang hängt von den spezifischen Versionen ab, die Sie einsetzen. Geben Sie dem Anbieter daher Ihre tatsächliche Versionsliste an und vergewissern Sie sich, dass jede einzelne Version abgedeckt ist, bevor Sie sich darauf verlassen.

Zwei weitere Maßnahmen erscheinen verlockend. Die Festlegung eines kürzeren Supportzeitraums ist nur dann möglich, wenn Sie davon ausgehen, dass das Produkt weniger als fünf Jahre lang genutzt wird. Die Dokumentation einer bekannten Schwachstelle in einem Risikoregister mag dies zwar erklären, doch die CRA verlangt von den Herstellern, Schwachstellen unverzüglich zu beheben – und ein Eintrag im Register ist keine Behebung.

Was Sie vor der Festlegung eines Unterhaltszeitraums klären sollten

Das Enddatum muss bereits beim Kauf angegeben werden; daher ist es einfacher, Fragen zu den Abhängigkeiten vor der Veröffentlichung zu klären als danach.

• Beginnen Sie mit einer Bestandsaufnahme: Eine aktuelle Liste der Bestandteile Ihres Produkts – in der Regel eine Software-Stückliste (SBOM) – zeigt Ihnen, welche Abhängigkeiten Sie überprüfen müssen, einschließlich derjenigen, die von Ihren direkten Abhängigkeiten eingebunden werden.
• Tragen Sie die Termine ein: Tragen Sie das veröffentlichte Ende der Lebensdauer jeder Abhängigkeit neben den von Ihnen in Betracht gezogenen CRA-Supportzeitraum ein. Dazu eignet sich eine Tabellenkalkulation.
• Überprüfen Sie jede Version: Der Support gilt pro Version, wie aus den Daten für Django, Laravel und Spring Boot hervorgeht. Ermitteln Sie das End-of-Life-Datum für genau die Version, die Sie ausliefern. Die Leitlinien der Kommission sehen außerdem vor, dass für jede wesentlich geänderte Version, die Sie auf den Markt bringen, ein Supportzeitraum angegeben wird.
• Bestimmen Sie für jede Lücke einen Verantwortlichen: Wählen Sie für jede nicht erfüllte Abhängigkeit einen der vier Ansätze aus und legen Sie fest, wer dafür zuständig ist.
• Kennzeichnen Sie, was bereits das Ende seiner Lebensdauer überschritten hat: Wenn eine Abhängigkeit in einem ausgelieferten Produkt heute das Ende ihrer Lebensdauer überschritten hat, besteht die Lücke bereits jetzt. Falls das Produkt in den Geltungsbereich fällt, muss eine aktiv ausgenutzte Sicherheitslücke in dieser Abhängigkeit seit dem 11. September 2026 innerhalb von 24 Stunden gemeldet werden. In der anschließenden 72-Stunden-Meldung muss angegeben werden, welche Maßnahmen Sie ergriffen haben, solange es noch keinen Upstream-Fix gibt, auf den verwiesen werden kann.
• Notieren Sie sich die Gründe dafür: Die technische Dokumentation muss die Informationen enthalten, auf deren Grundlage Sie den Zeitraum festgelegt haben; bewahren Sie daher Ihre Begründung auf.

Die Lücke bis Dezember 2027 schließen

Man legt einen Supportzeitraum fest, wenn man ein Produkt auf den Markt bringt und es dann über Jahre hinweg weiterführt, während die zugrunde liegenden Frameworks ihren eigenen Zeitplänen folgen. Wenn man diese beiden Zeiträume vor der Entscheidung aufeinander abstimmt, wird deutlich, wie viele dieser Jahre man damit verbringen wird, Sicherheitspatches für Code zu beschaffen, für den die Verantwortlichen keine Patches mehr bereitstellen.

Sollte eines der Ihrem Produkt zugrunde liegenden Frameworks vor Ablauf Ihres Supportzeitraums keine Sicherheitspatches mehr vom Upstream-Entwickler erhalten, muss dennoch jemand diesen Patch bereitstellen. „Endless Lifecycle Support“ (ELS) von TuxCare übernimmt diese Aufgabe. Die Ingenieure von TuxCare portieren Sicherheitspatches rückwärts auf genau die Versionen, die Sie bereits einsetzen – und zwar so lange, wie Sie darauf angewiesen sind. Ihre Entwickler behalten die Versionen, die sie haben, und die Arbeitsabläufe, die sie nutzen. ELS lässt sich zudem mit SecureChain kombinieren, das Open-Source-Pakete vor der Installation überprüft und sie patcht, solange der Upstream noch aktiv ist.

Werden SecureChain und ELS gemeinsam erworben, erfolgt die automatische Übergabe der Abdeckung. Wenn ein Maintainer keine Sicherheitspatches mehr für eine von Ihnen verwendete Version veröffentlicht, geht die Abdeckung für diese Version von SecureChain auf ELS über. Sie müssen nicht das End-of-Life-Datum jeder einzelnen Komponente im Auge behalten, um zu wissen, wann keine Upstream-Patches mehr bereitgestellt werden. Die Produkte decken nun die Ökosysteme von JavaScript, Python, Java, Go und PHP ab.

FAQ

Wie lang ist die Mindestlaufzeit des EU-CRA-Förderzeitraums?

Das EU-Gesetz zur Cyber-Resilienz (CRA) legt eine Mindestunterstützungsdauer von fünf Jahren fest. Ein Hersteller kann diese Frist nur dann verkürzen, wenn davon auszugehen ist, dass das Produkt weniger lange genutzt wird; in diesem Fall richtet sich die Frist nach der Nutzungsdauer. Ein Produkt, das voraussichtlich länger genutzt wird, erfordert eine längere Unterstützungsdauer.

Müssen Open-Source-Betreuer alte Versionen weiterhin unterstützen?

Im Allgemeinen nicht. Das Cyber Resilience Act (CRA) behandelt zwei Gruppen unterschiedlich, und keine der beiden Gruppen unterliegt einer Verpflichtung zur Gewährleistung eines Supportzeitraums. Open-Source-Software-Stewards – juristische Personen, die Open-Source-Produkte für den kommerziellen Einsatz systematisch betreuen – müssen eine Cybersicherheitsrichtlinie dokumentieren, einschließlich des Umgangs mit Sicherheitslücken, und mit den Behörden zusammenarbeiten. Open-Source-Projekte, die nicht monetarisiert werden, fallen nicht unter die Herstellerpflichten, und einzelne Mitwirkende an Projekten, die sie nicht betreiben, sind überhaupt nicht erfasst. In jedem Fall muss der Hersteller, der den Code ausliefert, diesen während des von ihm angegebenen Supportzeitraums auf dem neuesten Stand halten.

Was passiert, wenn für eine Abhängigkeit während des Supportzeitraums keine Sicherheitsupdates mehr bereitgestellt werden?

Die Verantwortung liegt weiterhin beim Hersteller. Gemäß dem Cyber Resilience Act (CRA) müssen Sicherheitslücken im Produkt, einschließlich seiner Komponenten, während der gesamten vom Hersteller angegebenen Supportdauer behoben werden. Zu den möglichen Vorgehensweisen gehören der Wechsel zu einer unterstützten Version, der Austausch der Abhängigkeit, die Entwicklung eines Fixes oder der Kauf von Patches für die alte Version.

Was müssen Hersteller den Nutzern über die Supportdauer mitteilen?

Gemäß dem Cyber Resilience Act (CRA) muss das Enddatum des Supportzeitraums – zumindest mit Angabe von Monat und Jahr – bereits zum Zeitpunkt des Kaufs klar ersichtlich sein. Die Hersteller halten zudem in ihrer technischen Dokumentation fest, wie sie diesen Zeitraum festlegen, und informieren die Nutzer, sofern dies technisch machbar ist, über das Ende des Supports.

Gilt das Gesetz zur Cyber-Resilienz auch für Produkte, die bereits vor Dezember 2027 auf dem Markt waren?

Nur wenn sie wesentlich verändert werden. Nach dem Cyber Resilience Act (CRA) unterliegen Produkte, die bereits vor dem 11. Dezember 2027 auf dem Markt waren, den Anforderungen dieses Gesetzes erst nach einer wesentlichen Änderung ab diesem Datum. Die Meldepflichten gemäß Artikel 14, einschließlich derjenigen für aktiv ausgenutzte Schwachstellen, gelten für diese Produkte ohnehin.

Sind die Leitlinien der Kommission zum Gesetz über Cyberresilienz rechtsverbindlich?

Nein. Die Europäische Kommission hat am 27. Juli 2026 ihre Leitlinien zum Cyber Resilience Act (CRA) veröffentlicht, um die Anwendung der Vorschriften zu erläutern, doch diese sind nicht verbindlich. Die Verordnung selbst sowie die erlassenen delegierten Rechtsakte oder Durchführungsrechtsakte sind rechtsverbindlich, und nur der Gerichtshof der Europäischen Union kann eine maßgebliche Auslegung vornehmen. Die Leitlinien zeigen jedoch auf, wie die Kommission die Anwendung der Vorschriften erwartet; daher sollten sie als Grundlage für die Planung herangezogen werden, bis ein Gericht etwas anderes entscheidet.

Zusammenfassung

Artikel Name

Die Anforderungen an den CRA-Supportzeitraum gelten länger als Ihre Abhängigkeiten

Beschreibung

Die CRA schreibt vor, dass Sicherheitskorrekturen mindestens 5 Jahre lang bereitgestellt werden müssen. Viele Open-Source-Frameworks unterstützen eine Version nur für 1 bis 3 Jahre. Danach müssen Sie die Korrekturen selbst bereitstellen.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers