ENISA zu Frontier-KI: 5 Folgen für CRA-Hersteller

Im Januar 2026 hat curl sein Programm zur koordinierten Offenlegung von Schwachstellen eingestellt. KI-generierte Berichte hatten die Maintainer überrollt, und das Projekt entschied: Die Bearbeitung kostete mehr, als sie einbrachte. ENISA zitiert diese Einstellung jetzt in einer offiziellen Publikation. Der Teil, der für Sie zählt: Ein CRA-Hersteller kann diese Entscheidung nicht treffen. Der Cyber Resilience Act macht die Annahme von Schwachstellenmeldungen ab dem 11. Dezember 2027 zur gesetzlichen Pflicht. curl hatte einen Ausweg. Sie haben keinen.

Das ist eine von fünf Kollisionen zwischen ENISAs neuem Positionspapier und Ihren CRA-Pflichten. ENISA veröffentlichte im Juli 2026 seine Sicht auf Cybersicherheit im Zeitalter der Frontier-KI. Die 16 Seiten richten sich an nationale Behörden, EU-Politik, Verteidiger und Diensteanbieter. Kein einziger Abschnitt ist für Produkthersteller geschrieben. Die Folgen landen trotzdem auf Ihrem Tisch.

Was ENISA tatsächlich veröffentlicht hat

Das Papier ist eine 16-seitige Positionsnotiz, entwickelt gemeinsam mit dem EU-CSIRTs-Netzwerk und EU-CyCLONe zwischen Mai und Juni 2026. Der rechtliche Hinweis stellt klar: Es begründet keine regulatorische Pflicht. Verstehen Sie es als Signal dafür, wohin ENISAs operative Leitlinien sich entwickeln, und lesen Sie es neben den CRA-Pflichten, die für Sie bereits bindend sind.

Die Kernaussage ist messbar. Das Zeitfenster zwischen Entdeckung und Ausnutzung einer Schwachstelle ist von Jahren über Monate auf Minuten geschrumpft. Daten, die ENISA zitiert, setzen die Bewaffnung auf 15 Minuten nach der Offenlegung und die mediane Exfiltration auf 72 Minuten nach dem Erstzugriff. NCSC-NL ergänzt: Autonome Agenten nehmen Verteidigern den Vorteil der privaten Entdeckung. Findet ein KI-Agent eine Schwachstelle, ist der Bau des Exploits eine Berechnung, kein Ingenieursprojekt. Manche Exploits existieren inzwischen vor dem Fix, was das Papier als negative Time-to-Exploit bezeichnet.

ENISA ist offen über die andere Seite der Gleichung. Das Papier hält fest: ENISAs eigene Kapazität, ebenso wie die von Herstellern und nationalen CSIRTs, muss verstärkt oder überdacht werden, um die kommende Welle entdeckter Schwachstellen zu bewältigen. Die Behörde, die für die Single Reporting Platform zuständig ist, schreibt es schwarz auf weiß: Die Volumina werden alle an ihre Grenzen bringen.

Die fünf Abschnitte unten greifen je einen Befund aus dem Papier auf und verfolgen ihn bis zu einer CRA-Pflicht.

1. curl hat seine Schwachstellenannahme geschlossen. Sie können das nicht

Anfang 2026 begannen KI-generierte Schwachstellenberichte, Teile der Open-Source-Offenlegungspipeline zu überfluten. Das Papier benennt den Schaden konkret: Eine globale Bug-Bounty-Plattform pausierte neue Einreichungen im Internet Bug Bounty, nachdem eine Flut KI-unterstützter Berichte unterschiedlicher Qualität eintraf, und curl beendete sein CVD-Programm im Januar 2026, weil die Maintainer das Volumen und das Rauschen nicht mehr bewältigen konnten. Das Problem ist Signalverdünnung. Menschliche Prüfer verbringen ihre Zeit damit, echte Funde von sich wiederholenden, oberflächlichen oder unbestätigten Einreichungen zu trennen.

