OpenSSL: Was Hersteller jetzt nachweisen müssen

Anton Arapov ordnet ein, wie Hersteller ihre Open-Source-Komponenten unter dem CRA pflegen und auf Post-Quantum-Kryptografie vorbereiten.

Verwandt: CRA-Meldepflicht startet: Frühwarnung binnen 24 Stunden  ·  Was ist Post-Quantum-Kryptografie?

Meldepflichten und Rollen unter dem CRA

Frage 1

Seit dem 11. September müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden. Was ändert das für ein Projekt wie OpenSSL, das in unzähligen Produkten steckt und für die Hersteller, die es ausliefern?

Antwort

Die 24-Stunden-Frist gilt für Hersteller. Seit dem 11. September müssen sie aktiv ausgenutzte Schwachstellen und schwere Vorfälle über die zentrale ENISA-Meldeplattform melden: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und danach einen Abschlussbericht. Für eine Bibliothek, die so breit eingebettet ist wie unsere, wirkt sich das indirekt aber real aus: Es steigt der Wert dessen, was ein ausgereifter Sicherheitsprozess ohnehin liefert. Unser Prozess funktioniert seit Jahren auf dieselbe Weise. Meldungen gehen an eine zentrale Sicherheitsadresse und jedes Problem wird als kritisch, hoch, moderat oder niedrig eingestuft. Kritische und hohe Befunde lösen eine Veröffentlichung aus. Betriebssystem-Distributoren und Partner erhalten den Fix vor der öffentlichen Veröffentlichung unter Embargo, damit gepatchte Pakete am Tag der Veröffentlichung von Advisory und CVE bereitstehen. Der größere Wandel liegt bei den Herstellern. Die Uhr beginnt zu laufen, sobald ein Hersteller erfährt, dass eine Schwachstelle in seinem Produkt ausgenutzt wird und sehr oft steckt diese Schwachstelle in einer Komponente, die er nicht selbst geschrieben hat. Wer nicht innerhalb weniger Stunden sagen kann, welche Produkte welche Version der OpenSSL-Bibliothek enthalten und wie sie gebaut und verknüpft ist, kann keine aussagekräftige Frühwarnung senden. Das wird auch den Druck erhöhen, dass Hersteller und vorgelagerte Projekte schnell detaillierte Informationen austauschen. Das hilft allen, solange Meldungen mit genügend Details eingehen, um handeln zu können. Software ist nie frei von Fehlern. Wahrheitsgemäß kann jeder nur sagen, dass keine Fehler bekannt sind. Die Verordnung fragt, ob man reagieren kann, wenn sich das ändert.

Frage 2

Der CRA unterscheidet zwischen Herstellern und Betreuern von Open-Source-Software. Entwickler außerhalb einer kommerziellen Tätigkeit sind ausgenommen. Wo steht OpenSSL und wo ziehen Sie die Verantwortungsgrenze zwischen dem Projekt und dem Produkthersteller?

Antwort

Der CRA ordnet nach Produkt und Tätigkeit. Hersteller tragen die Pflichten aus den Artikeln 13 und 14. Betreuer von Open-Source-Software, eine durch die Verordnung eingeführte Rolle, haben nach Artikel 24 geringere Pflichten. Die Meldepflicht beginnt am 11. Dezember 2027. Kostenlose und nicht monetarisierte freie Software wird nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt, wie die Leitlinien der Kommission vom Juli bestätigen. Wir schließen derzeit gemeinsam mit Rechtsberatern eine formale Bewertung ab und arbeiten in den Open-Source-Arbeitsgruppen mit. Die OpenSSL-Bibliothek ist frei verfügbar und nicht monetarisiert. Der CRA ändert daran nichts.

