Die Frist, die vor der Norm kommt
Am 11. September 2026 greift Artikel 14 des Cyber Resilience Act. Ab diesem Datum muss jeder Hersteller, der ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden: eine Frühwarnung binnen 24 Stunden nach Kenntniserlangung, eine ausführlichere Meldung binnen 72 Stunden und einen Abschlussbericht binnen 14 Tagen bei einer Schwachstelle oder einem Monat bei einem Vorfall.
In den meisten Compliance-Fahrplänen steht der CRA unter 2027. Dort liegt tatsächlich der Grossteil der Verordnung: CE-Kennzeichnung, die grundlegenden Security-by-Design-Anforderungen, die technische Dokumentation und die Software-Stückliste gelten alle ab dem 11. Dezember 2027. Die Meldepflicht ist davon entkoppelt und kommt zuerst. Sie gilt auch für Produkte, die bereits auf dem Markt sind, nicht nur für solche, die danach bereitgestellt werden.
Der Abstand zwischen diesen beiden Daten ist das eigentliche Problem. Sie müssen die Ausnutzung einer Komponente achtzehn Monate früher melden, als Sie Ihre Komponenten dokumentieren müssen.
Die wichtigsten Daten
Die Verordnung (EU) 2024/2847 trat am 10. Dezember 2024 in Kraft. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026. Die übrigen Pflichten, einschliesslich der SBOM in der technischen Dokumentation, gelten ab dem 11. Dezember 2027.
Die Kommission hat am 27. Juli 2026 einen Umsetzungsleitfaden veröffentlicht, und der Meldekanal, die von der ENISA nach Artikel 16 betriebene Single Reporting Platform, soll am selben Tag verfügbar sein, an dem die Pflicht beginnt. Den aktuellen Stand finden Sie auf der CRA-Meldeseite der Kommission.
Der Primärtext ist die Verordnung (EU) 2024/2847. Artikel 14 regelt die Meldepflichten, Artikel 16 richtet die Single Reporting Platform ein, und Anhang I, Teil II regelt den Umgang mit Schwachstellen sowie die Software-Stückliste.
Ein Praxisbeispiel: Wie ein Sicherheitsscanner ein KI-Gateway kompromittierte
Im März 2026 kompromittierte die Bedrohungsakteursgruppe TeamPCP LiteLLM, ein weit verbreitetes Open-Source-KI-Gateway mit Proxy-Funktion. Zwei schadhafte Versionen, 1.82.7 und 1.82.8, gelangten auf PyPI. Sie waren rund vierzig Minuten lang verfügbar.
Entscheidend ist, wie sie dorthin gelangten. LiteLLM war nie das direkte Ziel. Die Build-Pipeline installierte den Schwachstellenscanner Trivy, ohne ihn auf eine geprüfte Version zu pinnen, und der Release-Prozess von Trivy selbst war bereits seit etwa zwanzig Tagen kompromittiert. Der manipulierte Scanner gelangte in den LiteLLM-Build und erzeugte manipulierte LiteLLM-Pakete. CloudSEK identifizierte dieselbe Kampagne bei einem dritten Werkzeug, Checkmarx KICS.
In Kontrollbegriffen gelesen heisst das: Das Werkzeug, dessen Aufgabe es war, Schwachstellen in der Pipeline zu finden, war die Schwachstelle in der Pipeline. Es lag innerhalb der Vertrauensgrenze, lief mit Pipeline-Berechtigungen und war von der Prüfung ausgenommen, die für Anwendungsabhängigkeiten gilt, weil es als Werkzeug und nicht als Code eingestuft war.
Ein Flussdiagramm, das zeigt, wie eine einzelne nicht widerrufene Zugangsberechtigung über drei Werkzeuge weitergereicht wurde. TeamPCP kompromittierte den Release-Prozess des Trivy-Scanners. Die CI-Pipeline von LiteLLM installierte die kompromittierte Trivy-Version automatisch, weil sie nicht gepinnt war. Der manipulierte Build erzeugte schadhafte LiteLLM-Pakete 1.82.7 und 1.82.8 auf PyPI, die 40 Minuten verfügbar waren. Diese Pakete wurden bei jedem Python-Aufruf ausgeführt und sammelten Cloud-Schlüssel, Repository-Token und KI-Dienstschlüssel von Build-Runnern und Entwicklerrechnern ein und erreichten rund 434.000 CI/CD-Pipelines in mehr als 2.500 Organisationen. Die erbeuteten Zugangsdaten bleiben auch nach Entfernung der Pakete gültig.
Der Schadcode lief bei jedem Python-Aufruf und nicht erst beim Import, benötigte also keine Anwendung, die die Bibliothek tatsächlich nutzt. Er wurde überall dort ausgeführt, wo das Paket landete: auf Build-Runnern, in Container-Images, in kurzlebigen Job-Containern, auf Entwicklerlaptops, in zwischengespeicherten Layern. Er sammelte alle Zugangsdaten ein, die dieser Prozess erreichen konnte.
Der von CloudSEK rekonstruierte Expositionsdatensatz ordnet dem betroffenen Pfad mehr als 2.500 Organisationen und rund 434.000 CI/CD-Pipeline-Läufe zu. Das Unternehmen weist ausdrücklich darauf hin, dass eine Übereinstimmung mit hoher Konfidenz ein Beleg für Exposition ist und kein Nachweis dafür, dass eine bestimmte Organisation kompromittiert wurde oder Daten abgeflossen sind. Diese Unterscheidung sollten Sie in einem Vorstandsbriefing erhalten.
Die vierzig Minuten sind die irreführende Zahl
Ein kurzes Veröffentlichungsfenster begrenzt, wie viele Builds das Paket gezogen haben. Es begrenzt in keiner Weise die Nutzungsdauer der erbeuteten Zugangsdaten. Das FBI warnt in seiner FLASH-Meldung vom Juli 2026 (FLASH-20260702-01), dass mit der Kampagne verbundene Akteure erbeutete Zugangsdaten voraussichtlich lange nach dem ursprünglichen Eindringen einsetzen werden.
Die Eindämmungsfrage lautet daher weniger, ob Sie LiteLLM 1.82.7 im Vierzig-Minuten-Fenster installiert haben, sondern welche Zugangsdaten für einen beliebigen Prozess auf einem Runner lesbar waren, der diesen Abhängigkeitspfad berührt hat, und ob jedes einzelne davon rotiert wurde. Das sind sehr unterschiedliche Untersuchungen, und nur die zweite beendet die Exposition.
Warum das ein CRA-Thema ist und nicht nur ein Thema der Vorfallsbearbeitung
Wenn Ihre Organisation Software ausschliesslich einsetzt, ist die LiteLLM-Kette ein Sicherheitsvorfall und möglicherweise ein NIS2-Thema. Wenn Ihre Organisation Software ausliefert, einschliesslich Software, die Sie verkaufen, einbetten, lizenzieren oder als Teil eines vernetzten Produkts vertreiben, ist es zusätzlich eine Meldepflicht mit laufender Uhr.
Hersteller im Sinne des CRA ist, wer ein Produkt mit digitalen Elementen entwickelt und unter eigenem Namen oder eigener Marke auf dem EU-Markt bereitstellt. Die Unternehmensgrösse spielt keine Rolle. Wer selbst entwickelt und verkauft, ist Hersteller, und das ist die Rolle mit den weitreichendsten Pflichten. Reines browserbasiertes SaaS fällt in der Regel nicht unter den CRA, sondern unter NIS2, doch die Grenze verläuft enger, als viele Teams annehmen, sobald ein Agent, ein SDK, ein Plug-in, eine mobile App oder Firmware ausgeliefert wird.
Hinzu kommt eine Pflicht in Richtung Vorlieferant, die genau auf die LiteLLM-Kette passt: Ein Hersteller, der eine Schwachstelle in einer integrierten Drittkomponente feststellt, muss die Stelle benachrichtigen, die diese Komponente pflegt. In einer dreistufigen Kette kann diejenige Organisation, die die Kompromittierung am ehesten bemerkt, vier Abhängigkeiten weiter unten sitzen.
Was die einzelnen Regelwerke verlangen, und wie schnell
Regelwerk: CRA, Art. 14
Regelwerk: NIS2, Art. 23
Regelwerk: DORA, Art. 19
Regelwerk: DSGVO, Art. 33
Die Überschneidung ist die operative Falle. Ein einziger Vorfall mit Abgriff von Zugangsdaten in einer Build-Pipeline kann plausibel drei dieser vier Pflichten gleichzeitig auslösen, mit drei verschiedenen Fristen, gegenüber drei verschiedenen Stellen und mit drei verschiedenen Schweregraddefinitionen. Wer die CRA-Meldung als eigenständigen neuen Prozess behandelt, wird Fristen reissen, während Organisationen, die ein bestehendes Verfahren zur Vorfallseinstufung und Meldung erweitern, das nicht tun.
Expertensicht: Alexis Hirschhorn
Das Problem liegt fast immer vor der Meldevorlage, nämlich in der Einstufung, die sie speist. Teams, die bereits einen disziplinierten Einstufungsprozess nach ISO/IEC 27035 fahren, nehmen Artikel 14 als einen weiteren Meldeweg auf, während Teams ohne einen solchen Prozess am ersten Tag feststellen, dass niemand binnen 24 Stunden sagen kann, ob eine Schwachstelle aktiv ausgenutzt wird. Diese Beurteilung ist die eigentliche Pflicht.
Die 24-Stunden-Uhr beginnt mit der Kenntniserlangung und nicht mit dem Abschluss der Untersuchung. Gestalten Sie den Prozess deshalb so, dass dieser Zeitpunkt definiert, protokolliert und verantwortet ist, sonst rekonstruieren Sie ihn im Nachhinein vor einer Behörde.
Die SBOM, die Sie formal erst 2027 brauchen und faktisch im September
Anhang I, Teil II, Nummer 1 des CRA verlangt von Herstellern, die Komponenten ihrer Produkte zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Diese Anforderung gilt ab Dezember 2027.
Die Pflicht ab September 2026 macht sie faktisch bereits 2026 erforderlich. Artikel 14 verlangt, eine aktiv ausgenutzte Schwachstelle mit Auswirkung auf Ihr Produkt binnen 24 Stunden nach Kenntniserlangung zu melden. Wenn eine Kompromittierung in einer Bibliothek drei Ebenen tief im Abhängigkeitsbaum auftaucht, lässt sich die Frage, welche Produkte und welche Versionen diese Komponente enthalten, in diesem Zeitfenster nur beantworten, wenn sie vorher beantwortet wurde.
Abhängigkeiten der obersten Ebene sind die genannte Untergrenze, kein sicheres Ziel. Die LiteLLM-Kette wäre in einer SBOM eines nachgelagerten Produkts, die nur die oberste Ebene erfasst, unsichtbar geblieben: Trivy war Build-Werkzeug und keine Anwendungsabhängigkeit, und LiteLLM selbst kann transitiv eingebunden gewesen sein. Wenn Ihr Inventar bei direkten Abhängigkeiten endet, beantwortet es die Frage der Verordnung nicht.
SBOM
Ein maschinenlesbares Verzeichnis der Komponenten einer Software mit Versions- und Lieferanteninformationen. CycloneDX und SPDX sind die beiden gebräuchlichen Formate. Die Technische Richtlinie BSI TR-03183-2 legt eine detaillierte technische Auslegung der CRA-Erwartungen fest und ist derzeit die konkreteste verfügbare Vorgabe.
Vier Lücken, an denen SBOM-Abdeckung in der Praxis scheitert
Build-Werkzeuge stehen nicht in der SBOM. Scanner, Linter, Formatierer, Test-Frameworks und Release-Automatisierung laufen mit Pipeline-Berechtigungen und werden in Abhängigkeitsinventaren üblicherweise vollständig ausgeklammert. Genau diese Lücke hat TeamPCP genutzt.
Die SBOM beschreibt das Release, nicht die Build-Umgebung. Zwei Artefakte mit identischer Stückliste können aus Pipelines mit sehr unterschiedlicher Exposition stammen, weil die Kompromittierung in der Umgebung und nicht im ausgelieferten Code lag.
Caches und Basis-Images weichen vom Manifest ab. Eine gepinnte Abhängigkeit in einer Lockdatei ist nicht dasselbe wie eine gepinnte Abhängigkeit in dem Layer, der tatsächlich ausgeführt wurde, sobald Basis-Images, kurzlebige Runner und warme Caches im Spiel sind.
Niemand verantwortet die Aktualität. Eine SBOM, die beim Release erzeugt und nie neu erzeugt wird, beantwortet eine Frage über die Vergangenheit. Die 24-Stunden-Uhr stellt eine Frage über die Gegenwart.
Anwendungsbereich: drei Fragen, die ihn klären
Stellen Sie ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke auf dem EU-Markt bereit? Wenn ja, sind Sie Hersteller, und Artikel 14 gilt für Sie ab dem 11. September 2026, auch für bereits verkaufte Produkte.
Ist das Produkt an oder nach diesem Datum weiterhin auf dem EU-Markt? Bestandsprodukte fallen unter die Meldepflicht. Die weitergehenden grundlegenden Anforderungen erreichen Bestandsprodukte erst bei einer wesentlichen Änderung ab Dezember 2027.
Liegt es tatsächlich ausserhalb des Anwendungsbereichs? Reines browserbasiertes SaaS fällt in der Regel nicht unter den CRA, und nicht-kommerzielle Open Source ist ausgenommen, wobei der CRA die abgeschwächte Rolle des Open-Source-Software-Verwalters schafft statt eines pauschalen Ausschlusses und die kommerzielle Bereitstellung von Open-Source-Komponenten Sie wieder in den Anwendungsbereich zieht. Ausserhalb des CRA zu liegen bedeutet meist, innerhalb von NIS2 zu liegen, daher führt dieser Weg selten dazu, gar keine Pflicht zu haben.
Sanktionen
Verstösse gegen die grundlegenden Anforderungen oder die Herstellerpflichten werden mit Bussgeldern von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet, je nachdem, welcher Betrag höher ist.
Die Uhr nach Artikel 14, von Anfang bis Ende
Die Meldung geht an das als Koordinator benannte CSIRT in dem Mitgliedstaat, in dem Sie Ihre Hauptniederlassung haben, und wird der ENISA gleichzeitig zugänglich gemacht. Sie melden einmal über die Single Reporting Platform und nicht getrennt an jede Stelle.
Beachten Sie, was Artikel 14 nicht verlangt. Es ist keine Pflicht, jede CVE zu melden. Erfasst sind Schwachstellen, die aktiv ausgenutzt werden, sowie schwerwiegende Vorfälle mit Auswirkung auf die Produktsicherheit. Der CRA selbst verlangt auch keine Benachrichtigung von Geschäftskunden, prüfen Sie jedoch Ihre Verträge, denn Kunden schreiben genau das zunehmend vertraglich vor, mit knapperen Fristen als die Verordnung.
Behebung ist nicht Teil der September-Pflicht
Die Pflicht zur Behebung und zur Bereitstellung von Sicherheitsupdates über den Unterstützungszeitraum gilt ab dem 11. Dezember 2027. Ab September 2026 müssen Sie melden, und eine Schwachstelle zu melden, die Sie noch nicht beheben können, ist der Regelfall. Verzögern Sie eine Meldung nicht, während Sie auf einen Patch warten.
Wo der CRA auf NIS2 und die Lieferkette trifft
Artikel 21 Absatz 2 Buchstabe d NIS2 verpflichtet wesentliche und wichtige Einrichtungen bereits heute zu Massnahmen für die Sicherheit der Lieferkette, einschliesslich der sicherheitsbezogenen Aspekte der Beziehungen zu unmittelbaren Anbietern und Dienstleistern. Der CRA nähert sich demselben Risiko von der anderen Seite: Er regelt, was diese Anbieter bauen und offenlegen müssen.
Für die meisten Organisationen gilt beides, in unterschiedlichen Rollen. Sie sind eine NIS2-Einrichtung, die ihre Lieferanten steuert, und ein CRA-Hersteller, der von seinen Kunden gesteuert wird. Die Nachweise überschneiden sich weitgehend: ein Komponenteninventar, ein Verfahren zur Lieferantenbewertung, ein Verfahren zum Umgang mit Schwachstellen und ein Meldehandbuch, vorausgesetzt, es wurde einmal entworfen und nicht dreimal.
Hier zeigt ISO 28000 seinen Wert. Die Norm liefert ein Managementsystem für Sicherheit in der Lieferkette, also genau die Struktur, die den meisten Organisationen fehlt, wenn sie Lieferantenrisikofragen über Einkauf, Entwicklung und Compliance hinweg einheitlich beantworten wollen. Die Alternative, eine Tabelle mit Lieferantenfragebögen, überlebt eine Kette wie LiteLLM nicht, weil die kompromittierte Partei nie ein bewerteter Lieferant war.
Von der Pflicht zur Fähigkeit, und von der Fähigkeit zur Zertifizierung
Pflicht: Einstufen und in 24 Std. melden
Pflicht: Die eigenen Komponenten kennen
Pflicht: Lieferanten- und Komponentenrisiko steuern
Pflicht: NIS2 Art. 21 Abs. 2 Buchst. d erfüllen
Pflicht: Das Programm gesamthaft verantworten
Ein 30-Tage-Plan zur Vorbereitung
Das realistische Ziel vor dem 11. September ist nicht die vollständige CRA-Konformität. Es geht darum, fristgerecht eine belastbare Meldung abgeben zu können. Das ist ein deutlich kleinerer Umfang, und er ist in der verbleibenden Zeit erreichbar.
- Klären, ob Sie Hersteller im Sinne des CRA sind, und alle Produkte auflisten, die weiterhin auf dem EU-Markt sind und in den Anwendungsbereich fallen
- Das zuständige CSIRT im Mitgliedstaat Ihrer Hauptniederlassung ermitteln und sich für die Single Reporting Platform registrieren
- Den Zeitpunkt der Kenntniserlangung definieren und dokumentieren: wer ihn feststellen darf, wie er protokolliert wird und was die 24-Stunden-Uhr startet
- Eine namentlich benannte verantwortliche Person und eine Vertretung für die Meldung festlegen, mit Erreichbarkeit ausserhalb der Geschäftszeiten
- Für jedes Produkt im Anwendungsbereich eine SBOM in CycloneDX oder SPDX erzeugen und dabei Build-Werkzeuge ebenso erfassen wie Anwendungsabhängigkeiten
- Die SBOM mit einer Schwachstellenquelle verknüpfen, sodass die Frage, welche Produkte Komponente X enthalten, in Minuten beantwortbar ist
- Die Einstufungsregel formulieren, die eine aktiv ausgenutzte Schwachstelle von einer gewöhnlichen CVE unterscheidet, und sie an einem realen Fall erproben
- Die CRA-Meldung auf die bestehenden Melde- und Vorfallswege für NIS2, DORA und DSGVO abbilden, damit ein Ereignis nicht drei unkoordinierte Prozesse auslöst
- Den Meldeweg gegenüber Vorlieferanten für Schwachstellen in Drittkomponenten einrichten
- Eine Planbesprechung mit der LiteLLM-Kette als Szenario durchführen und die eigene Zeit bis zur 24-Stunden-Marke messen
Die Planbesprechung ist der Schritt, den Teams überspringen, und derjenige, der die echten Lücken findet. Führen Sie sie mit dem Szenario durch, wie es tatsächlich eintritt: Eine öffentliche Meldung nennt ein Paket, das Ihre Build-Pipeline verwendet, Sie wissen noch nicht, ob es die Produktion erreicht hat, und die Uhr läuft bereits.
Beginnen Sie beim Zugangsdaten-Inventar, nicht beim Abhängigkeitsinventar
Bei dieser Angriffsklasse bestimmt sich die Exposition danach, was ein kompromittierter Prozess lesen konnte, und nicht danach, was importiert wurde. Erfassen Sie, welche Zugangsdaten von jedem Build-Runner aus erreichbar sind: Cloud-Schlüssel, Registry-Token, Quellcode-Token, Modell- und API-Schlüssel und alles, was über einen Instanz-Metadatendienst abrufbar ist. Diese Liste ist zugleich Ihr Untersuchungsumfang und Ihre wirksamste einzelne Verbesserung.
Was Sie daraus mitnehmen sollten
Trotz ihrer Darstellung in den Medien ist die LiteLLM-Kompromittierung weniger eine Geschichte über KI als über eine Build-Pipeline, die ihren eigenen Werkzeugen vertraute, über eine nicht widerrufene Zugangsberechtigung und über eine Abhängigkeitskette, die niemand kartiert hatte. Die KI-Ebene verschärfte das nur, weil KI-Gateways ungewöhnlich nah an Zugangsdaten für Cloud-Konten, Modellanbieter und Vektordatenbanken sitzen.
Was sich am 11. September 2026 ändert, ist, dass dasselbe Ereignis für jeden, der Software in die EU liefert, eine Meldepflicht binnen 24 Stunden auslöst. Die Verordnung verlangt von Ihnen, schnell zu wissen, ob die Kette Sie erreicht hat, und es zu sagen, und nicht, sie zu verhindern.
Das ist eine Frage des Komponenteninventars und der Vorfallseinstufung, lange bevor es eine regulatorische Frage ist. Organisationen, die beides bereits als Disziplin betreiben, werden Artikel 14 als kleine Ergänzung erleben. Alle anderen haben noch rund dreissig Tage.
