Cyber Resilience Act: Geschwindigkeit und Sicherheit mit KI-Codierung steuern

Moderne Softwareentwicklung befindet sich im Spannungsfeld zweier mächtiger Kräfte. Einerseits beschleunigen generative KI-Codierungstools die Entwicklungsgeschwindigkeit, allerdings auf Kosten einer strengen Sicherheitsprüfung. Andererseits läutet der Cyber Resilience Act (CRA) der Europäischen Union (Verordnung (EU) 2024/2847) zusammen mit verwandten Rechtsvorschriften wie der Produkthaftungsrichtlinie (PLD) eine Ära strenger regulatorischer Rechenschaftspflicht ein, die die Haftung für die Verhinderung von Cybersicherheitsfehlern direkt den Herstellern auferlegt. Dies schafft ein kritisches Paradoxon: Gerade die Werkzeuge, die dazu dienen, Software schneller zu entwickeln, führen Sicherheitsrisiken in einem Ausmaß ein, das eine manuelle Überwachung nicht bewältigen kann, und der CRA macht Hersteller für diese Risiken rechtlich verantwortlich.

Für alle Unternehmen, die in der EU Geschäfte tätigen – wohlgemerkt nicht nur Unternehmen mit Sitz in der EU – bedeutet diese neue Realität erhebliche neue Komplikationen für das Software-Lebenszyklus- und Lieferkettenmanagement, insbesondere bei der Verwendung von KI-Codierungstools. Der CRA führt verbindliche Cybersicherheitsanforderungen ein, die während des gesamten Produktlebenszyklus gelten und „Produkte mit digitalen Elementen“ (PDEs) vom Design bis zum Ende der Lebensdauer abdecken. Mit schwerwiegenden Strafen bei Nichteinhaltung – bis zu 15 Millionen Euro oder 2,5 % des weltweiten Umsatzes – schreibt der CRA ein neues Modell gesetzlich vor: eines, das von Organisationen verlangt, schnell voranzukommen, aber zu beweisen, dass ihre Produkte von Anfang an richtig entwickelt wurden.

Neue Verpflichtungen durch die CRA

Der Anwendungsbereich der CRA ist bewusst weit gefasst und gilt für alle auf dem EU-Markt erhältlichen PDEs, unabhängig vom Herstellerstandort. Dazu gehört eine breite Produktpalette wie Babyphone, vernetzte Haushaltsgeräte, B2B-Software, vernetzte Unterhaltungselektronik und mehr. Die technischen Kernanforderungen, detailliert in Anhang I aufgeführt, sind umfangreich. Eckpfeiler ist die Vorgabe, Produkte „ohne bekannte ausnutzbare Schwachstellen“ auszuliefern und sie mit einer „standardmäßig sicheren Konfiguration“ auszuliefern. Weitere wesentliche Verpflichtungen sind der Schutz vor unbefugtem Zugriff, die Gewährleistung der Vertraulichkeit und Integrität von Daten, die Begrenzung von Angriffsflächen und die Minimierung der Datenverarbeitung.

Das Gesetz legt auch fortlaufende Verantwortlichkeiten fest. Hersteller müssen robuste Prozesse zur Schwachstellenbehebung implementieren, wozu auch die Erstellung einer Software Bill of Materials (SBOM) für ihre Produkte gehört. Sie sind verpflichtet, Sicherheitsupdates für einen Supportzeitraum von mindestens fünf Jahren bereitzustellen. Die vielleicht dringendste Anforderung ist die 24-Stunden-Frist, innerhalb derer die EU-Cybersicherheitsagentur ENISA über jede „aktiv ausgenutzte Schwachstelle“ informiert werden muss. Diese Regel erfordert ausgereifte und gut erprobte Notfallpläne. Der Nachweis der Einhaltung erfordert eine sorgfältige Dokumentation, einschließlich einer Cybersicherheits-Risikobewertung.

Ausnahmen gelten lediglich für Produkte, für die bereits branchenspezifische Gesetze mit gleichwertigen Cybersicherheitsanforderungen bestehen, beispielsweise für Medizinprodukte, die Luftfahrt und Autos. Bestimmte Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, ist ebenfalls von den direkten Verpflichtungen der Hersteller ausgenommen. Die kommerziellen Produkte, die diese Software enthalten, bleiben jedoch vollständig im Geltungsbereich. Diese umfassende Anwendbarkeit stellt sicher, dass der CRA eine horizontale Cybersicherheitsgrundlage für die digitale Wirtschaft schafft.

