CRA Meldepflicht 2026: 24 Stunden für Container-Software

Constantin Budin, Plattformberater bei Pexon Consulting | 10 Min. Lesezeit | 29.09.2026

TL;DR: CRA Meldepflicht für Container-Software

Die CRA Meldepflicht gilt seit dem 11.09.2026: Hersteller melden aktiv ausgenutzte Schwachstellen binnen 24 Stunden über die ENISA-Plattform. Wer Software als Image oder Helm-Chart ausliefert, muss dafür in Stunden wissen, welche Versionen betroffen sind. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) baut dafür Stückliste, Digest-Inventar und Meldeweg.

Das Problem: Die Frist beginnt mit dem Wissen, nicht mit der Analyse

Die Uhr startet, sobald Sie von einer aktiv ausgenutzten Schwachstelle in Ihrem Produkt erfahren. Nicht, wenn das Team die Ursache gefunden hat, und nicht am nächsten Werktag. Wer an einem Freitagabend einen Hinweis bekommt, muss bis Samstagabend die Frühwarnung abgesetzt haben.

Für Hersteller klassischer Software ist das schon eng. Für Hersteller, deren Produkt aus Container-Images und Helm-Charts besteht, kommt eine zweite Frage dazu: Welche der ausgelieferten Versionen enthalten die betroffene Bibliothek überhaupt? Ein Image zieht Dutzende Pakete aus Basis-Image, Sprach-Laufzeit und Abhängigkeiten. Ohne Stückliste pro Release beginnt die Suche im Git-Log.

Die Meldepflicht ist der erste Teil des Cyber Resilience Act, der tatsächlich greift. Die übrigen Pflichten, darunter Schwachstellenmanagement über den ganzen Lebenszyklus und die Stückliste in der technischen Dokumentation, gelten ab dem 11.12.2027. Wie Sie den SBOM-Prozess für diesen zweiten Stichtag aufsetzen, beschreiben wir auf der Seite zu SBOM und CRA auf Kubernetes. Dieser Text geht auf den Meldeweg ein, der schon heute läuft.

Wen trifft die CRA Meldepflicht, und wen nicht?

Die CRA Meldepflicht trifft Hersteller von Produkten mit digitalen Elementen, die in der EU auf den Markt kommen. Dazu gehört Software, die Ihre Kunden selbst installieren, etwa als Container-Image, Helm-Chart, Operator oder Appliance mit Kubernetes darin. Die Pflicht hängt am Produkt, nicht an der Branche.

Drei Fälle, die wir in Gesprächen am häufigsten sortieren:

Die rechtliche Einstufung gehört in die Hände Ihrer Rechts- oder Compliance-Abteilung. Wir sehen aber oft, dass die Diskussion über die Einstufung Wochen dauert und die Technik für den Meldeweg in dieser Zeit liegen bleibt. Aus unserer Sicht lohnt sich der technische Teil in jedem Fall: Ein Inventar, das betroffene Versionen in Minuten findet, brauchen Sie auch für NIS2 und für jeden Kunden, der nach einer CVE fragt.

Für Open-Source-Stewards, also Organisationen, die freie Software dauerhaft für den kommerziellen Einsatz betreuen, gilt die Meldepflicht erst ab dem 11.12.2027.

Was muss in 24 Stunden, 72 Stunden und 14 Tagen raus?

Gemeldet wird über die Single Reporting Platform der ENISA, die am 11.09.2026 gestartet ist. Die Meldung geht an das CSIRT des Mitgliedstaats Ihrer Hauptniederlassung, in Deutschland an das BSI, und parallel an die ENISA. Die Pflichten stehen in Artikel 14 der Verordnung (EU) 2024/2847, die Kommission fasst sie auf ihrer Seite zu den CRA-Meldepflichten zusammen.

1. Frühwarnung nach 24 Stunden: dass eine aktiv ausgenutzte Schwachstelle vorliegt, und in welchen Mitgliedstaaten das Produkt verfügbar ist.
2. Meldung nach 72 Stunden: allgemeine Angaben zum Produkt, zur Art der Ausnutzung und zu ergriffenen oder empfohlenen Gegenmaßnahmen.
3. Abschlussbericht: bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur verfügbar ist. Bei schweren Sicherheitsvorfällen einen Monat nach der 72-Stunden-Meldung.

Zusätzlich verlangt der CRA, die betroffenen Nutzer über die Schwachstelle und mögliche Abhilfen zu informieren. Das ist der Schritt, bei dem Sie wissen müssen, welcher Kunde welche Version betreibt.

Ein Detail aus der Anleitung der ENISA: Die Registrierung als Vertreter des Herstellers wird vom zuständigen CSIRT erst im Zuge der ersten Meldung geprüft, und die ENISA rät davon ab, Konten auf Vorrat anzulegen. Die Meldung selbst wird dadurch nicht blockiert. Wir legen deshalb im Meldeplan fest, wer das EU-Login hat und wer vertritt, statt ein Konto ungenutzt liegen zu lassen.

