CRA Preparations: What Software Manufacturers Must Do Before the Cyber Resilience Act Applies
CRA Preparations: Was Software-Hersteller noch tun müssen, bevor der CRA greift
Die Uhr tickt – Warum der CRA kein regulatorisches Hintergrundrauschen ist
Ich erlebe es regelmäßig in Gesprächen mit Sicherheitsverantwortlichen: Der Cyber Resilience Act wird erwähnt, genickt wird pflichtbewusst, und dann kehrt man zur Tagesordnung zurück. Das ist ein Fehler, den sich Softwarehersteller schlicht nicht leisten können.
Der CRA wurde im Oktober 2024 im Amtsblatt der EU veröffentlicht. Die Übergangsfristen sind definiert: Melde- und Überwachungspflichten gelten ab September 2026 - das sind jetzt noch D R E I Monate - die vollständigen Anforderungen ab Dezember 2027. Das klingt nach Spielraum. Ist es aber nicht — denn wer heute noch keine strukturierte Inventarisierung seiner Software-Komponenten betreibt, hat schlicht zu spät angefangen.
Die Bußgeldrahmen sprechen eine klare Sprache: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die wesentlichen Anforderungen. Bei wiederholtem Verstoß, kann es zum Marktausschluss führen. Zum Vergleich: Die DSGVO-Bußgelder, die Unternehmen jahrelang als abstrakte Bedrohung behandelten, haben sich inzwischen in der Realität materialisiert. Wer glaubt, der CRA verlaufe ähnlich folgenlos, sollte sich die Konsequenzen zweimal überlegen.
Was der CRA konkret fordert – Ein nüchterner Blick auf die Pflichten
Der CRA adressiert Hersteller von Products with Digital Elements, also im Wesentlichen jede Software und jedes hardwarenahe Produkt, das in vernetzten Umgebungen betrieben wird. Die Anforderungen lassen sich auf einige Kernpunkte verdichten:
- Security by Design: Sicherheit muss von Anfang an im Entwicklungsprozess verankert sein, nicht nachträglich aufgesetzt
- Schwachstellenmanagement: Hersteller müssen Schwachstellen über den gesamten Produktlebenszyklus aktiv identifizieren und beheben
- Sichere Standardkonfigurationen: Produkte dürfen nicht mit unsicheren Werkseinstellungen ausgeliefert werden
- Transparenzpflichten: Gegenüber Behörden und Nutzern müssen Sicherheitseigenschaften nachvollziehbar dokumentiert werden
Die SBOM — Software Bill of Materials — ist im CRA-Text nicht explizit vorgeschrieben. In der Praxis ist diese Unterscheidung jedoch akademisch. Ohne maschinenlesbare Komponentenliste lässt sich kein glaubwürdiger Nachweis führen, dass man tatsächlich weiß, was im eigenen Produkt steckt.
Wer sich noch nicht sicher ist, wo das eigene Unternehmen in Bezug auf CRA-Compliance steht, kann sich mit dem kostenlosen Tool unter cra-support.eacg.de durch einen strukturierten Fragebogen führen lassen. Die Firmen EACG und metaeffekt haben dort ihre Best Practices aus der MetaTrust-Methode in eine frei zugängliche Online-Lösung überführt — das Ergebnis ist eine priorisierte Aufgabenliste, die konkrete nächste Schritte liefert.
SBOM als Fundament – Warum ohne Komponententransparenz nichts geht
Eine vollständige, maschinenlesbare SBOM ist nicht Mittel zum Zweck — sie ist die Grundvoraussetzung dafür, überhaupt handlungsfähig zu sein. Wer nicht weiß, welche Open-Source-Bibliotheken, Transitivabhängigkeiten und Lizenzmodelle in seinen Produkten stecken, kann weder Schwachstellen systematisch adressieren noch behördliche Nachweispflichten erfüllen.
Bei der Formatfrage steht die Branche vor einer strategischen Entscheidung: CycloneDX oder SPDX? Beide Formate sind etabliert, beide werden von gängigen Tools unterstützt. Im CRA-Kontext hat CycloneDX jedoch einen pragmatischen Vorteil: Es wurde explizit für Security-Anwendungsfälle entwickelt, unterstützt VEX-Dokumente nativ und bildet Schwachstelleninformationen strukturierter ab. SPDX hingegen dominiert traditionell den Lizenz-Compliance-Bereich und ist als ISO-Standard (ISO 5962) formal breiter anerkannt. Die Entscheidung hängt vom primären Verwendungszweck ab — für Organisationen, die beides brauchen, bieten reife Plattformen heute Konvertierung zwischen den Formaten an.
Entscheidend ist aber ein anderer Punkt: Die SBOM darf kein einmaliges Audit-Artefakt sein. Sie muss kontinuierlich im CI/CD-Prozess generiert werden. Jeder Build, jede Abhängigkeitsänderung, jedes neue Release — der SBOM-Stand muss aktuell sein. Wer das als nachgelagerten Schritt behandelt, produziert Dokumente, die im Ernstfall nicht die Realität abbilden.
Software Composition Analysis – Schwachstellen finden, bevor andere es tun
SCA-Tools scannen Abhängigkeiten gegen bekannte Schwachstellendatenbanken — NVD, OSV, GitHub Advisory Database. Das ist unter dem CRA keine optionale Hygienemaßnahme mehr, sondern regulatorische Pflicht. Die Herausforderung liegt dabei weniger in der Technologie als in der Handhabbarkeit der Ergebnisse.
Wer schon einmal einen rohen CVE-Report eines größeren Projekts gesehen hat, weiß: Die Liste ist lang, und viele der gemeldeten Schwachstellen betreffen Code, der im konkreten Produktkontext gar nicht erreichbar ist. Ohne Reachability-Analyse überlasten solche Berichte Sicherheitsteams mit False Positives und lähmen die Priorisierung. Moderne SCA-Werkzeuge, die kontextsensitiv analysieren — also tatsächlich prüfen, ob verwundbare Codesegmente im Aufrufpfad liegen — reduzieren dieses Rauschen erheblich.
Noch wichtiger als die Erkennung ist aber der Prozess dahinter: SCA-Ergebnisse müssen in ein nachvollziehbares Risikomanagement münden. Ein Remediation-Prozess mit klarem Audit-Trail ist nicht nur für interne Steuerung relevant — er ist der Nachweis gegenüber Behörden, dass Schwachstellen systematisch und nicht ad hoc bearbeitet werden.
Vulnerability Disclosure und Meldepflichten – Der CRA schreibt Tempo vor
Hier wird es für viele Organisationen unbequem. Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an ENISA gemeldet werden. Nicht 48 Stunden, nicht "zeitnah" — 24 Stunden. Ein solches Zeitfenster ist ohne automatisierte Monitoring-Infrastruktur schlicht nicht einzuhalten, wenn gleichzeitig noch Einschätzung, Klassifizierung und interne Eskalation stattfinden müssen.
Das bedeutet: Hersteller brauchen heute definierte Coordinated Vulnerability Disclosure (CVD)-Prozesse, die sowohl CRA-Anforderungen als auch bestehenden Standards wie ISO/IEC 29147 genügen. Das ist keine Frage von Werkzeugen allein — es ist eine organisatorische Frage, die Rollen, Eskalationspfade und Kommunikationskanäle klärt. Das Carnegie Mellon CERT hat entsprechende Best Practises im “Vultron”-Protokoll definiert. EACG hat diese in TrustSource implementiert.
VEX-Dokumente (Vulnerability Exploitability eXchange) sollen dabei die Kommunikation gegenüber Kunden und Behörden standardisieren: Ist eine bekannte Schwachstelle im eigenen Produkt tatsächlich ausnutzbar? Unter welchen Bedingungen? Wann ist ein Fix verfügbar? In der Theorie ist das ein elegantes Instrument. In der gelebten Praxis klaffen Anspruch und Realität noch weit auseinander — zu wenige Hersteller erstellen VEX-Dokumente systematisch, zu wenige Abnehmer wissen damit umzugehen. Für die Verteilung ist der Betrieb eines CSAF-Providers, der vom BSI-Lister erfasst wird, eine ideale Voraussetzung.
License Compliance im CRA-Kontext – Der unterschätzte Risikofaktor
Neben den Sicherheitsanforderungen lauert ein zweiter Risikofaktor, den Compliance-Teams häufig unterschätzen: Open-Source-Lizenzen. GPL, LGPL, AGPL — diese Lizenzen können bei kommerziellen Produkten Pflichten auslösen, die über den CRA hinausgehen. Eine AGPL-lizenzierte Komponente in einem SaaS-Produkt kann etwa Copyleft-Pflichten auslösen, die den gesamten Quellcode betreffen. Das ist kein theoretisches Szenario — es ist ein reales Risiko, das bei fehlender Inventarisierung unbemerkt in Produkte einzieht.
Automatisierte Lizenzerkennung und Policy-Enforcement im Build-Prozess sind hier der einzig praktikable Ansatz. Manuelle Audits skalieren nicht, wenn Abhängigkeitsbäume hunderte von Komponenten umfassen.
Der strategische Vorteil: SBOM-Daten dienen gleichzeitig als Basis für License-Audits. Ein Artefakt, zwei regulatorische Zwecke. Wer seine SBOM-Infrastruktur einmal sauber aufgebaut hat, vermeidet Doppelarbeit zwischen Sicherheits- und Rechtsabteilung.
Handlungsempfehlungen – Was Teams jetzt konkret tun können
Die verbleibende Zeit bis September 2026 klingt nach ausreichend Puffer. Sie ist es nicht, wenn man die Vorlaufzeiten für Prozessänderungen, Tool-Implementierungen und organisatorische Anpassungen realistisch einkalkuliert. Meine Empfehlung für Sofortmaßnahmen:
- SBOM-Generierung anstoßen: Für alle aktiven Produkte, automatisiert im CI/CD, heute — nicht nach dem nächsten Planungszyklus
- SCA in bestehende Pipelines integrieren: Mit Priorisierungslogik, nicht als rohe CVE-Dump-Lösung
- Meldeprozesse für Schwachstellen definieren: Klare Rollen, definierte Eskalationspfade, Zeitfenster eingeübt
- Lizenzchecks automatisieren: Policy-Regeln im Build-Prozess verankern, nicht als nachgelagerten Audit
Wer diese Prozesse nicht mit vielen, separaten Werkzeugen koordinieren möchte, findet in Plattformen wie TrustSource einen integrierten Ansatz für SBOM-Management, Software Composition Analysis und License Compliance. Das reduziert nicht nur Werkzeugkomplexität, sondern schafft auch die Datengrundlage für konsistente Nachweise gegenüber Behörden.
Der CRA ist kein Endpunkt regulatorischer Anforderungen — er ist deren Ausgangslage. Organisationen, die jetzt in eine belastbare Supply-Chain-Security-Infrastruktur investieren, bauen etwas auf, das auch künftige Anforderungen trägt. Wer wartet, kauft sich nur Zeit — und zahlt sie teuer.
Zur Person
Freier Tech-Journalist, promovierter Wirtschaftsinformatiker. Recherchiert zu Software Supply Chain Security und SBOM-Adoption.
Gastbeitrag. Dr. Brenner ist freier Journalist. Keine Vergütung für diesen Beitrag.
Why Every Software Team Needs an SBOM Strategy in 2026
Warum jedes Software-Team ab 2026 eine SBOM-Strategie braucht
Der Moment, der alles verändert hat
Es war ein Dienstagmorgen im April 2024. Eine Mail vom Risikomanagement landet in meinem Postfach: „Stefan, seid ihr von der XZ-Utils-Backdoor betroffen? Wir brauchen bis heute Mittag eine Antwort."
Ich kenne Kollegen aus anderen Unternehmen, die in diesem Moment schweißgebadet vor ihren Laptops saßen und händisch durch ihre Repo-Landschaft gegraben haben. Bei uns: ein einziger Bericht in TrustSource, Filterung auf das betroffene Package, Abgleich gegen unsere SBOM-Snapshots – keine drei Minuten, und ich hatte eine vollständige Antwort für alle 120 aktiven Produkte.
Das ist der Unterschied zwischen SBOM als lebendigem Betriebsmittel und dem klassischen „wir haben da irgendwo eine Inventarliste als Excel". Als XZ einschlug, waren CRA und NIS2 für viele noch abstrakte Brüsseler Konzepte. Heute sind sie Realität. Und wer kein strukturiertes SBOM-Management hat, hat ab 2026 nicht nur ein Compliance-Problem - er hat ein operatives Problem.
Der Paradigmenwechsel, den wir in unserem OSPO durchgemacht haben: SBOM ist kein PDF für den Auditor. Es ist das Nervensystem unserer Supply-Chain-Hygiene.
Was die Regulierung konkret verlangt - und was sie nicht sagt
Der Cyber Resilience Act macht maschinenlesbare SBOMs für alle „Products with Digital Elements" zur Pflicht - und zwar ab Markteintritt, nicht erst wenn der Auditor anklopft. Das ist ein fundamentaler Unterschied zu dem, was viele noch erwarten. Es geht nicht um eine einmalige Dokumentationsübung, sondern um einen kontinuierlichen Nachweis.
NIS2 erhöht den Druck auf kritische Lieferketten nochmals: Betroffene Organisationen müssen nachweisen können, welche Komponenten sie einsetzen und wie deren aktueller Vulnerability-Status aussieht. Ohne SBOM ist das schlicht nicht skalierbar.
Eine gute, erste Orientierung gibt die BSI TR-03183, die konkret definiert, was in einer SBOM stehen sollte: von SPDXID und Lizenzinformationen bis hin zu Relationship-Typen zwischen Komponenten. Praktisch hilfreich – aber in unserem Setup ist das längst automatisiert. TrustSource erzeugt SBOMs, die diese Anforderungen out-of-the-box erfüllen. Kein manueller Nachbau erforderlich.
SBOM-Inhalte nach BSI TR-03183 – was wirklich drinsteht
Die Pflichtfelder laut TR-03183 Tier 1 und 2 klingen zunächst überschaubar: Package Name, Version, Supplier, Unique Identifier (PURL oder CPE), Declared License, Copyright. Trivial? In der Praxis fehlen bei Legacy-Komponenten regelmäßig 30 bis 40 Prozent dieser Felder – das sehe ich in jedem SBOM-Audit, den wir bei Neuprojekten durchführen.
Deshalb haben wir ein hartes Quality-Gate eingeführt: Kein Merge ohne grünes Häkchen in TrustSource. Die Pipeline prüft automatisch, ob alle TR-03183-relevanten Felder befüllt sind. Was früher eine manuelle Compliance-Prüfung war, die Wochen gedauert hat, ist heute ein automatisierter Check, der Sekunden braucht.
Das SBOM als lebendiges Betriebsmittel – nicht als Momentaufnahme
Das größte Missverständnis, das ich immer noch höre: „Wir machen das einmal pro Release." Das ist ungefähr so hilfreich wie ein Feuerlöscher, den man am Eingang eines großen Gebäudes positioniert.
In unserem Setup erzeugt jeder CI/CD-Build einen neuen SBOM-Snapshot, der automatisch in TrustSource abgelegt wird. Das hat zwei unmittelbare Vorteile:
Erstens erkennen wir Komponentendrifts sofort. TrustSource schlägt sogar Alarm bei unerwarteten Version-Jumps – genau das Muster, das bei Dependency-Confusion-Attacks auftritt. Dieser Angriffsvektor ist subtil und ohne automatisierte SBOM-Überwachung kaum zu entdecken.
Zweitens ist die Vulnerability-Korrelation in Echtzeit möglich. Neue CVEs werden automatisch gegen unsere SBOM-Daten geprüft. Bei Log4Shell hatten wir innerhalb von 5 Minuten eine vollständige Betroffenheitsliste – für alle 120 Produkte gleichzeitig. Exakt klar, ab bzw. Bis zu welcher Version Produkte betroffen waren. Kein manuelles Durchsuchen, kein Raten.
Ein weiterer Effekt, den ich anfangs unterschätzt habe: Wir liefern unseren OEM-Kunden heute maschinenlesbare CycloneDX-Files on-demand. Was als Compliance-Overhead begann, ist inzwischen ein echtes Verkaufsargument geworden. Kunden aus dem Automotive- und Industrieumfeld fragen aktiv danach.
Supply-Chain-Risiko greifbar machen – Zahlen aus unserem Setup
Nach drei Jahren produktivem Einsatz von TrustSource haben wir belastbare Daten. Ein paar Zahlen, die ich regelmäßig im Management-Reporting verwende:
- 68 % unserer Komponenten sind transitiv. Wer nur die direkten Dependencies kennt, ist blind für den größten Angriffsvektor. Ohne vollständigen Dependency-Graph ist Supply-Chain-Security eine Illusion.
- Lizenz-Compliance-Findings sind um über 80 % gesunken, seit wir Policy-as-Code im SBOM-Workflow betreiben. Entwickler bekommen das Feedback direkt in der Pipeline – nicht sechs Wochen später im Legal-Review.
- Time-to-Detect bei kritischen Findings (CVSS ≥ 9.0 mit bekanntem Exploit) ist von durchschnittlich 12 Tagen auf unter 4 Stunden gesunken. Das ist der Unterschied zwischen einem kontrollierten Incident-Response-Prozess und einer Krisennacht.
Häufige Stolpersteine beim SBOM-Aufbau – und wie wir sie gelöst haben
„Wir haben zu viele Repos." Das höre ich oft als Argument, warum der Start zu komplex sei. Meine Antwort: Fang nicht mit dem gesamten Portfolio an. SBOM-Abdeckung von 20 % der richtigen Assets – also produktionskritische Services, alles was nach außen exponiert ist – bringt mehr als 100 % Coverage auf internen Testprojekten.
Tool-Fragmentierung ist ein echtes Problem. Unterschiedliche Scanner erzeugen inkonsistente PURLs, und wenn du SBOMs aus drei verschiedenen Tools konsolidieren willst, hast du schnell Chaos. Normalisierung ist Pflicht, bevor du anfängst zu aggregieren. TrustSource übernimmt das automatisch – wer es ohne Plattform lösen will, kann auch ts-scan auf GitHub als Open-Source-Basis nutzen.
Organisatorischer Widerstand ist ein oft unterschätzter Stolperstein. Der klassische Fehler: Das SBOM-Thema ins Compliance-Team schieben und hoffen, dass es von dort aus skaliert. Bei uns hat es erst funktioniert, als wir das Thema ins Security-Champion-Programm integriert haben. Wenn Entwickler sehen, dass sie dank SBOM eine Vulnerability-Triage in Minuten statt Tagen durchführen können, braucht es keine Überzeugungsarbeit mehr.
Fazit & nächste Schritte: Dein SBOM-Fahrplan für 2026
Drei Maßnahmen, die ich jedem Team empfehle – und die sich alle drei in einem einzigen Sprint umsetzen lassen:
- BSI TR-03183 als Qualitätsmaßstab adoptieren. Nicht als bürokratische Pflichtübung, sondern als konkretes Qualitätskriterium für jede erzeugte SBOM.
- SBOM-Erzeugung in jede CI/CD-Pipeline integrieren. Jeder Build, jeder Snapshot, automatisch abgelegt. Keine Ausnahmen.
- Vulnerability-Matching automatisieren. Manuelles CVE-Tracking ist 2026 keine Option mehr.
2026 wird das Jahr, in dem Kunden und Behörden SBOMs nicht mehr nett finden, sondern aktiv einfordern – als Vertragsbestandteil, als Lieferbedingung, als regulatorischen Nachweis. Wer jetzt in seine SBOM-Infrastruktur investiert, liefert dann auf Knopfdruck. Wer wartet, wird unter Zeitdruck nachrüsten müssen.
Der beste Zeitpunkt, mit einer SBOM-Strategie anzufangen, war vor zwei Jahren. Der zweitbeste ist jetzt.
Wenn du deinen eigenen SBOM-Reifegrad einschätzen willst, ohne monatelange Evaluierung: Eine TrustSource-Demo dauert 30 Minuten und zeigt dir konkret, wo du stehst und was der nächste realistische Schritt ist. Genau das hätte ich mir gewünscht, bevor ich selbst angefangen habe.
Anwender-Erfahrungsbericht. Endkunde von TrustSource. Nicht vergütet.
TrustSource ergänzt EoL-Information
EoL bezeichnet den Zeitpunkt, ab dem ein Softwareprodukt oder eine Komponente vom Hersteller nicht mehr gepflegt wird. Keine Sicherheitsupdates. Keine Bugfixes. Kein Support. Wer EoL-Software einsetzt, betreibt de facto ein offenes Scheunentor – und das vollkommen legal, aber höchst riskant.
Das hat mehrere Implikationen:
- Sicherheit: Bekannte Schwachstellen bleiben dauerhaft ungepatcht. Jede neue CVE-Meldung kann zum existenziellen Risiko werden – ohne Gegenmittel.
- Betrieb: EoL-Komponenten verlieren die Kompatibilität mit modernen Systemen, Bibliotheken und Schnittstellen. Was heute noch funktioniert, kann morgen kritische Prozesse lahmlegen.
- Compliance:
Mit dem Cyber Resilience Act (CRA) der EU, der 2024 in Kraft getreten ist und dessen Pflichten bis 2027 schrittweise greifen, wird EoL zur regulatorischen Kernfrage.
Der CRA verpflichtet Hersteller digitaler Produkte zu:
-
Transparenz über Supportzeiträume – vor dem Kauf, verständlich kommuniziert
-
Mindest-Support von fünf Jahren (oder der erwarteten Produktlebensdauer)
-
Kostenlose Sicherheitsupdates während der gesamten Supportperiode
-
Klare Abkündigungsprozesse mit ausreichend Vorlaufzeit und Migrationspfaden
Das ist ein Paradigmenwechsel: EoL ist keine interne Produktentscheidung mehr, sondern eine regulierte Verpflichtung mit Rechtsfolgen. Hersteller, die zu kurze Support-Zeiträume deklarieren, müssen diese gegenüber Marktaufsichtsbehörden rechtfertigen.
Wollen Sie wissen, welche Auswirkungen der CRA auf Ihren Software-Entwicklungsprozess haben wird? Nutzen Sie unsere kostenlose Impact-Analyse!
Moderne IT-Landschaften umfassen Tausende von Softwarekomponenten. Da dies kein Mensch mehr manuell managemenn kann oder will, entwickeln sich derzeit zwei Ansätze, um die Sache maschinenlesbaren abzubilden:
- EoX (Cisco/OASIS): Ein strukturiertes Datenmodell mit definierten Meilensteinen – von End of Sale über End of Security Support bis End of Service Life. Automatisierte Asset-Management-Systeme lesen diese Daten und können proaktiv warnen.
- CycloneDX (OWASP): Der Standard für Software Bills of Materials (SBOMs) bildet Lifecycle-Phasen strukturiert ab: von aktiver Entwicklung bis EoL. Wenn ein Bibliotheks-Maintainer EoL im SBOM deklariert, erben alle nachgelagerten Nutzer automatisch diese Information.
EoL betrifft nicht nur Betriebssysteme – es betrifft Open-Source-Bibliotheken, Frameworks, Middleware, Container-Images und kommerzielle Komponenten gleichermaßen. In einem durchschnittlichen Unternehmens-Portfolio laufen mehr EoL-Komponenten, als die meisten IT-Teams ahnen.
Um dies zu adressieren, sollte jedes Führungsgremium die folgenden Fragen an die Entwicklung stellen:
-
Haben wir EoL-Komponenten im Einsatz?
-
Welche erreichen in den nächsten 6–12 Monaten ihr EoL?
-
TrustSource hat EoL-Monitoring in seine Software-Supply-Chain-Security-Plattform integriert.
Die Plattform aggregiert teils automatisiert, teils manuell ergänzt, EoL-Daten aus verschiedenen Quellen – für Komponenten und Distributionen gleichermaßen – und stellt diese direkt im Kontext der Projekte zur Verfügung. Das bedeutet konkret:
- Policy-basierte Alerts: Jedes Projekt in TrustSource kann individuelle Richtlinien definieren – etwa eine Warnung 9 Monate vor EoL und eine Verletzungsmeldung 2 Monate vor EoL. So erreichen Warnungen die Verantwortlichen, bevor das Fenster zum Handeln schließt.
- Portfolio-Reports für die Führungsebene: CISOs und zentrale Sicherheitsverantwortliche können mit einem einzigen Report das gesamte Portfolio oder einzelne Projekte auf EoL-Risiken screenen. Transparenz auf Knopfdruck – für fundierte Entscheidungen und Compliance-Nachweise.
- Downstream-API:
Der Cyber Resilience Act macht EoL zur Chefsache. Maschinenlesbare Standards erlauben es, die Herausforderung zu beherrschen. Und Plattformen wie TrustSource operationalisieren diese Informationen – automatisiert, kontinuierlich, skalierbar.
Die Frage ist nicht ob EoL-Risiken in Ihrem Portfolio schlummern. Die Frage ist:
Möchten Sie wissen, wie Sie die EOL-Informationen optimal in ihren Prozess integrieren?
PostQuantumGefahr
DER STILLE STURM: WIE SIE DIE POST-QUANTUM-KRYPTOGRAPHIE-GEFAHR MEISTERN
In der digitalen Welt halten wir unsere „Verschlüsselung“ – die Algorithmen, die unsere Banküberweisungen, Staatsgeheimnisse und privaten Nachrichten sichern – oft für unüberwindbar. Jahrzehntelang war dies auch der Fall. Doch am Informatik-Horizont braut sich ein stiller Sturm zusammen: das Aufkommen von kryptoanalytisch relevanten Quantencomputern.
Die Quantenbedrohung: Das Unknackbare knacken
Aktuelle kryptografische Standards wie RSA und Elliptic Curve Cryptography (ECC) basieren auf mathematischen Problemen, deren Lösung für klassische Computer unmöglich ist (z. B. die Faktorisierung großer Primzahlen). Ein Quantencomputer, der die Prinzipien der Superposition und Verschränkung nutzt, kann Informationen auf eine Weise verarbeiten, die für klassische Maschinen unmöglich ist.
Insbesondere ermöglicht der Shor-Algorithmus einem ausreichend leistungsfähigen Quantencomputer, diese asymmetrischen „Schlösser” innerhalb von Minuten zu knacken. Daraus entsteht ein Risiko, das man mit der Bezeichnung „jetzt ernten, später entschlüsseln” beschreibt: Angreifer könnten heute verschlüsselte Daten erfassen, bzw. einsammeln und darauf warten, dass die Technologie ausgereift ist, um sie in Zukunft zu entschlüsseln.
Lehren aus der Geschichte: Die Qualen des Übergangs
Wir haben das schon einmal erlebt, allerdings noch nie mit so hohen Einsätzen. Historische Übergänge bieten jedoch eine warnende Lehre:
- DES zu AES: Als der Data Encryption Standard (DES) Ende der 90er Jahre geknackt wurde, dauerte die Umstellung auf den Advanced Encryption Standard (AES) fast ein Jahrzehnt.
- SHA-1-Abkündigung: Die Abkehr vom SHA-1-Hashing-Algorithmus (nachdem er als anfällig erkannt wurde) wurde durch „Zombie“-Systeme erschwert, die den unsicheren Standard noch jahrelang weiterverwendeten, was zu weit verbreiteten Schwachstellen führte.
- Der Y2K-Vergleich: Wie bei Y2K gibt es auch bei der PQC-Migration eine „Frist“, die durch den Fortschritt der Hardware vorgegeben ist. Im Gegensatz zu Y2K kennen wir jedoch nicht das genaue Datum, an dem die Uhr „12“ schlägt. Eine Näherung s.bspw. Quantum doom clock.
Die größte Herausforderung bei diesen historischen Veränderungen war nicht die neue Mathematik, sondern die Sichtbarkeit. Unternehmen wussten oft nicht, wo ihre Kryptografie „fest codiert” war, was Updates zu einem manuellen, fehleranfälligen Albtraum machte, bei dem man sich durch Legacy-Code und Hardware kämpfen musste.
Die Lösung: Kryptografische Agilität
Globale Sicherheitsexperten, Kryptografie-Wissenschaftler und inzwischen auch das US-Kriegsministerium in einem Memo an seine Führung im vergangenen November fordern einen pro-aktiven Ansatz: Kryptografische Agilität.
Krypto-Agilität ist die Fähigkeit eines Informationssystems, zwischen kryptografischen Algorithmen zu wechseln, ohne dass dafür erhebliche Änderungen an der Infrastruktur oder umfangreiche Code-Neuprogrammierungen erforderlich sind. Anstatt „angeschraubt“ zu sein, wird Sicherheit modular. Dieser Ansatz ist aus folgenden Gründen unerlässlich:
- Algorithmen entwickeln sich weiter: Da das NIST PQC standardisiert, müssen die ersten Versionen möglicherweise aktualisiert werden, wenn neue Schwachstellen entdeckt werden.
- Hybridisierung: Bei der Migration müssen während einer Übergangsphase häufig ältere und quantenresistente Algorithmen parallel ausgeführt werden.
- Zukunftssicherheit: Ein agiles System kann sich an die nächste Bedrohung anpassen, ohne dass ein mehrjähriger „Rip-and-Replace“-Zyklus erforderlich ist.
Um dies zu erreichen, müssen Unternehmen zunächst ein umfassendes Kryptografie-Inventar erstellen und dabei jede Instanz der Verschlüsselung in nationalen Sicherheitssystemen, Cloud-Assets und IoT-Geräten identifizieren.
„ Seien Sie der Zeit voraus. Sichern Sie noch heute Ihre digitale Zukunft
Machen Sie den nächsten Schritt mit TrustSource
Die Umstellung auf Post-Quantum-Kryptografie (PQC) muss keine Reise ins Ungewisse sein. TrustSource bietet die Tools und das Fachwissen, um sicherzustellen, dass Ihre Software Lösungen widerstandsfähig bleiben.
- TrustSource Cryptographic Discovery Services:
Wir helfen Ihnen dabei, Ihre aktuelle kryptografischen Algorithmen zu identifizieren, zu inventarisieren und zu bewerten, um einen Risiko-orientierten Weg zur Quantenresistenz zu entwerfen. - TrustSource SBOM-Bestands- und Compliance-Workflows:
Speichern Sie Ihre SBOMs im TrustSource-Bestand oder nutzen Sie die Genehmigungs-Workflows, um die Risiken vor der Veröffentlichung Ihrer Software zu verwalten. Dokumentieren Sie die Existenz und Verwendung von Kryptoalgorithmen auf der Grundlage unseres Komponenten-Know-hows, sei es für Exportkontrollen oder Ihre Krypto-Agility-Implementierungen. - TrustSource Crypto Reporting:
Profitieren Sie von der Portfolio-weiten Analyse der verwendeten Kryptoalgorithmen und definieren Sie Migrationsstrategien auf der Grundlage von Komponenten und Portfolio-Risiken. - TrustSource Crypto Policies:
Verwenden Sie Richtlinien, um die Implementierung und/oder Verwendung schwacher Algorithmen im gesamten Unternehmen direkt in beim Bau der Software zu verhindern.
Wollen Sie mehr zu dem Thema erfahren?
Cyber Resilience Act veröffentlicht
EU Cyber Resilience Act veröffentlicht
Heute wurde der EU Cyber Resilience Act (CRA) veröffentlicht. Damit sind seine Gültigkeit und der Zeitplan festgeschrieben, da sich aus dem Veröffentlichungsdatum die entsprechenden Daten für die Umsetzung ergeben: Beginn der tatsächlichen Gültigkeit – also der Zeitpunkt, ab dem jeder Software-Hersteller oder Vertreter eines solchen, der in der EU eine Software auf den Markt bringt, sich konform verhalten muss – ist der 11. Dezember 2027.
Genauer: Die Regelungen, insbesondere Art. 13 sowie Anhang I und II, gelten für alle Produkte mit digitalen Elementen, die ab diesem Termin in der EU auf den Markt kommen. Für Produkte, die vor diesem Termin auf den Markt kommen oder gebracht wurden, gelten die Anforderungen, sobald sie nach dem Termin wesentliche Änderungen erfahren, s. Art. 69 II CRA. Die Berichtserfordernisse aus Art. 14 sind jedoch für alle Produkte bereits ab dem 11. September 2026 zu bedienen, unabhängig vom Termin des Markteintritts (Art. 69 III CRA).
Von jetzt an zählt die Übergangsfrist, bis zu der sich Software-Anbieter mit den neuen Anforderungen auseinandersetzen, bzw. diese umsetzen müssen. Die Umsetzung ist stellenweise nicht trivial und erfordert einiges an organisationalem Wandel, bspw. die Aufnahme ggf. noch nicht vorhandener Risikoanalysen und -bewertungen in den Release-Prozess, die Deklaration von Unterstützungszeiträumen oder den Aufbau geeigneter Schwachstellen-Management-Prozesse.
– soweit nicht anders dargestellt, beziehen sich im Folgenden alle Verweise auf den Text des CRA –
Sie wollen klären, welche Anforderungen der CRA an Ihre Organisation stellt?
Sprechen Sie unverbindlich mit unserem Experten!
Für wen ist der Cyber Resilience Act von Bedeutung?
Der CRA betrifft grundsätzlich alle, die ein Produkt mit digitalen Elementen, also einer Software-Unterstützung bereitstellen. Allerdings schränkt er seine Gültigkeit auch gegenüber bereits anderweitig regulierten Gruppen ein. So werden Produkte, die sich nur im Automotive-Bereich, im Marine- oder Aviation-Umfeld bewegen oder der Medical Device Regulation unterliegen, ausgenommen. Es ist jedoch anzunehmen, dass eine Dual-Use-Möglichkeit, also eine Nutzbarkeit in anderen, nicht regulierten Bereichen, die Gültigkeit auch wieder herstellen wird.
Rollen der Akteure
Weiterhin ist die Rolle des Handelnden relevant für die Beurteilung der Gültigkeit. Konzeptuell versucht die Regulierung den Nutznießer der wirtschaftlichen Transaktion in die Verantwortung zu nehmen, der innerhalb der EU das Geschäft abbildet. Was bedeutet das?
Im einfachen Fall stellt ein europäischer Anbieter ein Produkt mit digitalen Elemente her, welches in den regulierten Bereich (s.o.) fällt. Somit steht der Anbieter direkt in der Pflicht, die CRA-Anforderungen für sein Produkt zu erfüllen, beispielsweise ein Hersteller für Stereoanlagen oder Musikboxen, die Musik-Streaming unterstützen oder eine Werkzeugmaschine, welche per Fernüberwachung gewartete werden kann.
Sitzt der Hersteller des Produktes außerhalb der EU, gehen diese Pflichten an seinen Stellvertreter über, den „Inverkehrbringer“. Dies kann ein Händler, ein Partner oder ein Implementierungspartner sein, eben der nächste wirtschaftliche Nutznießer. Interessant ist, dass dieser auch für die Einhaltung der Pflichten bei der Herstellung bürgen muss. Das bringt eine komplett neues Haftungsregime für bspw. Lizenzverkäufer amerikanischer Software mit sich!
Open Source
Sobald Open Source ins Spiel kommt, wird die Kette etwas unklarer. Aber der CRA kennt und berücksichtigt das Open Source Konzept. Der eigentliche Urheber einer Open Source Lösung bleibt von den Anforderungen verschont. Nimmt ein Akteur jedoch eine Open Source Lösung und nutzt sie wirtschaftlich, sei es durch Support-Verträge, treffen ihn die Regelungen analog zu denen eines Anbieters. Beispielsweise ist eine SUSE im Sinne des CRA verantwortlich für die von ihr bereitgestellte Distribution.
Ausnahmen gibt es nur für sogenannte Stewards. Diese haben weniger scharfe Anforderungen zu erfüllen. Diese Rolle wurde für die sogenannten Foundations (Eclipse, Cloud native, etc.) geschaffen, da sie zwar eine Form des Inverkehrbringers darstellen, jedoch keine mit einem herkömmlichen Software-Anbieter vergleichbaren, wirtschaftlichen Vorteile aus der Bereitstellung und Verbreitung ziehen. Um als Steward zu gelten, ist eine Anerkennung erforderlich.
Was sind die wesentlichen Neuerungen?
Der leitende Gedanke hinter dem CRA ist die Verbesserung der Sicherheitslage für die Konsumenten von Software. Da heutzutage fast alles von und mit Software gesteuert wird, bzw. ausgestattet ist, sind Cyber-Angriffe fast überall möglich. Jede Komponente, die durch eine Internetverbindung, ein WLan oder auch eine Near-Field-Kommunikation wie ZigBee oder Bluetooth zählt zur potentiellen Angriffsoberfläche – neu-deutsch: Attack Surface- und ist daher mit Bedacht zu nutzen, bzw. bereitzustellen.
Der Anbieter einer Software im europäischen Markt hat daher zukünftig folgende Anforderungen zu erfüllen:
- Bereitstellen eines Software Bill of Materials (SBOM), s. Anhang I
- Regelmäßiges Durchführen einer Risikobetrachtung der Sicherheitsrisiken sowie deren Aufnahme in die Dokumentation, s Art. 13, III und IV
- Erstellen einer Konformitätserklärung, s. Art. 13 XII, bzw. Art. 28 I sowie Anhang IV
- Bereitstellen einer CE-Kennzeichnung, s. Art. 12 XII, bzw. Art. 30 I
- Definition einer zu erwartenden Lebensdauer des Produktes und die Bereitstellung kostenloser Sicherheits-Updates innerhalb dieses Zeitraumes, s. Art. 13 VIII ff
- Einfordern umfangreicher Meldepflichten (gem. Art. 14)
- Mitteilung aktiv ausgenutzter Schwachstellen innerhalb von 24h an die European Network and Information Security Agency (ENISA) über eine noch zu schaffende Meldeplattform (vermutlich analog der bereits im Telekom-Umfeld bestehenden Lösung)
- Ergänzend hierzu eine Präzisierung der Einschätzung sowie der Maßnahmen innerhalb von 72h
- Information der Nutzer des Produktes sowie die von diesen zu ergreifenden Maßnahmen, s. Art. 14 VIII.
Wie kann TrustSource helfen?
- Einheitliche Plattform für Software Analyse, Compliance & Release-Management
- Integriertes Risiko-Management
- Automatisiertes Schwachstellen-Management
- Durchgängige, CRA-konforme Dokumentation
- CSAF-konforme Meldungen
- Einheitlicher Schwachstellen-Meldeprozess
- Umsetzungsunterstützung
Was sind die Auswirkungen der Nicht-Einhaltung?
Jedes Gesetz ist zunächst nur die Deklaration einer Verhaltensvorgabe. Was ist jedoch die Folge, wenn man sich nicht der Vorgabe gemäß verhält? Welche Risiken drohen den Anbietern?
Mit Veröffentlichung werden die Mitgliedsstaaten beauftragt, eine Stelle zu benennen, die für die Aufsicht in dem jeweiligen Land verantwortlich ist. In Deutschland wird dies nach aller Voraussicht das BSI sein. Dieses wiederum kann dann im Verdachtsfall entsprechende Prüfungen durchführen, bzw. beauftragen. Werden dabei Missstände festgestellt, führt dies in der Regel zur Aufforderung der Nachbesserung, kann jedoch auch entsprechend sanktioniert werden. Der CRA sieht folgende, mögliche Sanktionen vor:
- Bei Verstoß gegen grundlegende Sicherheitsanforderungen (Anhang I) bis zu 15 Mil. EUR oder, bei Unternehmen, bis zu 2,5% des weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr. (s. Art. 64 II)
- Bei Verstoß gegen Pflichten, die der CRA auferlegt, bis zu 10 Mil. EUR oder – für Unternehmen – bis zu 2% des ww Umsatzes (Vorjahr) (s. Art. 64 III)
- Für unrichtige, unvollständige oder irreführende Meldungen gegenüber den Behörden, bis zu 5 Mil. EUR, bzw. 1% des Jahresumsatzes für Unternehmen (s. Art. 64 IV)
Darüber hinaus besteht die Möglichkeit, bei nachhaltiger Nicht-Konformität die Verbreitung des Produktes einzuschränken, bzw. es vom Markt zu nehmen, s. bspw. Art. 58 II.
Sie sind sich nicht sicher, was das für Ihre Organisation bedeutet?
Sprechen Sie unverbindlich mit einem unserer Experten!