Cyber Resilience Act: SBOM und Secure by Design

Der Cyber Resilience Act wird den Umgang mit Software und vernetzten Produkten in Europa spürbar verändern. Wenn du in der Verwaltung IT beschaffst oder als Unternehmen Produkte mit digitalen Elementen in den EU-Markt bringst, wirst du an den neuen Pflichten nicht vorbeikommen: Sicherheitsanforderungen, SBOM, Schwachstellenmanagement und klare Prozesse über den gesamten Produktlebenszyklus.

Wen der Cyber Resilience Act betrifft

Der CRA ist eine EU-Verordnung für „Produkte mit digitalen Elementen“. Er richtet sich nicht an Endnutzer, sondern an die Akteure im Markt:

• Hersteller
• Bevollmächtigte
• Importeure
• Händler

Betroffen sind insbesondere:

• Softwareprodukte, auch reine Cloud-Software, sofern sie als Produkt in den EU-Markt gebracht werden
• Betriebssysteme, Middleware, Datenbanken
• IoT-Geräte, vernetzte Sensoren, Smart-Meter, Smart-Building-Komponenten
• Netzwerk- und Sicherheitsprodukte wie Firewalls, Router, VPN-Gateways
• Industriesteuerungen und OT-Komponenten, wenn sie mit Netzen verbunden sind
• Embedded Software in Hardware, zum Beispiel in Medizingeräten oder Fahrzeugen

Nicht erfasst sind im Grundsatz:

• Reine Open-Source-Software, die nicht kommerziell in Verkehr gebracht wird
• Reine Dienste ohne Produktcharakter, zum Beispiel reine Beratungsleistungen

Für öffentliche Auftraggeber heißt das: Du wirst künftig regelmäßig mit CRA-konformen Produkten und entsprechenden Konformitätserklärungen zu tun haben. Und als Unternehmen, das für die öffentliche Hand entwickelt, musst du klären, ob du Hersteller im Sinne des CRA bist und welche Pflichten du selbst trägst.

Passende Seminare und Termine findest du bei uns auf cmt.de.

Zentrale Pflichten für Produkte mit digitalen Elementen

Der CRA verlangt, dass Produkte mit digitalen Elementen während ihres gesamten Lebenszyklus ein angemessenes Cybersicherheitsniveau aufweisen. Kernpunkte sind:

• Sicherheitsanforderungen an Design und Entwicklung
• Sicheres Konfigurations- und Update-Management
• Schwachstellenmanagement und Meldungen an Behörden
• Technische Dokumentation und Konformitätsbewertung
• CE-Kennzeichnung und EU-Konformitätserklärung

Für Hersteller bedeutet das unter anderem:

• Risikobewertung des Produkts und seiner Umgebung
• Implementierung von Sicherheitsfunktionen, zum Beispiel Zugriffskontrolle, Logging, Schutz vor unbefugten Änderungen
• Minimierung von Angriffsflächen und Verwendung sicherer Voreinstellungen
• Etablierung eines dokumentierten Prozesses zum Umgang mit Schwachstellen, inklusive Annahme von Meldungen aus der Community
• Sicherstellung, dass bekannte Schwachstellen in verwendeten Komponenten (Libraries, Frameworks) erkannt und behandelt werden

Für Importeure und Händler gilt: Sie müssen prüfen, ob das Produkt eine CE-Kennzeichnung trägt, eine EU-Konformitätserklärung vorliegt und ob der Hersteller seinen Pflichten nachkommt. Bei Verdacht auf Nichtkonformität müssen sie die Bereitstellung aussetzen und zuständige Behörden informieren.

SBOM als zentrales Werkzeug: Was verlangt der CRA?

Eine „Software Bill of Materials“ (SBOM) ist eine strukturierte Liste aller Softwarekomponenten, die in einem Produkt stecken. Sie umfasst in der Regel:

• Name der Komponente
• Version
• Herkunft bzw. Quelle (zum Beispiel Projekt, Anbieter, Repository)
• Lizenzinformationen
• Abhängigkeiten zu weiteren Komponenten

Der CRA verlangt nicht wörtlich „SBOM“, aber faktisch genau das: Hersteller müssen eine Übersicht über die im Produkt enthaltenen Komponenten führen und Sicherheitsrisiken, die sich aus Komponenten ergeben, adressieren. Ohne SBOM ist das praktisch nicht machbar.

Für die Praxis heißt das:

• In der Entwicklung müssen Tools eingesetzt werden, die Abhängigkeiten automatisch erfassen und dokumentieren.
• Build-Prozesse sollten automatisiert SBOM-Artefakte erzeugen, zum Beispiel im CycloneDX- oder SPDX-Format.
• Security-Teams brauchen Zugriff auf diese SBOM-Daten, um bekannte Schwachstellen (CVEs) gegen die verwendeten Komponenten abzugleichen.
• Für bestimmte Kunden, insbesondere Behörden und kritische Infrastrukturen, wird die Bereitstellung einer SBOM vertraglich eingefordert werden.

