Schwachstellenmanagement, PSIRT und SBOM unter dem Cyber Resilience Act

Problem in der Praxis

In vielen Produktorganisationen ist Schwachstellenbehandlung reaktiv und personenabhängig. Meldungen erreichen das Unternehmen über zufällige Kanäle, eine zentrale Kontaktstelle fehlt, und Verantwortlichkeiten sind unklar. Drittkomponenten und Open-Source-Bibliotheken sind nicht vollständig inventarisiert, sodass beim Bekanntwerden einer Schwachstelle in einer verbreiteten Bibliothek niemand schnell beantworten kann, welche ausgelieferten Produkte und Versionen betroffen sind.

Hinzu kommt, dass der Unterstützungszeitraum oft nicht definiert ist. Produkte bleiben jahrelang im Feld, ohne dass geklärt wäre, wie lange Sicherheitsupdates bereitgestellt werden und über welchen Mechanismus sie die Nutzer erreichen. Erst ein konkreter Vorfall oder eine externe Schwachstellenmeldung legt offen, dass weder Prozess, Rollen noch Nachweise vorhanden sind.

Das ist unter dem CRA keine Komfortfrage mehr. Schwachstellenbehandlung gehört zu den wesentlichen Cybersicherheitsanforderungen und ist damit Voraussetzung für das rechtmäßige Inverkehrbringen.

CISO-Einordnung

Der CRA ist produktbezogen und damit von organisationsbezogenen Rahmen wie NIS2 abzugrenzen. NIS2 adressiert das Risikomanagement und die Meldepflichten eines Betreibers, der CRA adressiert die Eigenschaften und die Lebenszykluspflichten eines Produkts beim Hersteller. Beide ergänzen sich: CRA-konforme Produkte stärken die Lieferkettensicherheit, die NIS2-Betreiber von ihren Zulieferern erwarten.

Innerhalb des CRA sind zwei Säulen zu unterscheiden. Die Produkteigenschaften (Anhang I, Teil I) verlangen unter anderem Security-by-Design und Security-by-Default sowie die Auslieferung ohne bekannte ausnutzbare Schwachstellen. Die Schwachstellenbehandlung (Anhang I, Teil II) verlangt das Identifizieren und Dokumentieren von Komponenten und Schwachstellen inklusive SBOM, das zeitnahe Beheben durch Sicherheitsupdates, regelmäßige Tests, eine CVD-Policy und die Bereitstellung von Updates über den Unterstützungszeitraum.

Davon zu trennen ist die Meldepflicht. Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen melden Hersteller an ENISA und das zuständige nationale CSIRT über die zentrale Meldeplattform. Vorgesehen sind eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden sowie ein Abschlussbericht; bei aktiv ausgenutzten Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Gegenmaßnahme fällig (Frist nach CRA Art. 14), bei schwerwiegenden Vorfällen binnen eines Monats. Für den CISO heißt das: Schwachstellenbehandlung (Dauerpflicht) und Meldung (Ereignispflicht) sind verschiedene Prozesse, die dieselbe PSIRT-Funktion bedienen sollte.

Umsetzungsperspektive

Die PSIRT-Funktion ist der organisatorische Kern. Sie betreibt die Kontaktstelle für eingehende Schwachstellenmeldungen, koordiniert Analyse und Behebung, steuert die koordinierte Offenlegung und verantwortet die Verteilung von Sicherheitsupdates. PSIRT muss kein großes, eigenständiges Team sein; ausschlaggebend sind klare Rollen, definierte Reaktionszeiten und ein belastbarer Eskalationsweg ins Engineering und ins Management.

Die SBOM ist die Datengrundlage. Ohne maschinenlesbare Stückliste der enthaltenen Komponenten lässt sich die Frage nach Betroffenheit bei neuen Schwachstellen nicht verlässlich beantworten. Die SBOM sollte automatisiert aus der Build-Pipeline entstehen und versioniert mit dem Produkt mitgeführt werden. Die BSI TR-03183 behandelt SBOM in einem eigenen Teil und nimmt dabei auf etablierte Formate wie CycloneDX und SPDX Bezug.

Der Unterstützungszeitraum ist eine Managemententscheidung mit Produkt- und Kostenfolge. Als Orientierung gilt in der Regel ein Zeitraum von mindestens fünf Jahren, sofern die erwartete Nutzungsdauer nicht kürzer ist. Das Ende des Unterstützungszeitraums gehört zu den Nutzerinformationen, die mit dem Produkt bereitzustellen sind.

Als fachliche Bezugspunkte für die Umsetzung dienen die BSI TR-03183 (Teil 1 allgemeine Anforderungen, Teil 2 SBOM, Teil 3 Umgang mit Schwachstellen) als frei zugängliche Orientierung, die Normenreihe IEC 62443 (insbesondere 62443-4-1 für den sicheren Entwicklungslebenszyklus) als wichtigster Kandidat für harmonisierte Normen mit Vermutungswirkung sowie das NIST SSDF (SP 800-218) als prozessuale Referenz. Die organisatorischen Secure-Development- und Schwachstellen-Praktiken der ISO/IEC-27001-Familie liefern den übergreifenden Managementrahmen.

