Cyber Resilience Act und was Hersteller von Software in Python jetzt tun müssen

Seit dem 11. September 2026 ist der Cyber Resilience Act für viele Softwarehersteller keine Zukunftsmusik mehr. Wer als Hersteller Produkte mit digitalen Elementen in der EU anbietet, muss aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden, mit einer ersten Frühwarnung binnen 24 Stunden. Die volle Wucht der Verordnung folgt am 11. Dezember 2027. Dann gelten alle Anforderungen an Sicherheit, Dokumentation und Updates.

Für Anwendungen in Python ist das eine besondere Aufgabe, weil moderne Projekte zum großen Teil aus fremden Paketen bestehen. Jedes davon kann eine Schwachstelle mitbringen, für die Sie als Hersteller geradestehen. In diesem Beitrag erklären wir, was der Cyber Resilience Act verlangt, wen er betrifft und wie Sie Ihre Projekte in Python Schritt für Schritt darauf vorbereiten.

Was der Cyber Resilience Act regelt

Die Verordnung ist seit Dezember 2024 in Kraft und gilt unmittelbar in allen Mitgliedstaaten. Sie betrifft Produkte mit digitalen Elementen, also Hardware und Software, die auf dem europäischen Markt angeboten werden. Dazu zählen Desktopsoftware, mobile Apps, Firmware und vernetzte Geräte genauso wie Bibliotheken und Komponenten, die kommerziell vertrieben werden.

Im Kern verlangt die Verordnung drei Dinge. Produkte müssen sicher entwickelt und ausgeliefert werden. Hersteller müssen Schwachstellen über den gesamten Supportzeitraum systematisch behandeln und Updates bereitstellen. Und sie müssen das dokumentieren, die Konformität erklären und das Produkt mit der CE-Kennzeichnung versehen.

Die wichtigsten Fristen

• Seit dem 10. Dezember 2024 ist die Verordnung in Kraft.
• Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle, auch für Produkte, die schon vorher auf dem Markt waren.
• Ab dem 11. Dezember 2027 gelten alle übrigen Pflichten, darunter die grundlegenden Anforderungen an die Sicherheit, die technische Dokumentation und die Konformitätsbewertung.

Die Meldepflichten im Detail

Sobald ein Hersteller von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erfährt, läuft die Uhr. Innerhalb von 24 Stunden ist eine Frühwarnung fällig, innerhalb von 72 Stunden eine ausführlichere Meldung. Ein Abschlussbericht folgt spätestens 14 Tage, nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist. Bei schweren Sicherheitsvorfällen gilt für den Abschlussbericht eine Frist von einem Monat. Gemeldet wird gleichzeitig an die ENISA und das zuständige nationale CSIRT, und zwar über die zentrale Single Reporting Platform der ENISA. Außerdem verlangt der Cyber Resilience Act in Artikel 14, dass Sie die Nutzer Ihres Produkts informieren, wenn eine Schwachstelle oder ein Vorfall sie betrifft, und ihnen sagen, was sie dagegen tun können.

Ein Szenario zeigt, wie knapp das ist. Am Freitagabend wird bekannt, dass eine weit verbreitete Bibliothek zur Verarbeitung von Bildern eine Lücke hat, die bereits aktiv ausgenutzt wird. Erfahren Sie sofort davon und betrifft die Lücke Ihr Produkt, ist die Frühwarnung bis Samstagabend fällig. Ohne aktuelle SBOM wissen Sie zu diesem Zeitpunkt vielleicht nicht einmal, ob Sie betroffen sind.

24 Stunden sind kurz, besonders am Wochenende. Legen Sie deshalb jetzt fest, wer Schwachstellen bewertet, wer meldet und wer die Kunden informiert.

Wen die Verordnung betrifft

Der Cyber Resilience Act richtet sich in erster Linie an Hersteller, außerdem an Importeure und Händler. Als Hersteller gilt, wer ein Produkt unter eigenem Namen auf den Markt bringt, auch wenn ein Dienstleister es entwickelt hat.