Als öffentlicher Auftraggeber solltest du künftig in Leistungsbeschreibungen und EVB-IT-Verträgen klar regeln:

• in welcher Form der Auftragnehmer eine SBOM bereitstellt
• in welchen Zyklen Aktualisierungen zu liefern sind
• wie mit vertraulichen Komponenten und Schutzinteressen des Herstellers umzugehen ist

Secure by Design: Anforderungen an Entwicklung und Architektur

„Secure by Design“ ist ein Kernprinzip des CRA. Sicherheit darf nicht nachträglich aufgesetzt werden, sondern muss von Anfang an in Konzeption und Architektur einfließen. Praktisch bedeutet das unter anderem:

• Sicherheitsanforderungen sind Teil der Produktanforderungen, nicht nur ein „nice to have“.
• Bedrohungsanalysen (Threat Modeling) werden systematisch durchgeführt und dokumentiert.
• Die Prinzipien „Least Privilege“ und „Need to know“ werden bei Rollen und Berechtigungen konsequent umgesetzt.
• Voreinstellungen sind sicher, zum Beispiel:
• keine Standardpasswörter
• verschlüsselte Kommunikation ab Werk
• minimal notwendige Dienste aktiv
• Sicherheitsrelevante Funktionen sind robust gegen Fehlkonfigurationen und Missbrauch.

Für Behörden lohnt es sich, in Ausschreibungen explizit auf Secure-by-Design-Praktiken Bezug zu nehmen und Nachweise zu fordern, zum Beispiel:

• dokumentierte Secure-Coding-Guidelines
• etablierte Code-Reviews und Security-Tests (SAST, DAST, Penetrationstests)
• Nachweis, dass sicherheitsrelevante Anforderungen in den Entwicklungsprozessen verankert sind, etwa über ein ISMS nach ISO 27001 oder etablierte Secure-Development-Lifecycles

Schwachstellen-Handling: Prozesse, Meldungen, Fristen

Der CRA legt großen Wert auf ein strukturiertes Schwachstellen-Management. Hersteller müssen:

• einen dokumentierten Prozess zum Umgang mit Schwachstellen etablieren
• eine Kontaktstelle („Vulnerability Disclosure Policy“) veröffentlichen, über die Schwachstellen gemeldet werden können
• Meldungen von Sicherheitsforschern und Nutzern entgegennehmen und bewerten
• Sicherheitsupdates in angemessener Zeit bereitstellen
• in bestimmten Fällen Aufsichtsbehörden informieren

Relevant ist die enge Verzahnung mit anderen Vorgaben, etwa der NIS-2-Richtlinie und den Meldepflichten bei Sicherheitsvorfällen. Im Einzelfall muss abgestimmt werden, wann ein Vorfall meldepflichtig ist und welche Fristen laufen.

Für Auftraggeber ist wichtig:

• In Verträgen sollte klar geregelt sein, innerhalb welcher Zeitrahmen Sicherheitsupdates bereitzustellen sind.
• Du solltest definieren, wie sicherheitsrelevante Informationen kommuniziert werden, etwa über Kundenportale, Security-Advisories oder Mailinglisten.
• Prüfe, ob dein eigenes Incident-Management an die Informationswege der Hersteller angebunden ist, damit kritische Patches nicht „übersehen“ werden.

Release-Gates: Sicherheit als verbindliche Freigabestufe

Um die CRA-Pflichten praktisch umzusetzen, werden viele Organisationen sogenannte Release-Gates einführen oder schärfen. Gemeint sind verbindliche Kriterien, die erfüllt sein müssen, bevor ein Produkt oder Update ausgeliefert wird.

Typische Security-Release-Gates können sein:

• Erfolgreiche Durchführung automatisierter Security-Scans der Anwendung und der verwendeten Libraries
• Keine bekannten kritischen oder hohen Schwachstellen (CVE) in der SBOM, oder dokumentierte, akzeptierte Abweichungen mit klaren Kompensationsmaßnahmen
• Durchführung und Freigabe eines Threat-Modelings für wesentliche Änderungen
• Erfolgreiche Penetrationstests bei Major-Releases
• Aktualisierte Sicherheitsdokumentation und Bedienhinweise

Eine einfache Übersicht:

Bereich	Beispiel für Release-Gate
SBOM	SBOM generiert, keine unbekannten Komponenten
Libraries / CVEs	Keine offenen kritischen CVEs ohne dokumentierte Ausnahme
Konfiguration	Sichere Defaults, kein Hardcoding von Zugangsdaten
Tests	Security-Tests bestanden, Findings bewertet und priorisiert
Dokumentation	Aktualisierte Sicherheits- und Update-Hinweise
Governance	Freigabe durch Security oder Compliance dokumentiert

Für öffentliche Auftraggeber kann es sinnvoll sein, in IT-Projekten mit eigenentwickelter Software festzulegen, dass bestimmte Release-Gates vertraglich bindend sind. So lässt sich das Sicherheitsniveau über die Projektlaufzeit besser steuern.

