Cyber Resilience Act: ab jetzt 24 Stunden Meldefrist

Für Unternehmen, die Software auf dem EU-Markt bereitstellen, gilt ab dem 11. September 2026 eine neue Frist: 24 Stunden, um eine Meldung einzureichen, sobald bekannt wird, dass eine Schwachstelle in einem ihrer Produkte aktiv ausgenutzt wird. Diese Anforderung stammt aus dem Cyber Resilience Act (CRA), dem EU-Gesetz für Cybersicherheitsanforderungen an Produkte mit digitalen Elementen, die in Europa verkauft werden. Es soll sicherstellen, dass diese Produkte von Grund auf sicher gestaltet sind und gegen neue Bedrohungen abgesichert bleiben. Die strengsten Anforderungen des CRA gelten für die Hersteller dieser Produkte, von großen Softwareanbietern bis zu Unternehmen, die vernetzte Hardware ausliefern.

Die eigentliche Herausforderung ist nicht die Meldung selbst, sondern das rechtzeitige Erkennen: Wird gerade eine Schwachstelle im eigenen Produkt aktiv ausgenutzt? Die 24-Stunden-Frist beginnt in dem Moment der Kenntniserlangung. Genau deshalb ist Erkennung so wichtig. Kontinuierliche Erkennung ist eine technische Lösung, kein einmaliger Compliance-Akt. Die Funktionen von GitLab für Software Supply Chain Security helfen dabei, aktive Ausnutzung im eigenen ausgelieferten Code automatisch und kontinuierlich zu erkennen. Dieser Beitrag geht vier Fragen durch, die sich zur kontinuierlichen Erkennung in der eigenen Pipeline schon heute stellen lassen.

Meldepflicht startet im September 2026

Ab dem 11. September 2026 müssen Hersteller eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Kenntniserlangung melden. Die Meldung läuft in drei Stufen, die jeweils gleichzeitig an die Agentur der Europäischen Union für Cybersicherheit (ENISA) und an das Computer Security Incident Response Team (CSIRT), das als Koordinator benannt ist, übermittelt werden.

1. Frühwarnung, innerhalb von 24 Stunden nach Kenntniserlangung von der aktiv ausgenutzten Schwachstelle. Eine kurze erste Meldung, dass eine Ausnutzung stattfindet. Der volle Umfang der Auswirkungen oder eine Lösung muss zu diesem Zeitpunkt noch nicht bekannt sein.
2. Meldung, innerhalb von 72 Stunden. Ein ausführlicherer Bericht darüber, was betroffen ist, was bislang bekannt ist und welche Maßnahmen ergriffen werden.
3. Abschlussbericht. Bei einer aktiv ausgenutzten Schwachstelle spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist.

Vier Fragen zur Vorbereitung mit GitLab

Ob eine Schwachstelle im eigenen Produkt meldepflichtig ist, muss jedes Unternehmen selbst entscheiden. Die folgenden vier Fragen lassen sich schon heute zur Vorbereitung auf den CRA stellen, jeweils mit einem Blick darauf, wie GitLab bei der Antwort hilft.

Aktive Ausnutzung im bereits Ausgelieferten erkennen

Wird gerade eine Komponente in etwas, das ich ausgeliefert habe, aktiv ausgenutzt?

Continuous Dependency Scanning überwacht die eigene SBOM und gleicht sie mit neu veröffentlichten Advisories ab. KEV-Status und EPSS-Werte zu jedem Fund zeigen, welche davon tatsächlich von Angreifern genutzt werden, sodass sich die Schwachstellen mit echtem Risiko priorisieren lassen. Container Scanning deckt die ausgelieferten Images ab, Operational Container Scanning das, was aktuell in den eigenen Clustern läuft.

Jedes betroffene Produkt und Repository finden

Welche meiner Produkte sind betroffen, und in welchem Repository?

Eine einzige Suche in der gruppenweiten Abhängigkeitsliste liefert jedes Projekt, das diese Komponente ausliefert. Sicherheitsattribute zeigen, welche davon internetexponiert oder geschäftskritisch sind, damit klar ist, wo zuerst anzusetzen ist. Diese Liste speist sich aus zwei Quellen: einer CycloneDX-SBOM aus Dependency Scanning für das, was der eigene Code deklariert, einschließlich transitiver Abhängigkeiten, sowie einer weiteren aus Container Scanning für die im Image enthaltenen Betriebssystempakete. Eine einzige Suche erreicht die gesamte eigene Software-Lieferkette – alles, was tatsächlich ausgeliefert wurde.