Ein Open-Source-Projekt kann die Tür schließen. Unter dem CRA können Sie das nicht. Die Verordnung verlangt von Ihnen, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen zu betreiben und durchzusetzen, sowie eine Kontaktadresse für Schwachstellenmeldungen zu Ihrem Produkt zu veröffentlichen. Beide Pflichten gelten ab dem 11. Dezember 2027. Die unbequeme Wahrheit: Der CRA wurde unter der Annahme geschrieben, dass Berichte selten und wertvoll sind. Das Papier dokumentiert eine Welt, in der sie zu Hunderten eintreffen, maschinell geschrieben und unbestätigt. Die Pflicht bleibt. Die Annahme dahinter ist verschwunden.

Ihre CVD-Richtlinie braucht deshalb eine Klausel für das KI-Zeitalter. Drei Dinge gehören hinein:

• Validierungsanforderungen: Legen Sie fest, was ein Bericht enthalten muss, um in die Triage aufgenommen zu werden. Betroffenes Produkt und Version, Reproduktionsschritte oder ein Proof of Concept, sowie die beobachtete Auswirkung. Ein Bericht ohne diese Angaben erhält eine Nachforderung, keinen Triage-Platz.
• Deduplizierung vor der Triage: KI-Werkzeuge reichen dieselbe Schwachstelle in vielen Formulierungen erneut ein. Clustern Sie eingehende Berichte zuerst gegen Ihre bekannten Funde, und zählen Sie Cluster, nicht E-Mails.
• Triage-Zusagen nach Schweregrad: Veröffentlichen Sie Reaktionszeiten, die Sie auch beim Zehnfachen des heutigen Volumens einhalten können. Eine Eingangsbestätigungs-SLA, die Sie jede Woche brechen, ist ein schlechterer Nachweis als eine bescheidene, die Sie einhalten.

Eine weitere Nuance aus dem Papier: ENISA stellt fest, dass die Qualität von KI-Berichten in den letzten Monaten spürbar gestiegen ist. Eine pauschale Regel „keine KI-Berichte" verwirft deshalb echtes Signal. Filtern Sie nach Vollständigkeit und Reproduzierbarkeit, nicht nach Urheberschaft. Die Annahmemechanik über security.txt zu veröffentlichen, hält die Kontaktpunkt-Pflicht prüfbar.

2. KI bläht auf, was „bekannt ausnutzbar“ bedeutet

Das Papier enthält eine Zahl, die das Release-Engineering verändert. Eine Branchenorganisation berichtete ENISA, sie sei von rund 80 CVEs im ersten Quartal 2025 auf fast 500 im ersten Quartal 2026 gestiegen, und dann auf etwa 500 pro Tag, sobald sie Frontier-KI-fähige Werkzeuge einsetzte. ENISA nennt das die wirtschaftliche Entwertung der Entdeckung: Das Auffinden von Schwachstellen wird industrialisiert, wodurch das Offenlegungsvolumen schneller wächst, als irgendjemand beheben kann.

Der CRA verbietet das Inverkehrbringen eines Produkts mit bekannten ausnutzbaren Schwachstellen. Zwei Wörter tragen diese Regel. KI erweitert bekannt mechanisch: Jeder Scanner-Lauf gegen Ihre SBOM fördert mehr Funde zutage, jedes Quartal. Was KI nicht ändert, ist ausnutzbar, und genau dort liegt jetzt Ihr Compliance-Nachweis. Die Arbeit der Schweregradbewertung, inhärenten Schweregrad von Ausnutzungswahrscheinlichkeit zu trennen, ist keine Optimierung mehr, sie wird selbst zum Release-Gate.