Übergangsfristen und Zeitplan: Wann musst du handeln?

Der CRA wurde im EU-Gesetzgebungsverfahren beschlossen. Er tritt nach Veröffentlichung im EU-Amtsblatt in Kraft und gilt dann nach einer Übergangsfrist direkt in allen Mitgliedstaaten. Die politisch diskutierten Fristen bewegen sich im Regelfall in diesem Rahmen:

• Inkrafttreten der Verordnung kurz nach Veröffentlichung
• Anwendbarkeit der materiellen Pflichten nach einer Übergangsfrist von in der Regel einigen Jahren
• Für bestimmte Pflichten, insbesondere Meldungen an Behörden, können kürzere Fristen gelten

Die genauen Zeitpunkte ergeben sich aus der endgültigen Verordnung. Verbindlich ist nur der Wortlaut im Amtsblatt. Du solltest den Text und etwaige Leitlinien der EU-Kommission beziehungsweise nationaler Behörden im Blick behalten, zum Beispiel über:

• EUR-Lex für den verbindlichen Verordnungstext
• Informationen des Bundesministeriums für Wirtschaft und Klimaschutz (BMWK)
• Veröffentlichungen des Bundesamts für Sicherheit in der Informationstechnik (BSI)

Aus praktischer Sicht ist die Übergangsfrist kurz, wenn du tief in bestehende Prozesse eingreifen musst. Typische Vorlaufzeiten in größeren Organisationen für:

• Anpassung von Entwicklungsprozessen und Toolchains
• Aufbau eines Schwachstellenmanagements
• Vertragsanpassungen im Einkauf
• Schulung von Entwicklung, Einkauf, Rechtsabteilung und IT-Betrieb

liegen oft bei 12 bis 24 Monaten. Du solltest die Zeit nicht bis zum letzten Tag ausreizen.

Was bedeutet der CRA für deine Ausschreibungen und Verträge?

Für öffentliche Auftraggeber ist der CRA kein „Herstellerproblem“. Er wirkt direkt in deine Beschaffungs- und Vertragsgestaltung hinein:

• Leistungsbeschreibungen sollten Sicherheitsanforderungen, SBOM, Update-Zeiträume und Support klar adressieren.
• EVB-IT-Verträge brauchen gegebenenfalls Ergänzungen zu Secure-by-Design-Vorgaben, Schwachstellenhandling und Informationspflichten.
• Kriterien für die Eignungsprüfung von Bietern können Aspekte der sicheren Softwareentwicklung und des Schwachstellenmanagements umfassen.
• Bei der Bewertung von Angeboten sollte klar sein, wie du Sicherheits-Features und Lebenszykluskosten (Total Cost of Ownership) berücksichtigst.

Als Unternehmen, das an die öffentliche Hand liefert, solltest du dich darauf einstellen, dass Nachweise zu Secure Development, SBOM-Fähigkeiten und Incident-Handling künftig zum Standard in Vergabeverfahren gehören werden.

Checkliste: Wo du jetzt ansetzen solltest

Zum Abschluss eine kompakte Checkliste. Sie ersetzt keine Rechtsberatung, hilft dir aber bei der Priorisierung:

1. Rollen klären

• Bin ich Hersteller, Importeur oder Händler im Sinne des CRA?
• Welche Produkte mit digitalen Elementen bringe ich in den EU-Markt?

2. Produktinventar erstellen

• Welche Produkte sind betroffen?
• Welche davon werden bei öffentlichen Auftraggebern oder in kritischen Bereichen eingesetzt?

3. Entwicklungsprozesse prüfen

• Gibt es definierte Secure-Development-Prozesse?
• Werden SBOMs automatisiert erstellt und gepflegt?
• Sind Security-Tests und Code-Reviews verbindlich?

4. Schwachstellenmanagement etablieren

• Gibt es eine veröffentlichte Kontaktstelle für Vulnerability Reports?
• Wie werden gemeldete Schwachstellen priorisiert, bearbeitet und dokumentiert?
• Wie informierst du Kunden über Sicherheitsupdates?

5. Release-Gates definieren

• Welche Sicherheitskriterien müssen vor einem Release zwingend erfüllt sein?
• Wer entscheidet über Ausnahmen und wie werden diese dokumentiert?

6. Verträge und Beschaffung anpassen

• Sind EVB-IT-Verträge und AGB auf CRA-relevante Themen geprüft?
• Werden SBOM, Secure by Design und Update-Pflichten in Ausschreibungen adressiert?

7. Zeitplan und Verantwortlichkeiten

• Wer ist intern für CRA-Themen zuständig, etwa Recht, IT-Sicherheit, Entwicklung, Einkauf?
• Gibt es einen Projektplan, um die Übergangsfrist sinnvoll zu nutzen?

Wenn du diese Punkte systematisch angehst, bist du deutlich besser vorbereitet, wenn der CRA voll wirksam wird. Für die öffentliche Hand und ihre IT-Lieferanten wird er zum verbindlichen Maßstab für Cybersicherheit über den gesamten Produktlebenszyklus.