Die Verantwortungsgrenze ergibt sich aus der Mechanik der Verordnung selbst. Heute gelten nur die Meldepflichten aus Artikel 14. Ab dem 11. Dezember 2027 müssen Hersteller, die Open-Source-Komponenten integrieren, deren Sorgfaltspflichten erfüllen und Schwachstellen, die sie in einer Komponente finden, an deren Betreuer melden. Die Verordnung kennt keine eigene Kategorie für Maintainer und der Hersteller bleibt für das Produkt als Ganzes verantwortlich. Von uns kann ein Hersteller erwarten, was diese Sorgfaltspflicht braucht, sofern er weiß, welche Version der Bibliothek in welchem Produkt steckt: eine veröffentlichte Sicherheitsrichtlinie mit definierten Schweregraden, eine Release-Strategie mit einer zweijährigen Long-Term-Support-Linie und einer Unterstützung von jeweils mindestens fünf Jahren, Advisories mit vom Projekt selbst vergebenen CVEs, eine Vorabinformation für Distributoren und Partner vor der Veröffentlichung von Fixes sowie einen für regulierte Nutzung validierten FIPS-140-3-Provider.

Eine SBOM hilft nur, wenn sie den tatsächlichen Inhalt des Binärprogramms abbildet.

Frage 3

Welchen häufigsten Fehler beobachten Sie bei Herstellern im Umgang mit eingebetteten Open-Source-Komponenten, etwa bei SBOMs, der Übernahme von Patches oder veralteten Versionen?

Antwort

Eine kryptografische Bibliothek wie einen einmaligen Import zu behandeln statt als Abhängigkeit mit einem Lebenszyklus. Eine Version wird in einen Build kopiert, statisch verknüpft und bleibt jahrelang unangetastet, weil nichts sichtbar kaputtgeht. OpenSSL 3.0 hat am 7. September sein Lebensende erreicht, vier Tage bevor die CRA-Meldepflichten für Hersteller zu gelten begannen. Produkte, die diese Version weiterhin ausliefern, brauchen jetzt einen Upgrade-Plan. In der Praxis sehe ich in einem Produkt meistens mehrere Kopien der Bibliothek: eine aus dem Betriebssystem sowie weitere, die mit Anwendungen oder Firmware-Komponenten gebündelt sind. Jede wird anders gebaut und folgt ihrem eigenen Zeitplan. Der Übergang zu FIPS 140-3 hat das bei vielen Teams sichtbar gemacht, weil der validierte Provider ein bestimmter Build ist und die Frage nach der tatsächlich kryptografisch arbeitenden Kopie plötzlich präzise beantwortet werden musste. Eine SBOM hilft nur, wenn sie den tatsächlichen Inhalt des Binärprogramms abbildet. Statisch verknüpfte Kopien fehlen in Inventaren, die nur nach Betriebssystempaketen suchen. Die Lösung ist Zuständigkeit statt Werkzeug: Jemand muss für jede kritische Abhängigkeit verantwortlich sein, ihr Supportfenster verfolgen und das nächste Upgrade planen, bevor die aktuelle Version ausläuft. Mit der Sorgfaltspflicht, die der CRA ab Dezember 2027 einführt, wird diese Zuständigkeit Teil des Nachweises, dass die eigenen Abhängigkeiten unter Kontrolle sind.

Post-Quantum als Vorbereitung in der Praxis

Frage 4

OpenSSL 3.5 macht als LTS-Version den hybriden Post-Quantum-Schlüsselaustausch in TLS 1.3 zum Standard. Warum jetzt und welches Feedback erhalten Sie aus der Praxis zu Kompatibilität und Leistung?

Antwort

Weil das Risiko bereits operativ ist. Daten, die heute aufgezeichnet werden, können gespeichert und entschlüsselt werden, sobald Quantenhardware leistungsfähig genug ist. Deshalb muss der Schutz beim Schlüsselaustausch beginnen. Den Zeitpunkt dieses Moments vorherzusagen ist nicht nötig, um zu erkennen, dass Warten die Gefährdung erhöht. OpenSSL 3.5 wurde im April 2025 als Long-Term-Support-Version veröffentlicht und aktiviert standardmäßig den hybriden Post-Quantum-Schlüsselaustausch X25519MLKEM768 in TLS 1.3. Der hybride Schlüsselaustausch verbindet eine klassische und eine Post-Quantum-Schlüsselvereinbarung. Die Sitzungsschlüssel bleiben sicher, solange eine von beiden Bestand hat. Das ist relevant, weil Kandidaten im Post-Quantum-Verfahren auf dem Weg dorthin gebrochen wurden. Neue Algorithmen hatten weniger Zeit, einer Kryptoanalyse standzuhalten. Deshalb haben wir die konservative Wahl zur einfachen Wahl gemacht. Wer eigenständiges ML-KEM nutzen will, kann per Konfiguration umschalten. Hybrid als Standard und eigenständig als Option.