Der Verkettungspunkt wirkt in beide Richtungen. ENISA warnt, dass Schwachstellen mit niedrigem Risiko nicht mehr als harmlos abgetan werden können, weil Modelle sie zu funktionierenden Exploits verketten. Damit ist „niedriger CVSS, ignorieren" als Triage-Regel tot. Aber ein reines CVE-Zahlen-Gate in der CI stirbt ebenfalls: Bei 500 Funden am Tag blockiert es jedes Release für immer. Was überlebt, ist dokumentierte Ausnutzbarkeit pro Fund. Das Papier nennt die zwei Instrumente: EPSS von FIRST für die Ausnutzungswahrscheinlichkeit, und VEX, um festzuhalten, ob Ihr Produkt überhaupt betroffen ist.

3. Jeder Patch, den Sie ausliefern, kartiert die Lücke in Ihren älteren Versionen

Der Abschnitt des Papiers zur N-Day-Bewaffnung hält fest, dass Patch-Diffs und Binär-Änderungen historisch das Reverse Engineering und die Exploit-Entwicklung genährt haben, und dass sich das Ausnutzungsfenster bereits vor der Patch-Verteilung öffnet. Frontier-KI verdichtet dieses Reverse Engineering von Tagen an Spezialistenarbeit auf eine Berechnung. Das Papier merkt zudem an, dass KI-gestützte Analyse das Codeverständnis von Altsystemen beschleunigt.

Setzen Sie jetzt Ihre eigene Produktlinie in dieses Bild. Sie veröffentlichen einen Sicherheitsfix für Version N. Der Diff beschreibt die Schwachstelle präzise. Teilt Version N-1 den betroffenen Code und liegt sie bereits nach ihrem Support-Ende, ist Ihr eigener Patch die beste verfügbare Ausnutzungsanleitung gegen Ihre eigene installierte Basis. In menschlicher Geschwindigkeit war das ein bekanntes, aber langsames Risiko. In Maschinengeschwindigkeit passiert es am selben Tag.

Das verändert die Bedeutung zweier CRA-Entscheidungen:

• Der Supportzeitraum, in den meisten Fällen mindestens fünf Jahre, legt fest, welche Versionen noch Fixes erhalten. Versionen außerhalb davon verschwinden nicht aus dem Feld. Sie bleiben erreichbar, und jeder Fix, den Sie für unterstützte Versionen veröffentlichen, lehrt Angreifer etwas über sie. Versionswildwuchs ist jetzt Angriffsfläche, deshalb schlagen wenige, langlebige unterstützte Versionen viele kurzlebige. Wie die Dauer festgelegt wird, lesen Sie unter Supportzeitraum.
• Die Offenlegung zum Support-Ende, die Sie Käufern vor dem Kauf schulden, wird zur operativen Information, nicht zum Papierkram im Regal. Ein Käufer, der über das von Ihnen offengelegte Datum hinaus weiterläuft, betreibt ein Produkt, das Ihr eigener Patch-Strom Angreifern beschreibt. Sagen Sie das in der Offenlegung. Wo das Datum erscheinen muss, behandelt die Seite Offenlegung zum Support-Ende.

Der Rat von NCSC Ireland im Papier ist unverblümt: Bestandsverzeichnisse prüfen, Patch-Disziplin priorisieren, und die Exposition gegenüber nicht mehr unterstützten Komponenten bewerten. Für einen Hersteller lautet die spiegelbildliche Pflicht: die Lücke zwischen „gepatchtem Branch" und „aufgegebenem Branch" nicht still weiter wachsen lassen.

4. KI-geschriebene Patches laufen weiterhin unter Ihrer CE-Kennzeichnung

ENISA erwartet, dass die Behebung dieselben Werkzeuge übernimmt wie die Entdeckung. Der Verifikations-Engpass im Papier ist die Folge: Technische Teams stehen vor einer Skalierungsherausforderung, KI-generierte Patches zu prüfen und zu validieren, damit sie keine neuen Schwachstellen in die Codebasis einbringen. Das Papier beschreibt zudem den Druck auf der anderen Seite, eine Autoritätslücke, in der menschliche Change-Boards Eingriffe nicht in den wenigen Minuten autorisieren können, die zur Abwehr autonomer Exploits bleiben.