Das KI-Codierungs-Paradoxon: Geschwindigkeit mit Risiko

Die schnelle Einführung von KI-Programmierassistenten bringt für Entwickler und Hersteller eine neue Variable in die CRA-Compliance-Gleichung. Diese Tools beschleunigen die Entwicklung, bergen aber auch erhebliche Sicherheitsrisiken. KI-Modelle werden anhand riesiger öffentlicher Code-Repositories trainiert und lernen aus den unzähligen Schwachstellen und unsicheren Programmiermustern in diesen Daten. Studien haben gezeigt, dass ein erheblicher Teil – in manchen Fällen etwa 40 % – des KI-generierten Codes Sicherheitslücken wie die in der CWE Top 25-Liste aufgeführten enthält. Beispiele für erhöhte Sicherheitsrisiken sind:

• Replizieren unsicherer Muster, wie sie beispielsweise zu Log-Injection- oder Cross-Site-Scripting-Angriffen führen.
• Verwenden veralteter Open-Source-Bibliotheken mit bekannten Schwachstellen oder sogar das Vortäuschen nicht vorhandener Pakete (dies schafft einen potenziellen Angriffsvektor, über den böswillige Akteure diese Paketnamen registrieren und Malware verbreiten können).
• Unzulängliche, unsichere Eingabeaufforderungen für KI-generierten Code, der häufig wiederverwendet wird und in Kombination mit KI-Halluzinationen unsichere Muster in Unternehmen verbreitet.
• Mögliche böswillige Vergiftung von Trainingsdaten, bei der ein Angreifer absichtlich anfälligen oder mit Backdoors versehenen Code in öffentliche Repositories einführt, die wahrscheinlich für das Modelltraining ausgenutzt werden.

Die CRA gibt eine eindeutige Antwort auf die Frage, wer für diese KI-bedingten Fehler verantwortlich ist: der Hersteller des Endprodukts. Die Verordnung unterscheidet nicht zwischen von Menschen geschriebenem und von KI vorgeschlagenem Code. Um den Sorgfaltspflichtstandard der CRA zu erfüllen, müssen Unternehmen KI-generierten Code als nicht vertrauenswürdige Eingabe behandeln, die dasselbe oder sogar ein strengeres Maß an automatisierter Sicherheitsanalyse erfordert wie jede Drittanbieterbibliothek.

Ein strategischer Rahmen für Compliance

Um die doppelte Herausforderung des CRA und des KI-generierten Codes zu bewältigen, ist ein Framework erforderlich, das eine automatisierte Sicherheitsüberprüfung während des gesamten Softwareentwicklungszyklus einbettet.