Die Aufnahme in eine LTS-Version war beabsichtigt, weil Hersteller ihre Produkte auf LTS-Versionen aufbauen. Das verändert die Vereinbarung von Sitzungsschlüsseln. Die Datenverschlüsselung bleibt unverändert und die Authentifizierung ist praktisch noch nicht Post-Quantum, weil Zertifikate weiterhin von klassischen CAs stammen. Die Bibliothek unterstützt ML-DSA und ist bereit, sobald die Public-Key-Infrastruktur es ist. Aus der Praxis lautet mein Rat: Die eigene Umgebung testen, bevor man dem Standard vertraut, besonders Prüfgeräte und eingebettete Endpunkte. Der Algorithmus ist nicht das Problem. ML-KEM ist schnell und die CPU-Kosten sind vernachlässigbar. Die Reibung entsteht bei der Größe. Der ClientHello wächst um etwa 1,2 Kilobyte und passt nicht mehr in ein einzelnes Paket. Ein kleiner Anteil der Middleboxes und Server, die das voraussetzen oder eine unbekannte Gruppe zurückweisen statt sie zu ignorieren, bricht dann. Cloudflares Tests mit den Servern seiner Kunden ergaben, dass weniger als 0,34 Prozent der untersuchten Origin-Server scheitern, wenn ihnen der Post-Quanten-Keyshare direkt im ersten ClientHello angeboten wird. Für Prüfgeräte in Unternehmensnetzen ist mir keine öffentliche Zahl bekannt. Der hybride Austausch schützt bereits rund 70 Prozent des Browserverkehrs, der das Cloudflare-Netzwerk erreicht. Das ist kein Experiment.

Frage 5

Was sollten Hersteller mit langen Produktlebenszyklen, etwa in der Industrie oder Medizintechnik, heute tun, damit sie in fünf Jahren nicht nachrüsten müssen?

Antwort

Mit der Rechnung beginnen. Unter dem CRA muss die Supportdauer grundsätzlich mindestens fünf Jahre betragen und Industrie- oder Medizinprodukte bleiben oft zehn oder fünfzehn Jahre im Feld. OpenSSL 3.5 wird bis April 2030 unterstützt. Die nächste Long-Term-Support-Version ist für April 2027 geplant und soll bis 2032 unterstützt werden. Ein Produkt, das im nächsten Jahr auf den Markt kommt, wird länger leben als die Bibliotheksversion, mit der es ausgeliefert wird. Der Upgradepfad gehört deshalb vom ersten Tag an in das Design.

In der Praxis bedeutet das drei Dinge. Erstens Krypto-Agilität: Algorithmen und Parameter konfigurierbar halten statt sie fest zu codieren und im Speicher sowie bei der Bandbreite Reserven für größere Post-Quantum-Schlüssel und Signaturen lassen. Zweitens einen sicheren und getesteten Updatepfad: Ein Gerät, das ein Bibliotheksupdate im Feld nicht empfangen und prüfen kann, lässt sich später ebenfalls nicht quantensicher machen. Der Update-Mechanismus selbst darf nicht von den Algorithmen abhängen, die ersetzt werden sollen. Drittens ein Inventar, das für jedes Produkt benennt, welche Komponente die Kryptografie bereitstellt und wer für ihr Upgrade zuständig ist. In regulierten Branchen sehe ich häufig, dass die Kryptografie beim Design korrekt war und dann gemeinsam mit der Zertifizierung eingefroren wurde. Jede Änderung öffnet die Zertifizierung erneut. Der Ausweg ist, die Fähigkeit zur Änderung zu zertifizieren und nicht einen einzelnen Algorithmus. Die europäische Roadmap fordert die Mitgliedstaaten auf, den Übergang bis Ende 2026 zu beginnen und Hochrisikosysteme bis 2030 abzudecken. Diese Fragen werden daher früher als von den meisten erwartet in der Beschaffung ankommen.