Einige Bereiche sind ausgenommen oder anders geregelt. Reines SaaS ist grundsätzlich vom CRA ausgenommen, sofern es keine Fernverarbeitungslösung im Sinne des CRA betrifft. Ob NIS2 gilt, hängt dagegen von Dienst, Sektor, Größe und nationaler Umsetzung ab. Freie Software ohne kommerziellen Hintergrund ist ebenfalls ausgenommen, und für Organisationen, die Open Source dauerhaft unterstützen, gibt es ein leichteres Regime. Medizinprodukte, Fahrzeuge und einige weitere Bereiche haben eigene Regeln. Weil die Abgrenzung im Einzelfall knifflig ist, lohnt sich eine juristische Prüfung. Dieser Beitrag ersetzt keine Rechtsberatung.

Was das für Software in Python bedeutet

Ein typisches Projekt in Python besteht nur zu einem kleinen Teil aus eigenem Code. Eine Anwendung mit Django, die Ihre Kunden selbst betreiben, bringt schnell mehrere Dutzend bis weit über hundert Pakete mit, wenn man die indirekten Abhängigkeiten mitzählt. Für den Cyber Resilience Act spielt es keine Rolle, ob eine Lücke in Ihrem Code oder in einer Bibliothek steckt. Sie sind für das Produkt als Ganzes verantwortlich. Daraus ergeben sich fünf praktische Aufgaben.

Software Bill of Materials

Sie brauchen eine maschinenlesbare Stückliste Ihrer Software, die mindestens die direkten Abhängigkeiten abdeckt. Üblich sind die Formate CycloneDX und SPDX. Für Python gibt es Werkzeuge, die eine SBOM direkt aus der Umgebung oder dem Lockfile erzeugen. Mit PEP 770 ist außerdem festgelegt, wie Pakete eigene SBOMs in ihren Wheels mitliefern können.

Reproduzierbare Abhängigkeiten

Ohne Lockfile weiß niemand genau, welche Versionen im ausgelieferten Produkt stecken. Werkzeuge wie uv erzeugen solche Dateien automatisch, und mit pylock.toml gibt es seit PEP 751 ein standardisiertes Format dafür.

Schwachstellen erkennen

Scanner wie Trivy, Grype oder Dependabot gleichen Ihre Pakete laufend mit Datenbanken bekannter Lücken ab. Das gehört in die CI und zusätzlich in einen regelmäßigen Job für bereits ausgelieferte Versionen.

Updates über Jahre

Der Supportzeitraum muss sich an der erwarteten Nutzungsdauer orientieren und beträgt in der Regel mindestens fünf Jahre. Das betrifft auch Python selbst. Kommt ein Produkt Ende 2027 mit Python 3.12 auf den Markt, endet der Support für diese Version schon im Oktober 2028. Upgrades von Python müssen Sie also von vornherein einplanen.

Sichere Voreinstellungen

Der Cyber Resilience Act verlangt außerdem, dass Produkte mit sicheren Voreinstellungen ausgeliefert werden. Für eine Anwendung mit Django, die beim Kunden läuft, heißt das zum Beispiel, dass der Debugmodus aus ist, Cookies geschützt sind, Passwörter sicher gespeichert werden und Schnittstellen nur das preisgeben, was sie müssen. Vieles davon bringt Django mit, es muss aber auch wirklich aktiviert sein.

Die Lieferkette absichern

Rund um Python sind Angriffe auf die Lieferkette kein theoretisches Risiko. Auf PyPI tauchen regelmäßig Pakete auf, deren Namen beliebten Bibliotheken zum Verwechseln ähnlich sehen, und hin und wieder werden auch Konten echter Maintainer übernommen. Schützen können Sie sich mit festen Versionen und Prüfsummen im Lockfile, einem eigenen Spiegel für freigegebene Pakete und einem kurzen Prüfschritt, bevor neue Abhängigkeiten ins Projekt kommen. Wer selbst Pakete veröffentlicht, sollte Trusted Publishing nutzen. Dabei lädt die Pipeline Releases ohne langlebige Zugangsdaten hoch, und es lässt sich nachweisen, aus welchem Repository ein Paket stammt.

Typische Lücken in bestehenden Projekten

Wenn wir bestehende Anwendungen auf den Cyber Resilience Act hin prüfen, finden wir fast immer ähnliche Baustellen. Abhängigkeiten sind nicht fest gepinnt oder seit Jahren nicht aktualisiert. Python selbst läuft auf einer Version ohne Support, etwa 3.9 oder nach dem für den 1. Oktober 2026 vorgesehenen Supportende von Python 3.10. Einige Pakete werden von niemandem mehr gepflegt. Zugangsdaten liegen im Repository. Und niemand weiß genau, welche Version bei welchem Kunden läuft. Nichts davon ist dramatisch, wenn man es kennt. Gefährlich wird es erst, wenn die erste Meldung fällig ist und diese Fragen unter Zeitdruck beantwortet werden müssen.