Typische Fehler

1. Schwachstellenbehandlung wird mit Vorfallmeldung verwechselt; die Dauerpflicht aus Anhang I, Teil II bleibt unbearbeitet.
2. Es gibt keine zentrale, dauerhaft erreichbare Kontaktstelle für externe Schwachstellenmelder.
3. Die SBOM wird einmalig manuell erstellt statt automatisiert und versioniert aus der Pipeline gepflegt.
4. Der Unterstützungszeitraum ist nicht definiert oder den Nutzern nicht transparent gemacht.
5. Drittkomponenten werden nicht systematisch beobachtet, sodass neue Schwachstellen in Bibliotheken zu spät erkannt werden.
6. PSIRT existiert auf dem Papier, hat aber keine verbindlichen Reaktionszeiten und keinen Eskalationsweg ins Engineering.

Risiken und Trade-offs

Ein zu eng gefasster Unterstützungszeitraum senkt kurzfristig Kosten, kann aber Marktanforderungen, Kundenerwartungen und die erwartete Nutzungsdauer verfehlen. Ein sehr langer Zeitraum bindet dagegen über Jahre Update- und Test-Kapazitäten.

Bei der koordinierten Offenlegung besteht ein Spannungsfeld zwischen Transparenz gegenüber Nutzern und dem Schutz noch nicht behobener Schwachstellen. Eine klare CVD-Policy mit angemessenen Fristen reduziert dieses Risiko.

Die SBOM selbst kann sicherheitsrelevante Information über die Angriffsfläche enthalten. Umfang, Detailgrad und Empfängerkreis sind daher bewusst zu steuern. Schließlich gilt: Werkzeuge für SBOM-Erzeugung und Schwachstellen-Scanning unterstützen den Prozess, ersetzen aber weder die PSIRT-Verantwortung noch die Triage-Entscheidungen.

Entscheidungspunkte

• Welche Produkte fallen in den Anwendungsbereich, und wer ist jeweils Hersteller im Sinne der Verordnung?
• Wie lang ist der Unterstützungszeitraum je Produktlinie, und wie wird er den Nutzern kommuniziert?
• Wo ist die PSIRT-Funktion organisatorisch verankert, und welche Reaktions- und Behebungszeiten gelten?
• Wie entsteht die SBOM technisch, in welchem Format, und wer erhält sie in welchem Detailgrad?
• Welche harmonisierten Normen oder Spezifikationen werden für die Konformität herangezogen?
• Wie wird die Trennung zwischen Dauerpflicht (Schwachstellenbehandlung) und Ereignispflicht (Meldung) prozessual sichergestellt?

Praktische Empfehlungen

1. Richten Sie eine dauerhaft erreichbare Kontaktstelle ein und verankern Sie eine PSIRT-Funktion mit klaren Rollen, Fristen und Eskalationswegen.
2. Automatisieren Sie die SBOM-Erzeugung in der Build-Pipeline und führen Sie sie versioniert mit jedem Produkt mit.
3. Definieren Sie den Unterstützungszeitraum je Produktlinie bewusst und machen Sie sein Ende für Nutzer transparent.
4. Verabschieden Sie eine CVD-Policy mit angemessenen Offenlegungsfristen und einem definierten Umgang mit externen Meldern.
5. Beobachten Sie Drittkomponenten kontinuierlich, damit neue Schwachstellen schnell den betroffenen Produkten zugeordnet werden.
6. Nutzen Sie die BSI TR-03183 als Strukturhilfe und prüfen Sie den jeweils aktuellen Versionsstand vor verbindlicher Anwendung.
7. Halten Sie Schwachstellenbehandlung und Meldewege als getrennte, aber gemeinsam betriebene Prozesse vor und üben Sie die 24-/72-Stunden-Wege.

Relevante Normreferenzen

• Cyber Resilience Act, Verordnung (EU) 2024/2847: verbindliche Rechtsgrundlage; wesentliche Cybersicherheitsanforderungen in Anhang I (Teil I Produkteigenschaften, Teil II Schwachstellenbehandlung). EU-Recht, frei zitierbar mit Quellenangabe.
• BSI TR-03183 "Cyber-Resilienz-Anforderungen an Hersteller und Produkte": frei zugängliche Orientierungs- und Umsetzungshilfe (Teil 1 allgemeine Anforderungen, Teil 2 SBOM, Teil 3 Umgang mit Schwachstellen); nicht rechtsverbindlich, keine Vermutungswirkung.
• IEC 62443 (insbesondere 62443-4-1): Referenz für den sicheren Produktentwicklungslebenszyklus; wichtiger Kandidat für harmonisierte Normen.
• NIST SSDF (SP 800-218): prozessuale Referenz für sichere Softwareentwicklung und SBOM (Public Domain).
• ISO/IEC 27001/27002: Referenz für organisatorische Secure-Development- und Schwachstellenpraktiken (nur Strukturbezug, keine Control-Nummern).