Der CRA hat keine Meinung dazu, wer oder was Ihren Code schreibt. Er hat eine klare Meinung dazu, wer dafür geradesteht. Die Verordnung verlangt wirksame und regelmäßige Sicherheitstests Ihres Produkts, und die Konformitätserklärung, die Sie im Rahmen der Konformitätsbewertung unterzeichnen, deckt jeden Patch ab, den Sie während des Supportzeitraums verteilen. Ein KI-generierter Fix, der eine neue Lücke öffnet, ist Ihre Nichtkonformität, in Maschinengeschwindigkeit.

Die praktische Konsequenz: Ihre Patch-Pipeline braucht Testnachweise, die mit dem Patch-Volumen mitwachsen. Menschliche Prüfung jeder KI-geschriebenen Zeile skaliert nicht auf 500 Funde am Tag. Dokumentierte, automatisierte Sicherheitstests auf dem Patch-Pfad tun das, und sie erzeugen die Artefakte, die Ihre technische Dokumentation braucht. Setzen Sie KI-gestützte Behebung ein, protokollieren Sie, welche Patches maschinell erzeugt wurden und welche Validierung jeder einzelne bestanden hat. Fragt ein Regulierer, wie Sie Ihre Testpflicht bei diesem Tempo ehrlich eingehalten haben, ist die Antwort ein Protokoll, keine Grundsatzerklärung.

5. Ihre Schwachstellenmeldungen werden zur öffentlichen Sicherheitshistorie

Die letzte Folge ist die leiseste im Papier. ENISA schreibt, dass korrelierte EUVD-Daten Hotspots in der Lieferkette, systemische Schwächen und durch KI-gestützte Entdeckung beschleunigte Schwachstellentrends erkennen können. Einen Satz weiter: CRA-bezogene Meldungen können helfen, Herstelleraussagen zur Härtung gegen reale Ausnutzbarkeit und Vorfallmuster zu prüfen.

Lesen Sie das als Hersteller. Ab dem 11. September 2026 melden Sie aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle binnen 24 Stunden über die Single Reporting Platform, dann eine 72-Stunden-Folgemeldung, dann einen Abschlussbericht binnen 14 Tagen nach dem Fix. Jede Meldung landet in einer Infrastruktur, die ENISA zu korrelieren plant. Mit der Zeit wird diese Korrelation zu einer herstellerbezogenen Sicherheitshistorie: wie oft Sie ausgenutzt wurden, wie schnell Sie behoben haben, wie Ihre Bilanz mit Ihren Aussagen übereinstimmt.

Daraus folgen zwei Verhaltensweisen:

• Formulieren Sie Produktsicherheitsaussagen, die Sie mit Ihrer eigenen Meldehistorie verteidigen können. „Gehärtet" und „secure by design" auf einem Datenblatt werden irgendwann neben Ihrer EUVD-Zeile stehen. Marketing, das den Daten davonläuft, wird zum Gespräch mit der Marktüberwachung.
• Behandeln Sie die Meldequalität als Reputation, nicht als Papierkram. Eine präzise 72-Stunden-Meldung mit echten Korrekturmaßnahmen liest sich anders als eine minimale, und ENISAs erklärtes Ziel ist es, die Lücke zwischen Offenlegung und koordinierter Reaktion mithilfe dieser Daten zu schließen. Die Meldekette selbst ging dieses Jahr stufenweise live, mit der Aufnahme der ersten CVE Numbering Authorities durch ENISA im Mai 2026.

Die Zusammenfassung des Papiers hält fest, dass die SRP, sobald funktionsfähig, genutzt werden muss, um den Herausforderungen neuer Entwicklungen zu begegnen. ENISA hat sich dazu schriftlich verpflichtet. Ihre Meldungen sind der Input.

Dieser Artikel dient ausschließlich der Information und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich an qualifizierte Rechtsberater.