- Start
- Compliance
- Cyber Resilience Act für Softwarehersteller
Cyber Resilience Act für Softwarehersteller
Sie verkaufen Software in der EU? Jetzt müssen Sie beweisen, dass Sie sie patchen können.
Der Cyber Resilience Act legt Sicherheitsregeln für Produkte mit digitalen Elementen fest, die in der EU verkauft werden. NIS2 regelt, wie Sie Ihr Unternehmen betreiben. Der CRA regelt, was Sie an Kunden ausliefern, ob Sie sich nun als Sicherheitsfirma sehen oder nicht.
Der schnelle Test: Enthält Ihr Produkt Software oder verbindet es sich mit einem Netzwerk, und verkaufen Sie es in Europa, sind Sie fast sicher betroffen.
Seit 2004 vertrauen uns öffentliche Hand, Energiewirtschaft und Schwerindustrie, also Kunden, die ihre Lieferanten prüfen, bevor sie unterschreiben. Zu den Fallstudien.
Der CRA gilt schrittweise, die Meldepflichten zuerst. Prüfen Sie im konsolidierten Text im Amtsblatt, welche Fristen für Ihre Produktkategorie gelten, bevor Sie danach planen. Diese Seite erklärt, wie die Regeln funktionieren, und ist keine Rechtsberatung.
Was Sie können müssen
- Ohne bekannte ausnutzbare Schwachstellen ausliefern, mit sicheren Standardeinstellungen.
- Eine SBOM erstellen: eine vollständige Liste aller Bibliotheken und Versionen in Ihrem Produkt.
- Schwachstellen behandeln: finden, beheben und den Fix während des gesamten Supportzeitraums zu den Kunden bringen.
- Melden: aktiv ausgenutzte Schwachstellen und schwere Vorfälle, mit kurzen Fristen.
- Hinweise von außen annehmen, über einen Meldekanal, der auch antwortet.
- Einen Supportzeitraum angeben, für den Kunden schon beim Kauf sichtbar.
Die Frage, auf die es ankommt
In einer Bibliothek, die Sie verwenden, taucht eine Schwachstelle auf. Wie lange dauert es, bis Sie sagen können, ob Sie betroffen sind, welche Kunden betroffen sind und wie schnell Sie sie patchen können?
Lautet die Antwort „ein paar Tage, in denen jemand die Repositories durchsucht“, haben Sie keinen CRA-Prozess. Unternehmen scheitern selten an den Anforderungen selbst. Sie scheitern, weil darunter nichts steht.
Wo es meistens hakt
- Eine SBOM, einmal für ein Audit von Hand erstellt und am nächsten Tag veraltet
- Niemand beobachtet Schwachstellen in den Komponenten, die Sie ausliefern
- Keine Übersicht, welcher Kunde welche Version einsetzt
- Kein schneller Weg, ein Sicherheitsupdate an alle zu verteilen
- Meldefristen verpasst, weil niemand weiß, wer entscheidet
Was wir bauen
Automatisiert
- Eine SBOM, bei jedem Release in Ihrer Build-Pipeline erzeugt
- Laufender Abgleich mit veröffentlichten Schwachstellen
- Alarm nur, wenn ein ausgeliefertes Produkt wirklich betroffen ist
- Ein Register der installierten Versionen pro Kunde
- Ein funktionierender Weg für Sicherheitsupdates
Dokumentiert
- Verfahren für Schwachstellenbehandlung und koordinierte Offenlegung
- Meldeablauf mit benannten Entscheidern
- Technische Dokumentation des Produkts
- Support- und Update-Richtlinie
- Schulung für Entwickler
Es gewinnt auch Aufträge
Kunden, die unter NIS2 fallen, müssen Sie als Lieferanten bewerten. Ein funktionierender CRA-Prozess liefert genau das, was ihre Fragebögen verlangen: SBOM, Schwachstellen-Richtlinie, Supportzeitraum, Meldekanal.
Sie antworten an einem Tag. Wettbewerber ohne Prozess brauchen drei Wochen und fallen von der Shortlist.
Wenn Ihr Produkt KI enthält
Die Regeln addieren sich. Ein vernetztes Produkt mit KI-Komponente kann sowohl unter den CRA als auch unter die KI-Verordnung fallen, jeweils mit eigener Dokumentation. Modelle und Inferenz-Bibliotheken gehören wie jede andere Abhängigkeit in die SBOM. Die Modellversion wird Teil der Konfiguration, die Sie unter Kontrolle haben müssen.
In einem Tag wissen, wo Sie stehen
Erzeugen Sie eine SBOM für Ihr Hauptprodukt und zählen Sie die heute bekannten Schwachstellen darin. Das dauert etwa einen Tag und wird meist ein ernüchterndes Gespräch mit Ihren Entwicklern. Danach buchen Sie ein Gespräch mit uns, und wir gehen durch, was Ihr Release-Prozess übersteht und was nicht.
Häufige Fragen
Was ist eine SBOM und wozu brauche ich sie?
Software Bill of Materials: die vollständige Liste aller Komponenten und Bibliotheken in Ihrem Produkt, mit Versionen. Ohne sie können Sie im Ernstfall die eine wichtige Frage nicht schnell beantworten: Bin ich von dieser Schwachstelle betroffen?
Gilt der CRA auch für interne Software?
Die Verordnung zielt auf Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden. Rein intern genutzte Software fällt unter andere Regeln, die Praktiken zum Schwachstellenmanagement bleiben für NIS2 aber relevant.
In 30 Minuten wissen, ob es sich lohnt.
Erzählen Sie uns von einem Prozess, der Ihrem Team die Woche raubt. Wir sagen Ihnen noch im Gespräch, ob ein Agent ihn übernehmen kann, was das ungefähr kostet und was es spart. Passt es nicht, sagen wir das auch.