Fahrplan in sechs Schritten

1. Produkte erfassen und einstufen. Klären Sie, welche Produkte unter die Verordnung fallen und ob sie zur Standardkategorie oder zu den wichtigen beziehungsweise kritischen Produkten mit strengerer Prüfung gehören.
2. SBOM automatisieren. Jede Version erzeugt in der Pipeline automatisch eine aktuelle Stückliste, die archiviert wird.
3. Schwachstellenmanagement aufbauen. Dazu gehören laufende Scans, eine klare Bewertung und eine Richtlinie zur koordinierten Offenlegung, nach der Außenstehende Lücken melden können.
4. Meldeprozess festlegen. Bestimmen Sie, wer entscheidet, ob eine Schwachstelle aktiv ausgenutzt wird, wer an die ENISA meldet und wie das am Wochenende geregelt ist.
5. Updatefähigkeit sicherstellen. Sicherheitsupdates sollten getrennt von neuen Funktionen und möglichst automatisch ausgeliefert werden können.
6. Dokumentation und Bewertung vorbereiten. Technische Dokumentation, Risikoanalyse und Konformitätsbewertung brauchen Zeit, besonders bei wichtigen oder kritischen Produkten.

Was bis Dezember 2027 erledigt sein sollte

Bis zur vollen Anwendung bleibt gut ein Jahr, und das ist weniger, als es klingt. Wir empfehlen eine einfache Reihenfolge. Produktinventar und Meldeprozess sollten sofort stehen, denn die Meldepflichten gelten bereits. Im ersten Halbjahr 2027 folgen SBOMs, Scans und ein sauberer Updateprozess, inklusive der Upgrades veralteter Versionen von Python und Django. Im zweiten Halbjahr stehen technische Dokumentation und Konformitätsbewertung an. Wer so vorgeht, muss am Stichtag für den Cyber Resilience Act keine böse Überraschung fürchten.

Was bei Verstößen droht

Bei Verstößen gegen die grundlegenden Anforderungen sind Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes möglich, je nachdem, welcher Betrag höher ist. Dazu kommen mögliche Rückrufe und der Verlust des Marktzugangs. Mindestens so schwer wiegt oft der Vertrauensverlust bei Kunden, wenn eine bekannte Lücke monatelang offen bleibt.

Häufige Fragen zum Cyber Resilience Act

Gilt die Verordnung auch für Software, die wir nur intern nutzen?

In der Regel nicht. Der Cyber Resilience Act gilt erst, wenn Software auf dem Markt bereitgestellt wird. Für interne Systeme können aber andere Regeln wie NIS2 greifen.

Betrifft uns die Verordnung, wenn wir Open Source verwenden?

Ja, indirekt. Sie bleiben als Hersteller für Ihr Produkt verantwortlich, auch für die enthaltenen Bibliotheken. Sie müssen Komponenten sorgfältig auswählen sowie Schwachstellen im eigenen Produkt wirksam behandeln und beheben.

Reicht eine SBOM pro Release?

Für das ausgelieferte Produkt ja, sie muss aber exakt zu dieser Version passen. Entscheidend ist, dass Sie neue Schwachstellen in alten Versionen schnell erkennen. Dafür werden die SBOMs archiviert und regelmäßig gegen aktuelle Datenbanken geprüft.

Was ist der Unterschied zu NIS2?

NIS2 regelt die Cybersicherheit bestimmter Einrichtungen und ihres Betriebs, der Cyber Resilience Act die Sicherheit von Produkten. Viele Firmen sind von beidem betroffen.

Ihre Software mit unserem Python Team vorbereiten

Unser Python Team unterstützt Sie dabei, die technischen Anforderungen umzusetzen. Wir erzeugen SBOMs automatisch in Ihrer Pipeline, räumen veraltete Abhängigkeiten auf, aktualisieren Python und Frameworks wie Django und bauen Prozesse, mit denen Sicherheitsupdates schnell und sauber bei Ihren Kunden ankommen.

Sprechen Sie mit uns über Ihre Produkte, gerne erst einmal ganz unverbindlich. Gemeinsam finden wir heraus, wo Sie beim Cyber Resilience Act stehen und welche Schritte als Nächstes sinnvoll sind.