Der Cyber Resilience Act ist eine Herausforderung. Nicht nur für europäische Firmen. Wir wollten daher wissen, wie ein Unternehmen aus dem nicheuropäischen Ausland damit arbeitet. wolfSSL aus den USA bietet Embedded-Security-Software an, die für ressourcenbeschränkte Umgebungen mit begrenztem Speicher, begrenzter Rechenleistung und begrenztem Speicherplatz entwickelt wurde. Die nach Firmenangabe „schlanken, hochoptimierten Lösungen schützen Kommunikation, Kryptografie und Firmware, ohne unnötigen Ressourcenaufwand zu verursachen“. Entwickelt für Portabilität über eingebettete Plattformen hinweg, will das Unternehmen dabei helfen, „sichere, leistungsstarke Produkte zu entwickeln und gleichzeitig anspruchsvolle Sicherheits- und Branchenanforderungen zu erfüllen“. Wir sprachen mit einem Entwickler der US-amerikanischen Firma, Tobias Frauenschläger.
EASY.CRA (EC): Wann habt Ihr bei wolfSSL damit angefangen, Euch mit dem CRA zu beschäftigen?
Tobias Frauenschläger (TF): Umfangreichere interne Analysen haben in der ersten Jahreshälfte 2025 begonnen, vordergründig mit der Fragestellung, wie unsere Produkte auf die grundlegenden Cybersicherheitsanforderungen des CRA abgebildet werden können. Hier kam heraus, dass unsere jeweiligen Software-Lösungen ideal geeignet sind, um die jeweiligen technischen Anforderungen in einem eingebetteten System zu erfüllen: beispielsweise Secure-Boot mit wolfBoot oder TLS via wolfssl. Darauf aufbauend wurde dann unter anderem intern ein Webinar zum Thema “How to get CRA ready” präsentiert und seitdem mehrfach wiederholt.
Zudem begannen in der zweiten Hälfte 2025 weitere Analysen, um herauszufinden, was Nutzer und Kunden von wolfSSL neben unseren „eigentlichen Produkten“ noch benötigen und welche Anforderungen und Verpflichtungen auf uns als Hersteller der Software-Produkte zukommt. Hierbei wurden die beiden großen Themen „Vulnerability Management“ und „Software Bill of Material“ identifiziert.1 Da zu diesem Zeitpunkt noch einiges in der genauen rechtlichen Umsetzung unklar war, hat sich die Geschäftsleitung, das sind Larry Stefonic und Todd Ouska, dazu entschieden, über eine Pressemitteilung die Botschaft an alle Nutzer und Kunden zu richten, dass „wolfSSL alles tun wird, um vollständig konform zum CRA zu sein“.2 Seitdem wurden intern weitere Schritte durchgeführt, um diesem Ziel näher zu kommen.
EC: Wie seid Ihr vorgegangen?
TF: Auf Basis der oben beschriebenen Analyse unserer Produkte und unter Berücksichtigung zusätzlicher Anforderungen an uns als Firma war der erste große Schritt, unsere Softwareprodukte mit SBOMs auszustatten. Dies wurde konkret im April 2026 begonnen. Hier sind wir iterativ und explorativ vorgegangen, um früh praktische Erfahrungen zu sammeln und Lösungen zu finden, die den Kunden aktiv weiterhelfen. Hierzu wurde zuerst unser Hauptprodukt, die wolfssl Bibliothek, um eine Funktion zur automatisierten Generierung einer SBOM erweitert (make sbom). Schon sehr schnell war uns klar, dass wir keine statischen SBOMs verwenden können, sondern diese während des Build-Vorgangs automatisch und auf die Nutzerumgebung angepasst erstellen müssen. Aufgrund der Konzentration auf eingebettete Systeme bieten unsere Produkte sehr viele Konfigurationsmöglichkeiten und Stellschrauben, um die Bibliotheken bestmöglich an das Nutzersystem anzupassen. Damit der Nutzen der SBOM möglichst hoch ist, muss diese Konfiguration in der SBOM abgebildet sein. Ein Beispiel: Um schnell auswerten zu können, ob eine Schwachstelle überhaupt relevant ist oder ob die betroffene Komponente im konkreten Build gar nicht vorhanden ist, wird die Konfiguration benötigt. Erst dann werden die Abhängigkeiten erkennbar und die Kritikalität sichtbar.
Als dieser erste Schritt erledigt war und ein erster funktionierender Stand erreicht war, wurde der Scope auf das gesamte Produkt-Portfolio erweitert, das sind bei uns immerhin 28 Produkte und mehr als 13 unterschiedliche Build-Systeme. Hier wurde klar, dass eine einheitliche Lösung entwickelt werden muss, die generisch für alle Produkte einsetzbar ist. Hieraus ist nun im Juli 2026 “wolfGlass” entstanden, was eine konsolidierte Infrastruktur ist, die, in alle Produkte integriert, SBOMs automatisiert und für den konkreten Build abgestimmt erzeugt. Zudem wurden viele Dokumentationen und Beispielmaterial für Kunden erstellt, um die Verwendung dieses Toolings so einfach wie möglich zu gestalten.
Ausgehend vom aktuellen Stand gibt es zudem Pläne, das Tooling zukünftig noch zu erweitern, um beispielsweise Security-Advisories für neue Schwachstellen zu erzeugen, damit Nutzer schnell feststellen können, ob sie von einer neuen Schwachstelle überhaupt betroffen sind.
Parallel zu den eher praktischen Tätigkeiten wurde zudem auch auf organisatorischer und rechtlicher Ebene weitergearbeitet. Wir haben keine neue Abteilung oder ein spezielles Team eingerichtet, sondern die jeweiligen Verantwortlichen eines Produkts entsprechend vorbereitet, um sie zu befähigen, die jeweils relevanten Themen mit in die Prozesse zu integrieren. Ferner galt ein Augenmerk den rechtlichen Fragestellungen, auch in enger Zusammenarbeit mit dem TÜV-Süd: Sind wir durch unsere Open-Source-Lösungen mit GPLv3 Lizenz mit Option einer kommerziellen Lizenz ein “Manufacturer” oder nicht? In welche Produktkategorie sind wir einzuordnen? Wie und wann genau müssen wir Vulnerabilities melden?
Sämtliche dieser Fragen konnten mittlerweile mehr oder weniger im Rahmen der aktuellen Gesetzeslage und dem Maß an verfügbaren Informationen beantwortet werden. Durch die Monetarisierung bei kommerziellen Kunden sind wir ein Hersteller und haben damit mehr Verpflichtungen als in der Rolle als Open-Source-Projekt. Allerdings gelten diese erweiterten Verpflichtungen nur gegenüber den kommerziellen Kunden. Als Pflichten gelten ja das Bereitstellen von Sicherheitsupdates über den Unterstützungszeitraum hinweg. Die Einstufung erfolgte in die Standardkategorie, also Konformitätsbewertung über das Verfahren der internen Kontrolle (Modul A) und damit Selbstbewertung, was allerdings unabhängig von der Einstufung unserer Nutzer und Kunden ist. Es kann sehr gut möglich sein, dass ein Nutzer von wolfSSL Produkten mit seinen eigenen Produkten höher einzustufen ist. Das Thema Vulnerability Management ist zweigeteilt: einerseits unterliegen nur “aktiv ausgenutzte Schwachstellen” den Meldepflichten gegenüber dem als Koordinator benannten CSIRT.
EC: Aber auch schwerwiegende Sicherheitsvorfälle. Art 14 Abs 3…
TF: Unserem Verständnis nach sind Sicherheitsvorfälle aber nur tatsächlich eingetretene „Events“, worunter „geheime“ Meldungen von Vulnerabilities nicht fallen, auch wenn diese kritisch sind. Wir würden nur Events dahingehend einstufen, dass uns bzw. generell öffentlich gemeldet wird, dass wolfssl diese oder jene kritische Schwachstelle hat, oder dass ein Kunde uns meldet, dass es bei ihm einen Vorfall gab, der aus einer Lücke bei uns resultiert. Vulnerabilities, die im Rahmen einer koordinierten Offenlegung („responsible disclosure“) an uns gemeldet werden, unterliegen nicht der Meldepflicht und durchlaufen den gewohnten Disclosure-Prozess im Rahmen eines Software-Releases. Andererseits sind wir hierbei aber dran, den Prozess so „angenehm wie möglich“ für unsere Nutzer zu gestalten, sodass sie auch mithilfe der SBOMs schnell auf Schwachstellen reagieren können.
EC: Wie kommunizieren Kunden mit Euch? Laden sie sich die Software und Patches aus einem Git? Musstet Ihr Prozesse umstellen?
TF: Der Open-Source-Code liegt komplett auf Github. Kommerzielle Kunden bekommen pro Release ein Archiv mit dem Code bereitgestellt. Open Source und kommerzieller Code sind einhundert Prozent identisch: exklusive der Lizenz-Header-Kommentare ganz oben in den Dateien. Das Disclosure von Vulnerabilities erfolgt mit einem Release über die Release Notes. Zudem werden die Vulnerabilities auch auf unserer Webseite veröffentlicht. Kommerzielle Kunden mit Supportvertrag erhalten zudem vor einem anstehenden Release bereits eine Liste mit den Vulnerabilites. Über den Supportvertrag ist die Vertraulichkeit geregelt, also ist das keine öffentliche Disclosure. Es kann gut sein, dass sich hier in Zukunft noch Prozesse verändern werden, um es den Kunden noch einfacher zu machen, an die Infos zu kommen. Da es hier aber aktuell zig verschiedene Verfahren und Lösungen bzw. Wege gibt, warten wir hier aktuell noch, bis sich ein klarer Pfad ergibt, den die Kunden dann auch wirklich langfristig verwenden wollen/können.
EC: Was waren die major challenges?
TF: Aus technischer und praktischer Sicht war die bisher größte Herausforderung, die SBOM-Generierung so umzusetzen, dass sie mit möglichst geringem Aufwand für all unsere Produkte und deren Konfigurationsmöglichkeiten geeignet ist. Aus Prozesssicht sowie aus regulatorischer Sicht war und ist die größte Hürde die Informationsgewinnung und ihre Auswertung.
EC: Damit meint Ihr sicher das Problem, dass es noch keine sicheren Aussagen zu allen Themen gibt, oder?
TF: Genau. Da sich vieles noch im Erarbeitungsprozess befindet und noch nicht final ist, können sich Informationen immer noch ändern. Und das kann neue Anforderungen mit sich bringen.
EC: Nutzt Ihr bei SBOM auch offene Tools (syft, cdxgen, cycloneDX, Format: spdx)?
Unser make-sbom-Skript in allen Produkten erzeugt sowohl SPDX als auch CycloneDX-SBOM-Dateien, die dann entweder als eigenständiges Dokument in einer Produkt-SBOM referenziert oder copy-paste in die große SBOM kopiert werden können.
EC: Haben US Exekutivanordnung 14028, oder die Regelung von so genannten Minimum Elements, die von der National Telecommunications and Information Administration herausgegeben wurde, eine Rolle bei der Umsetzung der SBOM-Problematik geholfen?
Nicht maßgeblich. Der wesentliche treibende Faktor war der CRA, aber die NTIA Minimum Elements waren eine Baseline für die SBOMs, an die wir uns angelehnt haben. Die EO 14028 wurde zu Kenntis genommen, hat sich hier aber in die generelle Landschaft an SBOM-Empfehlungen eingereiht.
Tobias Frauenschläger
Tobias Frauenschläger ist Software-Entwickler bei wolfSSL seit Januar 2026. Seine Schwerpunkte sind TLS und angewandte Kryptografie auf Embedded Geräten sowie Post-Quantum-Kryptografie. Zuvor hat er zum Thema Kryptoagilität und Post-Quantum-Kryptografie in der Betriebstechnik an der OTH Regensburg in Zusammenarbeit mit der FAU Erlangen promoviert.
1 S. https://easycra.net/2026/05/04/alles-sbom-oder-was/.
2 S. https://www.wolfssl.com/wolfssl-announces-full-support-for-eu-cyber-resilience-act-cra-security-requirements-for-connected-and-embedded-devices/.