• Sicherheit von Anfang an einbetten: Das „Secure-by-Design“-Prinzip des CRA (Cyber Resilience Act) erfordert eine „Shift-Left“-Strategie bei der Sicherheit. Dies wird durch statische Code-Analyse und statische Anwendungssicherheitstests (SAST) ermöglicht. Diese Tools lassen sich direkt in die IDE des Entwicklers und in die CI/CD-Pipeline integrieren. Ein Tool wie SonarQube verhindert beispielsweise, dass Probleme in den Hauptzweig gelangen, indem es Ihren Entwicklern sofortiges Feedback zu Schwachstellen und Codierungsfehlern gibt, während der Code geschrieben wird.
• Kontrolle über KI-generierten Code behalten: Organisationen müssen KI-generierten Code verifizieren, nicht nur vertrauen. Dies im großen Maßstab zu tun, erfordert die Fähigkeit, anfälligen oder minderwertigen Code mit automatisierten Schutzmaßnahmen zu stoppen. Eine Quality Gate, verfügbar in SonarQube, kann verhindern, dass anfälliger oder minderwertiger Code in die Produktion gelangt. Dies ist ein nicht verhandelbarer Prüfpunkt in der CI/CD-Pipeline, unabhängig davon, ob der Code von einem Entwickler oder einer KI geschrieben wurde.
• Beherrschung der Software-Lieferkette: Das Mandat des CRA für eine SBOM macht eine robuste Software Composition Analysis (SCA) unerlässlich. Ein effektiver SCA-Prozess, wie er im Advanced Security-Angebot von SonarQube enthalten ist, kennzeichnet automatisch Risiken in Ihrer Open-Source-Software von Drittanbietern, basierend auf der Identifizierung von Abhängigkeiten und der kontinuierlichen Schwachstellenanalyse. Er kann auch einen nachvollziehbaren Schwachstellenmanagementprozess mit Software Bills of Materials (SBOM)-Funktionen gewährleisten.
• Schutz der Datenintegrität: Der CRA schreibt vor, dass Systeme manipulationsresistent sein und die Auswirkungen von Sicherheitsvorfällen minimiert werden müssen. Taint-Analyse, eine SonarQube-Funktion, die den Fluss nicht vertrauenswürdiger Benutzerdaten über die gesamte Anwendung und Drittanbieterbibliotheken hinweg verfolgt, um tief eingebettete Injektionsschwachstellen zu identifizieren, erfüllt diese Anforderungen direkt.
• Systemzugriff schützen: SonarQube findet häufig Fälle, in denen Entwickler versehentlich fest codierte Anmeldeinformationen in die Quellcodeverwaltung einpflegen. Die Geschwindigkeit der KI-gestützten Entwicklung ist zwar vorteilhaft für die Produktivität, birgt jedoch ein erhöhtes Risiko für solche Vorkommnisse. Um dies zu mindern, sind automatisierte Geheimniserkennungstools unerlässlich. SonarQube identifiziert und stellt beispielsweise sicher, dass Ihre Entwickler sensible Zugriffsdaten entfernen, bevor Sie exponiert werden, indem die gesamte Codebasis nach Mustern wie API-Schlüsseln, Passwörtern und anderen sensiblen Token durchsucht wird.
• Compliance nachweisen: Der Nachweis der Compliance erfordert eine prüfbare Aufzeichnung der Sicherheitsaktivitäten. Es kann jedoch schwierig sein, alle Sicherheitsaktivitäten über Ihre Codebasen hinweg kohärent und effizient zu verfolgen. Lösungen wie SonarQube enthalten Berichte, die einen schnellen und konsistenten Zugriff auf die Dokumentation gewährleisten, die Sie benötigen, um die Einhaltung von Sicherheitsstandards wie den OWASP Top 10 und CWE Top 25 nachzuweisen.

Ein kleines Zeitfenster

Die Fristen des Cyber Resilience Act sind verbindlich und rücken näher. Die Pflicht zur Meldung aktiv ausgenutzter Schwachstellen gilt ab dem 11. September 2026, die vollständige Anwendung der meisten anderen Bestimmungen erfolgt ab dem 11. Dezember 2027.

Organisationen sollten sofort mit den Vorbereitungen beginnen, indem sie beurteilen, welche Produkte in den Geltungsbereich der CRA fallen, eine Lückenanalyse ihrer aktuellen Prozesse durchführen, ihre Sicherheitstools bewerten und ihre Reaktionspläne für Vorfälle formalisieren, um das enge 24-Stunden-Berichtsfenster einzuhalten.

Die SonarQube-Plattform integriert alle oben genannten Funktionen in einer einzigen Lösung und gewährleistet so sowohl Entwicklern als auch Qualitätsverantwortlichen ein benutzerfreundliches und optimiertes Erlebnis. Dieser umfassende Ansatz ermöglicht es Teams, Sonars „Trust and Verify“-Ansatz zu implementieren, um hohe Standards bei Codequalität und -sicherheit aufrechtzuerhalten, selbst wenn sie KI-Codierungslösungen einsetzen. Dies führt letztendlich zu robusteren und zuverlässigeren Anwendungen.

Softwareteams, die den CRA als bloße Compliance-Checkliste betrachten, die mit fragmentierten Tools oder manuellen Prozessen verwaltet werden muss, werden Schwierigkeiten haben, Schritt zu halten und sich erheblichen rechtlichen und finanziellen Risiken aussetzen. Unternehmen, die sich hingegen vom Geist des Gesetzes leiten lassen – einer tief verwurzelten Verpflichtung, von Anfang an qualitativ hochwertige, sichere und zuverlässige Software zu entwickeln – können diese regulatorische Verpflichtung in einen entscheidenden Wettbewerbsvorteil verwandeln. Durch die Implementierung eines integrierten Rahmens zur Steuerung der Qualität und Sicherheit allen Codes, unabhängig von seiner Herkunft, können Unternehmen nicht nur ihren gesetzlichen Pflichten nachkommen, sondern auch robustere Produkte entwickeln, das Kundenvertrauen stärken und letztlich schneller und sicherer Innovationen hervorbringen.