Souveränität: Prüfbarkeit zählt mehr als Herkunft

Frage 6

Tim Hudson, Präsident der OpenSSL Corporation, sagt, Code habe keine Nationalität. Was bedeutet das für die europäische Debatte über digitale Souveränität, die sich häufig darauf konzentriert, woher Software stammt?

Antwort

Der Satz stammt von meinem Kollegen Tim Hudson und ich teile ihn. Herkunft ist ein schwacher Ersatz für Vertrauen. Quellcode kann von jedem gelesen, gebaut und geprüft werden, unabhängig davon, wo er geschrieben wurde. SSLeay, der Code, aus dem die OpenSSL-Bibliothek hervorgegangen ist, wurde in Brisbane geschrieben. Heute hat das Projekt Beitragende auf mehreren Kontinenten und die OpenSSL Corporation betreibt ihre Arbeit von Brno aus innerhalb der EU. Wo eine Codezeile geschrieben wurde, sagt wenig darüber aus, ob ein bestimmter Build sicher ist. Aussagekräftig ist, ob der Code geprüft werden kann, der Build reproduzierbar ist, Signaturen kontrolliert werden können und man selbst patchen kann, falls es nötig wird. Souveränität bedeutet in der Praxis, unabhängig handeln zu können, unabhängig vom Pass des Autors.

Unsere eigenen Werte besagen, dass keine Regierung, Organisation oder Einzelperson unangemessenen Einfluss auf die Erfüllung unseres Auftrags haben sollte. Die Entwicklung ist standardmäßig öffentlich. Europa hat bereits ein funktionierendes Beispiel für dieses Denken. Der deutsche Sovereign Tech Fund hat die Arbeit der OpenSSL Foundation an der Resistenz gegen Seitenkanalangriffe und am Rückstand offener Probleme finanziert. Das ist eine Investition in gemeinsame Infrastruktur, auf die europäische Hersteller täglich angewiesen sind. Nationale Kopien würden Aufwand duplizieren, der besser in die Stärkung dessen fließt, worauf Europa bereits aufbaut.

KI-Agenten brauchen Kontrollen an der Handlung

Frage 7

Tim Hudson verortet Sicherheit an der Handlungsschnittstelle, weniger beim Modellzugriff. Was bedeutet das für KI-Agenten, die zunehmend Code schreiben oder Abhängigkeiten selbst auswählen?

Antwort

Tim Hudson hat es so formuliert und so sehen wir es auch bei der OpenSSL Corporation. Ein KI-Agent, der Code schreibt oder Abhängigkeiten auswählt, ist ein weiterer Akteur mit Berechtigungen. Die Frage ist weniger, auf welchem Modell er läuft, sondern was er tun darf. Darf er ohne Prüfung eine Abhängigkeit hinzufügen, eine Versionssperre ändern, aus beliebigen Registries laden, in den Hauptzweig mergen oder eine Veröffentlichung auslösen? Dort müssen die Kontrollen ansetzen: eine Liste freigegebener Quellen, per Hash geprüfte und festgelegte Versionen, eine SBOM für jeden Build, ein menschliches oder regelbasiertes Gate, bevor etwas Neues in die Produktion gelangt sowie Protokolle, mit denen sich später nachvollziehen lässt, was der Agent getan hat. Das ist wichtig, weil Agenten sehr gut darin sind, plausible Entscheidungen zu produzieren, darunter auch veraltete oder nicht mehr gepflegte Pakete.

Wir sehen die andere Seite dieses Effekts auch im Projekt selbst. Matt Caswell, Executive Director der OpenSSL Foundation, beschrieb es im September so: „Vor einem Jahr erhielt unsere Sicherheitsadresse ungefähr neun Meldungen und Anfragen pro Monat. Jetzt sind es rund 70.“ Und weiter: „In den vergangenen zwölf Monaten haben wir etwas mehr als 400 Schwachstellenmeldungen erhalten. 43 davon führten zu einer veröffentlichten CVE.“ KI erhöht das Volumen auf beiden Seiten. Kontrollen an der Handlungsschnittstelle halten dieses Volumen für ein Projekt ebenso wie für einen Hersteller beherrschbar. Unsere eigene Beitragsrichtlinie verlangt, dass die Nutzung von KI offengelegt wird und jede Änderung vor dem Merge eine menschliche Prüfung durchläuft.