Wie finden Sie in Stunden, welche Images betroffen sind?

Sie finden betroffene Images in Stunden, wenn zu jeder ausgelieferten Digest eine Stückliste existiert und signiert am Image hängt. Dann ist die Frage eine Abfrage über alle Stücklisten, keine Suche im Code.

Die Kette, die wir in Projekten aufbauen, hat drei Glieder. Erstens erzeugt die Pipeline bei jedem Release eine SBOM im Format CycloneDX. Zweitens hängt sie diese als signierte Attestation an die Digest in der Registry. Drittens führt ein Inventar, welche Digest in welchem Release und bei welchem Kunden läuft.

# Im Release-Job: Stückliste erzeugen und an die Digest hängen
IMAGE=registry.example.com/produkt/api@sha256:4f1c...
syft "$IMAGE" -o cyclonedx-json > sbom.cdx.json
cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$IMAGE"

# Im Vorfall: alle archivierten Stücklisten gegen die neue CVE prüfen
for f in sbom-archiv/*.cdx.json; do
  trivy sbom --quiet --severity CRITICAL,HIGH "$f" | grep -q CVE-2026-XXXXX \
    && echo "betroffen: $f"
done

Betreiben Sie das Produkt zusätzlich für Kunden in eigenen Clustern, zeigt ein Befehl, welche Digests dort tatsächlich laufen. Das ist der Abgleich zwischen dem, was Sie ausgeliefert haben, und dem, was produktiv ist:

kubectl get pods -A -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.imageID}{"\n"}{end}{end}' \
  | sort -u > laufende-digests.txt

Nicht jede CVE in einer Bibliothek macht Ihr Produkt angreifbar. Wenn die betroffene Funktion nie aufgerufen wird, dokumentieren Sie das in einem VEX-Dokument als nicht betroffen. Trivy liest solche Aussagen mit --vex ein, und die nächste Kundenanfrage beantwortet sich damit selbst. Wie der Scanner im Cluster eingebunden wird, beschreibt unsere Seite zu Trivy im Kubernetes-Cluster.

Wer meldet, wer entscheidet, wer liefert den Fix?

Die Technik findet die Version. Die Meldung braucht Menschen mit klaren Rollen, und zwar auch nachts und am Wochenende. Ohne Rollen scheitert die 24-Stunden-Frist nicht an der Analyse, sondern an der Frage, wer die Meldung absenden darf.

Diese Rollen legen wir in einem Meldeplan fest, bevor der erste Fall eintritt:

Wir raten dazu, den Plan einmal mit einer fiktiven CVE durchzuspielen, mit Uhr. Der Test dauert einen halben Tag und zeigt zuverlässig, wo die Kette reißt. Meist fehlt nicht die Technik, sondern die Vertretung für die Person mit dem Login.

Wer die Meldung schon jetzt mit NIS2-Pflichten zusammenlegen muss, findet die Betriebsseite auf unserer Seite zum NIS2 Cluster Nachweis.

Häufig gestellte Fragen

Seit wann gilt die CRA Meldepflicht?

Seit dem 11.09.2026 für Hersteller von Produkten mit digitalen Elementen. Gemeldet werden aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die Single Reporting Platform der ENISA. Die übrigen Pflichten des Cyber Resilience Act gelten ab dem 11.12.2027.

Fällt SaaS unter die CRA Meldepflicht?

Reines SaaS, das Sie selbst betreiben, fällt nach unserem Verständnis in der Regel unter NIS2 statt unter den CRA. Software, die Kunden als Image, Helm-Chart oder Appliance installieren, ist ein Produkt mit digitalen Elementen. Die verbindliche Einstufung klären Sie mit Ihrer Rechtsabteilung.

Muss ich jede CVE in einem Container-Image melden?

Nein. Meldepflichtig sind aktiv ausgenutzte Schwachstellen in Ihrem Produkt, nicht jede bekannte CVE in einer Abhängigkeit. Ist eine Schwachstelle in Ihrem Produkt nicht ausnutzbar, halten Sie das in einem VEX-Dokument fest.

Was kostet es, den Meldeweg für Container-Software aufzubauen?

Die Werkzeuge Syft, Cosign und Trivy sind Open Source. Der Aufwand steckt in der Pipeline-Anbindung, im Archiv der Stücklisten und im Meldeplan mit Rollen. Den Umfang für Ihre Release-Kette schätzen wir im unverbindlichen 45-Minuten-Cluster-Check.

Brauche ich für die Meldepflicht schon eine vollständige SBOM?

Rechtlich wird die Stückliste in der technischen Dokumentation erst ab dem 11.12.2027 verlangt. Praktisch ist sie der schnellste Weg, in 24 Stunden die betroffenen Versionen zu kennen. Wer sie jetzt aufbaut, erfüllt 2027 einen Teil der Dokumentation nebenbei.

Nächster Schritt

Verwandte Themen