Erkennungszeitpunkt dokumentieren

Lässt sich zeigen, wann ich davon erfahren habe?

Das Aktivitätsprotokoll zu jeder Schwachstelle hält fest: wann sie erkannt wurde, in welcher Pipeline, und jede folgende Statusänderung mit Person und Zeitpunkt. Der Vulnerability-Events-Webhook spielt genau diese Momente in das jeweilige System ein, das die eigene Frist im Blick behält. Fragt jemand, wann man davon erfahren hat, liegt die Antwort bereits vor.

Fix-Auslieferung und Zeitpunkt zeigen

Wurde ein Fix ausgeliefert, und wann?

Dependency scanning auto-remediation öffnet automatisch den Merge Request für das Upgrade. Merge request approval policies können auf den Known-Exploited-Status prüfen, sodass die Regel gilt, ohne dass sie jedes Mal neu verhandelt werden muss. Compliance frameworks legen die dahinterliegenden Kontrollen fest. Der Compliance Status Report zeigt, wo jedes Projekt im Verhältnis dazu steht, und der Compliance Violations Report erfasst alles, was durchgerutscht ist.

Alles andere läuft bereits

Ein Großteil der Informationen, die zur Einschätzung der Meldepflichten nach dem CRA nötig sind, ist bereits in der GitLab-Plattform vorhanden, in der der eigene Code liegt. Das Inventar, die Ausnutzungssignale, der kontinuierliche Abgleich, die Zeitstempel und die Policy-Gates sind keine fünf separaten Tools, die bewertet, gekauft und miteinander verkabelt werden müssen. Es sind Funktionen, die sich in den bereits laufenden Pipelines aktivieren lassen, ohne neue Agents und ohne neue Datenebene.

Für die Beantwortung dieser vier Fragen werden GitLabs Sicherheits-Scans möglicherweise nicht gebraucht – Static Application Security Testing (SAST), Secret Detection, Secret Push Protection, Infrastructure-as-Code (IaC) Scanning und Security Policies. Sie helfen aber dabei, die nächste Phase der CRA-Anforderungen anzugehen, die im Dezember 2027 in Kraft tritt.

Blick nach vorn: riskante Pakete vor dem Eintritt in die Lieferkette stoppen

Die Sicherheitsfunktionen von GitLab helfen bei einer schnellen Reaktion. Es lohnt sich außerdem, die eigene Umgebung so aufzustellen, dass von vornherein weniger Schwachstellen zu melden sind.

Nicht jedes Lieferkettenrisiko taucht als CVE-Eintrag auf (Common Vulnerabilities and Exposures). Ein Paket, das nur ein Zeichen von einer täglich verwendeten Bibliothek entfernt veröffentlicht wird, erhält weder ein Advisory noch einen Schweregrad, ebenso wenig ein Paketname, den ein KI-Assistent erfunden hat und den jemand anderes dann registriert hat. Hier gibt es nichts zu patchen, denn das Paket selbst ist der Angriff.

Bald ermöglicht GitLab es, eine präventive Policy direkt an der Registry anzuwenden – statt eine Schwachstelle erst drei Wochen später in einem Review zu entdecken. So lassen sich schädliche Pakete stoppen, bevor sie überhaupt in die Lieferkette gelangen, noch vor einem Build. Informationen zur bald startenden Closed Beta der Dependency Firewall gibt es über dieses Formular.

Für bestehende GitLab-Kund(inn)en: an einer einzelnen Komponente ausprobieren. Die gruppenweite Abhängigkeitsliste öffnen, eine bekanntermaßen ausgelieferte Komponente auswählen und die Zeit stoppen, die für die Beantwortung aller vier Fragen nötig ist. Fallen die Antworten leicht, lässt sich Continuous Dependency Scanning aktivieren und der Known-Exploited-Status einer Merge Request Approval Policy hinzufügen.

Noch nicht auf GitLab Ultimate? In einer einzigen Ansicht zeigt sich, ob ausgelieferte Komponenten bekanntermaßen in freier Wildbahn ausgenutzte Schwachstellen tragen. Kostenlose Testversion starten.

Weiterführende Informationen: der Überblick der Europäischen Kommission zum Cyber Resilience Act, die Seite zu den Meldepflichten, die Zusammenfassung des Gesetzestexts sowie die Umsetzungsleitlinien der Kommission.

Amit Shalem ist Principal Product Manager, Software Supply Chain Security, bei GitLab.