Was Sicherheitsverantwortliche aus Prag mitnehmen

Frage 8

Die OpenSSL Conference in Prag endet am 15. Oktober. Welche zentrale Botschaft sollten Sicherheitsverantwortliche aus dieser Konferenzwoche mitnehmen?

Antwort

Dass CRA-Compliance und Post-Quantum-Bereitschaft dieselbe operative Disziplin verlangen: Man muss wissen, was in den eigenen Produkten steckt, es gepflegt halten und schnell ändern können. Das diesjährige Thema ist der Křižík-Effekt, benannt nach František Křižík, dessen Bogenlampe bei der Pariser Elektrizitätsausstellung 1881 die Goldmedaille gewann. Es war der Moment, in dem elektrisches Licht aufhörte, eine Neuheit zu sein und zur Infrastruktur wurde. Kryptografie hat dieselbe Linie überschritten. Sie leuchtet erst auf, wenn sie ausfällt. Vom 13. bis 15. Oktober bringt die Konferenz alle zusammen, die an Open-Source-Sicherheit und Datenschutz arbeiten oder davon abhängen: die Projekte unter der OpenSSL Mission, die größere Familie der Bibliotheken und Forks sowie die Unternehmen, Juristen, politischen Entscheidungsträger und Forscher in ihrem Umfeld. Als einer der Organisatoren würde ich Hersteller auf den Track „Security, Compliance & the Law“ als natürlichen Einstieg hinweisen. Wenn Sicherheitsverantwortliche eine Sache mitnehmen, dann diese: Die Open-Source-Komponenten in ihren Produkten kümmern sich nicht selbst um sich. Menschen pflegen sie und ihre Sicherheit zu erhalten ist eine gemeinsame Aufgabe.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Wen betrifft die 24-Stunden-Frist?

Sie gilt für Hersteller, die aktiv ausgenutzte Schwachstellen und schwere Vorfälle über die ENISA-Meldeplattform melden müssen.

Welche Rolle hat OpenSSL unter dem CRA?

Die OpenSSL-Bibliothek ist frei verfügbar und nicht monetarisiert. Die formale Bewertung mit Rechtsberatern läuft laut Quelle noch.

Warum reicht eine SBOM allein nicht?

Sie muss den tatsächlichen Inhalt des Binärprogramms abbilden. Statisch verknüpfte Kopien können in reinen Betriebssysteminventaren fehlen.

Was ist für lange Produktlebenszyklen entscheidend?

Krypto-Agilität, ein sicherer Updatepfad und ein Inventar mit klarer Upgrade-Zuständigkeit müssen früh eingeplant werden.

Wo sollten Kontrollen bei KI-Agenten ansetzen?

An der Handlungsschnittstelle: Quellen, Versionen, SBOMs, Freigaben und Protokolle begrenzen, was ein Agent tun kann.

Über den Gesprächspartner
Anton Arapov ist Director bei der OpenSSL Corporation. Er ordnet im Q&A CRA-Meldepflichten, Post-Quantum-Kryptografie, digitale Souveränität und KI-Agenten ein.

Lesetipps der Redaktion

LesetippDie CRA-Meldepflicht bindet einen Teil des Security-EtatsLesetippWas ist ein Supply-Chain-Angriff? Definition und AbwehrLesetippSo beschleunigt KI die Schwachstellensuche

Mehr aus dem MBF Media Netzwerk

cloudmagazinPost-Quantum-Migration in der DACH-Enterprise-IT: Welche Krypto-Bestände 2026 realistisch umgezogen werdenMyBusinessFutureHersteller melden CRA-Vorfälle an ENISA vor dem CSIRTDigital ChiefsQuantenrechner lesen später, was Angreifer heute speichern

Bildquelle: Titelbild KI-generiert (Oktober 2026), Porträt Anton Arapov: OpenSSL Corporation