Wissen, was drinsteckt: Was Cyber Resilience Act und Post-Quantum-Kryptografie von Software verlangen

Kaum eine Software kommt ohne fremde Bausteine aus. Verschlüsselung, Datenbankzugriff, Webserver – vieles davon stammt aus Open-Source-Bibliotheken wie OpenSSL. Der Cyber Resilience Act der EU macht Hersteller jetzt dafür verantwortlich, genau zu wissen, welche Bausteine in ihren Produkten stecken. Und die Umstellung auf quantensichere Verschlüsselung zeigt, wer seine Software darauf vorbereitet hat, sich ändern zu lassen.

Worum es geht

In einem Interview mit SecurityToday ordnet Anton Arapov, Director der OpenSSL Corporation, ein, was der Cyber Resilience Act (CRA) und die Post-Quantum-Umstellung für Hersteller bedeuten. Seine Kernaussage lässt sich auf einen Satz bringen: Man muss wissen, was in den eigenen Produkten steckt, es gepflegt halten und es schnell ändern können. Das klingt selbstverständlich. In der Praxis ist es das oft nicht.

Die Uhr läuft bereits

Der CRA gilt vollständig zwar erst ab dem 11. Dezember 2027. Die Meldepflichten greifen aber schon seit dem 11. September 2026: Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Frühwarnung an die europäische Meldeplattform abgeben, nach 72 Stunden eine ausführliche Meldung und danach einen Abschlussbericht.

Das Problem: Sehr oft steckt die Schwachstelle nicht im selbst geschriebenen Code, sondern in einer eingebundenen Bibliothek. Wer dann nicht innerhalb weniger Stunden sagen kann, welche Version dieser Bibliothek in welchem Produkt steckt, kann keine sinnvolle Meldung abgeben – und seine Kunden nicht gezielt warnen.

Der häufigste Fehler: einmal eingebaut, nie wieder angefasst

Nach Arapovs Erfahrung behandeln viele Hersteller eine Kryptobibliothek wie einen einmaligen Import: Eine Version wird fest in das Produkt eingebaut und bleibt dort jahrelang unverändert, weil ja nichts kaputtgeht. Oft stecken in einem Produkt sogar mehrere Kopien derselben Bibliothek in unterschiedlichen Versionen – eine vom Betriebssystem, weitere in einzelnen Anwendungsteilen oder in der Firmware.

Eine Softwarestückliste (SBOM) hilft nur, wenn sie wirklich abbildet, was im fertigen Programm steckt. Fest eingebaute Kopien tauchen in einfachen Inventaren häufig gar nicht auf. Die Lösung ist laut Arapov keine weitere Software, sondern Zuständigkeit: Für jede wichtige Abhängigkeit muss jemand verantwortlich sein, ihr Supportende im Blick haben und das nächste Update planen, bevor die aktuelle Version ausläuft.

Post-Quantum: Vorbereitung beginnt bei der Änderbarkeit

Angreifer können verschlüsselte Daten heute mitschneiden und speichern, um sie später zu entschlüsseln, sobald Quantencomputer leistungsfähig genug sind. Deshalb setzt die Umstellung beim Schlüsselaustausch an. OpenSSL verwendet seit Version 3.5 standardmäßig ein hybrides Verfahren, das klassische und quantensichere Schlüsselvereinbarung kombiniert. Die Verbindung bleibt sicher, solange eines der beiden Verfahren hält.

Die europäische Roadmap sieht vor, dass die Mitgliedstaaten bis Ende 2026 mit dem Übergang beginnen und kritische Systeme bis 2030 umgestellt sind. Die Frage nach quantensicherer Verschlüsselung wird damit früher in Ausschreibungen und Beschaffung auftauchen, als viele erwarten.

KI im Entwicklungsprozess: Kontrolle an der Handlung

Auch das Thema KI spricht Arapov an. Ein KI-Assistent, der Code schreibt oder Bibliotheken auswählt, ist für ihn ein weiterer Akteur mit Berechtigungen. Entscheidend ist nicht, welches Modell dahintersteht, sondern was er tun darf: Darf er neue Abhängigkeiten ohne Prüfung einbinden? Versionen ändern? Code ohne Freigabe übernehmen? Gerade KI neigt dazu, plausible, aber veraltete oder nicht mehr gepflegte Pakete vorzuschlagen.

Seine Empfehlung: freigegebene Quellen, geprüfte und festgelegte Versionen, eine Stückliste für jeden Build, eine menschliche Freigabe vor der Übernahme und Protokolle, die später nachvollziehbar machen, was geschehen ist.

Wie wir das in unserer eigenen Entwicklung umsetzen

Codekunst entwickelt eigene Sicherheits- und KI-Produkte, darunter unser SIEM. Die Anforderungen aus dem Interview sind für uns keine Neuigkeit, sondern waren von Anfang an Teil der Entwicklung – nicht nachträglich ergänzt, sondern bereits beim Schreiben des Codes berücksichtigt.

Mehr zu unserem Umgang mit KI in der Entwicklung lesen Sie in unserem Beitrag „KI-gestützte Entwicklung – mit klaren Leitplanken“. Wie ernst wir Beherrschbarkeit nehmen, zeigt auch „Wenn das SIEM Kunden und Mitarbeiter aussperrt“: Sicherheitssoftware muss nicht nur Angriffe erkennen, sondern selbst nachvollziehbar und beherrschbar bleiben.

Was das für Sie als Anwender bedeutet

Auch wer selbst keine Software herstellt, ist betroffen – über die Produkte, die er einsetzt. Firewalls, Router, Branchensoftware und Geräte mit eingebetteter Software enthalten dieselben Bibliotheken.

1. Hersteller nach ihrem Updateversprechen fragen: Wie lange wird ein Produkt mit Sicherheitsupdates versorgt? Und passt das zur geplanten Einsatzdauer?
2. Veraltete Systeme erkennen: Geräte und Anwendungen, die keine Updates mehr erhalten, schleppen alte Bibliotheken mit. Sie gehören auf die Austauschliste.
3. Quantensichere Verbindungen testen, bevor sie Standard werden: Durch die neuen Verfahren werden Verbindungsanfragen größer. Ältere Prüfgeräte und Proxys im Netz können daran scheitern. Ein kontrollierter Test vermeidet böse Überraschungen.
4. Bei Ausschreibungen nachfragen: Liefert der Hersteller eine Softwarestückliste? Wie schnell meldet und behebt er Schwachstellen?

Im Rahmen unserer Managed Services behalten wir den Update-Stand Ihrer Systeme im Blick und weisen frühzeitig darauf hin, wenn Komponenten aus dem Support laufen.

Fazit

CRA-Pflichten und Post-Quantum-Umstellung verlangen dieselbe Disziplin: wissen, was drinsteckt, es pflegen und es ändern können. Wer das erst angeht, wenn die erste Meldefrist läuft, ist zu spät. Für unsere eigenen Produkte haben wir diese Grundsätze von Anfang an umgesetzt – und achten auch bei den Systemen unserer Kunden darauf, dass sie aktualisierbar und nachvollziehbar bleiben.

Quellen & weiterführende Links

• SecurityToday

  OpenSSL: Was Hersteller jetzt nachweisen müssen (15. Oktober 2026)
• Amtsblatt der EU

  Verordnung (EU) 2024/2847 (Cyber Resilience Act)
• OpenSSL

  Release-Strategie

Recherche-Stand: 16. Oktober 2026