CRA-Schwachstellenmanagement: Vulnerability Handling nach Anhang I Teil II

Schwachstellenmanagement nach CRA bedeutet, Sicherheitslücken während des gesamten Supportzeitraums systematisch zu finden, zu bewerten, zu beheben und zu dokumentieren. Ein Hersteller braucht dafür keinen bestimmten Toolnamen, aber einen belastbaren Prozess, der Produktversionen, Komponenten, externe Meldungen, Updates und Nachweise miteinander verbindet.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Schwachstellen & Meldeprozesse. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Externe Meldungen benötigen einen verlässlichen CVD-Prozess mit erreichbarem Sicherheitskontakt. Die PSIRT-Funktion koordiniert Triage, Behebung und Eskalation über Entwicklung, Support und Management hinweg.

Was versteht der CRA unter Vulnerability Handling?

Vulnerability Handling umfasst alle organisatorischen und technischen Tätigkeiten, mit denen Hersteller Schwachstellen über die erwartete Nutzungs- und Supportzeit eines Produkts behandeln. Dazu gehören nicht nur gefundene Fehler im eigenen Code, sondern auch Schwachstellen in Bibliotheken, Firmware, Betriebssystemkomponenten und anderen integrierten Bestandteilen.

Der Prozess beginnt daher nicht erst mit einem Incident. Er braucht bereits vor dem Inverkehrbringen Informationen darüber, welche Komponenten verwendet werden, welche Produktversionen unterstützt werden und wer für Sicherheitsmeldungen zuständig ist.

Welche Anforderungen stellt Anhang I Teil II?

Anhang I Teil II des CRA beschreibt die zentralen Erwartungen an die Behandlung von Schwachstellen. Hersteller sollen Schwachstellen und Komponenten identifizieren und dokumentieren, Risiken beheben, eine CVD-Policy betreiben, Meldewege bereitstellen und Sicherheitsupdates sicher verteilen.

In der Praxis hängen diese Pflichten eng zusammen. Ohne SBOM lässt sich oft nicht schnell feststellen, welche Produkte von einer Bibliothekslücke betroffen sind. Ohne Supportmatrix ist unklar, welche Version noch gepatcht werden muss. Ohne Updateprozess bleibt selbst eine korrekt bewertete Schwachstelle offen.

Wie sollte der Prozess von der Meldung bis zur Behebung aussehen?

Ein guter Ablauf ist transparent und wiederholbar. Er sollte für intern entdeckte Schwachstellen, externe CVD-Meldungen und Hinweise aus Komponentenprojekten weitgehend dieselbe Grundstruktur verwenden.

Welche Quellen muss ein Hersteller überwachen?

Es gibt keine einzelne Datenbank, die alle produktrelevanten Schwachstellen vollständig abdeckt. Hersteller sollten Quellen kombinieren: Meldungen an den eigenen Security-Kontakt, Advisories von Lieferanten, Veröffentlichungen von Open-Source-Projekten, relevante Schwachstellendatenbanken und Erkenntnisse aus eigenen Tests.

Für zentrale Drittkomponenten kann eine gezielte Beobachtung sinnvoller sein als ein unspezifischer Datenstrom mit tausenden Treffern. Das Ziel ist nicht maximale Alarmmenge, sondern belastbare Betroffenheitsanalyse.

Welche Rolle spielt die SBOM?

Die SBOM verbindet externe Schwachstelleninformationen mit dem konkreten Produkt. Wenn eine CVE für eine Bibliothek veröffentlicht wird, muss schnell geklärt werden, ob diese Bibliothek in einer ausgelieferten Version enthalten ist und ob die verwundbare Funktion tatsächlich genutzt wird.

Eine SBOM ohne Versionsbezug oder Produktzuordnung reicht dafür nicht. Hersteller sollten wissen, welche Komponente in welchem Build oder Release enthalten ist und welche Produktgeneration noch unterstützt wird.

Wie priorisiert man Schwachstellen?

Ein technischer Score kann ein Ausgangspunkt sein, aber die Priorität sollte den Produktkontext berücksichtigen. Entscheidend sind Exposition, Ausnutzbarkeit, verfügbare Exploits, Schutzbarrieren, mögliche Auswirkungen und Anzahl betroffener Nutzer.

Besonders wichtig ist die Frage nach aktiver Ausnutzung. Wird eine Schwachstelle aktiv ausgenutzt, kann neben der technischen Behebung eine gesetzliche Meldung nach Artikel 14 CRA erforderlich werden.

Wie schnell müssen Schwachstellen behoben werden?

Der CRA verlangt wirksame Behandlung und zeitnahe Sicherheitsupdates, schreibt aber nicht für jede Schwachstellenklasse eine identische Patchfrist vor. Deshalb braucht das Unternehmen eigene Serviceziele, die sich an Risiko und Produktumgebung orientieren.

Ein praktikables Modell unterscheidet beispielsweise kritisch, hoch, mittel und niedrig und definiert für jede Klasse eine maximale Zeit für Bewertung, Maßnahmenentscheidung und Fix-Ziel. Wichtig ist, dass Ausnahmen dokumentiert und begründet werden.

Was passiert, wenn ein Fix nicht sofort möglich ist?

Dann sollte der Hersteller zunächst eine Minderungsmaßnahme prüfen. Das kann eine Konfigurationsänderung, Deaktivierung einer Funktion, zusätzliche Netzwerkbeschränkung oder andere temporäre Schutzmaßnahme sein.

Nutzer müssen verstehen, was sie tun sollen und welche Restrisiken verbleiben. Parallel läuft die dauerhafte Behebung weiter. Bei relevanten Fällen kann diese Information auch Bestandteil eines Security Advisories oder einer behördlichen Meldung werden.

Wie behandelt man Schwachstellen in Drittkomponenten?

Drittkomponenten sind keine Haftungs- oder Prozesslücke. Erkennt der Hersteller eine Schwachstelle in einer integrierten Komponente, muss er sie im eigenen Produkt bewerten, behandeln und den Komponentenhersteller oder Maintainer informieren.

Hat der Hersteller selbst einen Patch oder eine Modifikation entwickelt, kann es erforderlich sein, relevante Informationen oder Code an den Maintainer zurückzugeben. Das stärkt die Lieferkette und verhindert, dass jeder Integrator dieselbe Lücke isoliert behebt.

Welche Dokumentation ist sinnvoll?

Jeder relevante Fall sollte mindestens Quelle, Zeitpunkt, Produkt, Version, Komponente, Bewertung, Entscheidung, Maßnahmen, Verantwortliche, Tests, Veröffentlichung und Abschluss enthalten. Das muss nicht zwangsläufig ein spezielles Security-Tool sein; wichtig ist die Nachvollziehbarkeit.

Die Dokumentation fließt später in technische Nachweise und Reviews ein. Der geplante Beitrag zur technischen Dokumentation nach CRA zeigt, wie Vulnerability-Prozesse dort abgebildet werden.

Wie hängen Vulnerability Handling und Supportzeitraum zusammen?

Die Herstellerpflicht zur wirksamen Schwachstellenbehandlung gilt während des festgelegten Supportzeitraums. Deshalb müssen Supportende und Versionspflege technisch mit dem Schwachstellenprozess verbunden sein.

Ein Ticket darf nicht automatisch geschlossen werden, nur weil eine ältere Version intern als „legacy“ gilt. Erst wenn feststeht, dass die Version außerhalb des zugesagten Supportzeitraums liegt oder Nutzer kostenlos auf eine unterstützte Version wechseln können, lässt sich die Behandlungsstrategie sauber beurteilen.

Wie prüft man, ob der Prozess wirklich funktioniert?

Ein Tabletop-Test ist besonders wirksam. Das Team erhält ein realistisches Szenario: Eine kritische Bibliothek ist betroffen, mehrere Produktversionen sind im Markt, ein Kunde meldet verdächtiges Verhalten und ein Fix ist noch nicht verfügbar.

Dann wird geprüft, wie schnell Betroffenheit, Owner, Priorität, Nutzermaßnahme, Update-Plan und Meldepflicht geklärt werden. Der Test deckt fehlende Kontakte und Informationslücken besser auf als eine reine Prozessbeschreibung.

Welche Kennzahlen helfen ohne falschen KPI-Druck?

Hilfreich sind beispielsweise Zeit bis zur ersten Bewertung, Anteil innerhalb definierter Fix-Ziele, offene kritische Schwachstellen, Zeit bis zur Nutzerinformation und Zahl der Fälle ohne eindeutige Produktzuordnung.

Die Kennzahlen sollten Qualität fördern und nicht dazu führen, dass Fälle nur für bessere Statistiken geschlossen werden. Ein sauber begründetes offenes Risiko ist besser als ein formal geschlossenes Ticket ohne technische Lösung.

Welche Fehler sind besonders kritisch?

• Keine eindeutige Zuständigkeit für Schwachstellen.
• Keine Verbindung zwischen SBOM und Produktversionen.
• Externe Meldungen bleiben im Supportsystem hängen.
• Drittkomponenten werden als „Problem des Lieferanten“ abgetan.
• Patch-Entscheidungen werden nicht dokumentiert.
• Security Updates werden nicht sicher verteilt.
• Aktive Ausnutzung wird nicht an den Reporting-Prozess eskaliert.

Wo stehen die Anforderungen?

Die rechtliche Grundlage findet sich insbesondere in Artikel 13 und Anhang I Teil II der Verordnung (EU) 2024/2847. Für einzelne Fälle sind zusätzlich Produktklassifizierung, Supportzeitraum und Meldepflichten zu berücksichtigen.

Wie wird aus einer Schwachstelle ein dokumentiertes Produktrisiko?

Eine Schwachstelle ist zunächst eine technische Eigenschaft oder ein Fehler. Zum Produktrisiko wird sie durch den konkreten Einsatzkontext: Welche Funktion ist betroffen, welche Schutzgüter können verletzt werden und wie realistisch ist eine Ausnutzung? Genau diese Brücke muss der Hersteller dokumentieren.

Die Fallakte sollte deshalb nicht nur einen externen Score speichern. Sie sollte festhalten, welche Annahmen der Bewertung zugrunde liegen und ob sich die produktbezogene Risikobewertung ändern muss. So bleibt nachvollziehbar, warum zwei Produkte mit derselben Bibliothek unterschiedlich priorisiert werden können.

Wie verhindert man Doppelarbeit zwischen Teams?

Schwachstellen tauchen oft gleichzeitig in Security-Scannern, Entwicklerboards, Kundentickets und Lieferantenmeldungen auf. Ohne gemeinsame Fall-ID entstehen parallele Analysen und widersprüchliche Statusangaben.

Ein zentraler Vulnerability Record sollte deshalb auf technische Tickets verweisen, aber die regulatorisch relevanten Informationen bündeln. Entwicklung kann weiterhin in ihrem gewohnten System arbeiten; der Security-Prozess hält Produktbezug, Priorität, Reportingstatus und Nutzerkommunikation zusammen.

Wie behandelt man False Positives aus Scannern?

Automatisierte Scanner liefern wertvolle Hinweise, aber nicht jeder Treffer betrifft das ausgelieferte Produkt. Eine Bibliothek kann beispielsweise vorhanden sein, ohne dass die verwundbare Funktion genutzt wird. Solche Fälle müssen geprüft und begründet ausgeschlossen werden.

Ein dokumentiertes False Positive ist kein Problem. Problematisch ist ein pauschaler Ausschluss ohne technische Begründung. Gute Nachweise nennen Version, betroffene Funktion, Build-Kontext und die Analyse, warum keine Ausnutzbarkeit besteht.

Wie geht man mit End-of-Life-Komponenten um?

Eine nicht mehr gepflegte Kernkomponente ist ein strategisches Risiko. Selbst wenn aktuell keine bekannte Schwachstelle vorliegt, kann der Hersteller künftige Lücken möglicherweise nicht mehr mit Hilfe des Maintainers beheben.

Deshalb sollte Komponenten-Support Teil der Produktplanung sein. Für Kernfunktionen braucht es Alternativen, Migrationspfade oder eigene Wartungsfähigkeit. Der Supportzeitraum des Produkts sollte nicht länger versprochen werden, ohne die Abhängigkeiten dahinter zu berücksichtigen.

Welche Rolle spielt Threat Intelligence?

Threat Intelligence kann helfen zu erkennen, ob eine bekannte Schwachstelle bereits praktisch ausgenutzt wird, welche Angriffswerkzeuge existieren oder welche Branchen besonders betroffen sind. Für den CRA ist vor allem aktive Ausnutzung relevant, weil sie Meldepflichten auslösen kann.

KMU müssen dafür kein eigenes Intelligence-Team aufbauen. Seriöse Lieferantenhinweise, nationale CSIRT-Informationen, Komponenten-Advisories und vertrauenswürdige Security-Quellen können ausreichend sein, wenn klar geregelt ist, wer diese Hinweise bewertet.

Was sollte ein monatliches Vulnerability Review leisten?

Ein regelmäßiges Review verhindert, dass offene Fälle still altern. Das Team betrachtet kritische und überfällige Schwachstellen, blockierte Fixes, Produkte kurz vor Supportende und neue Risiken in Drittkomponenten.

Das Review sollte Entscheidungen erzeugen: Priorität erhöhen, Management eskalieren, Nutzer informieren, Lieferant nachfassen oder Risikobewertung aktualisieren. Ein Meeting ohne dokumentierte Folgemaßnahmen verbessert den Prozess nicht.

Wie weist man Prozessreife gegenüber einer Behörde nach?

Bei einer Prüfung zählt nicht nur eine Prozessbeschreibung, sondern konkrete Evidenz. Hilfreich sind anonymisierte Fallverläufe, dokumentierte Entscheidungen, Security Advisories, Testberichte, SBOM-Bezüge und Nachweise über Updates.

Ein Hersteller sollte deshalb gelegentlich einen abgeschlossenen Fall vom Eingang bis zum Abschluss prüfen. Wenn der Ablauf anhand der Dokumentation nicht rekonstruiert werden kann, ist die Nachweisführung noch zu schwach.

Wie werden Schwachstellen über mehrere Produktgenerationen verfolgt?

Ein Hersteller mit mehreren Produktlinien braucht eine gemeinsame Sicht auf wiederverwendete Komponenten. Eine Schwachstelle kann gleichzeitig drei Firmwaregenerationen, eine Desktopanwendung und einen Cloud-Agenten betreffen. Ohne zentrale Zuordnung entstehen Lücken.

Deshalb sollte ein Vulnerability Record auf alle betroffenen Produkte und Releases verweisen. Erst danach kann pro Version entschieden werden, ob Patch, Mitigation oder Supportende relevant ist. Diese Struktur ist besonders wichtig, wenn Code oder Bibliotheken zwischen Produkten geteilt werden.

Wie bindet man Kundenmeldungen in den Prozess ein?

Kunden beschreiben Sicherheitsprobleme häufig nicht in Security-Sprache. Ein ungewöhnlicher Absturz, unerwartete Berechtigung oder verdächtige Netzwerkverbindung kann trotzdem ein Schwachstellenhinweis sein. Support braucht deshalb einfache Kriterien für eine Security-Eskalation.

Das bedeutet nicht, jedes Ticket zum Security Incident zu machen. Ein kurzer Triagepfad reicht: mögliche Vertraulichkeits-, Integritäts- oder Zugriffsauswirkung? Reproduzierbar? Mehrere Kunden? Dann an den Security-Prozess übergeben und dort bewerten.

Wie werden behobene Schwachstellen geschlossen?

„Fix gemerged“ ist kein ausreichendes Abschlusskriterium. Ein Fall sollte erst geschlossen werden, wenn betroffene Versionen geklärt, Tests abgeschlossen, Update oder Mitigation veröffentlicht, Nutzerinformation erfolgt und gegebenenfalls Meldepflichten abgeschlossen sind.

Zusätzlich lohnt ein kurzer Lessons-Learned-Eintrag: Warum entstand die Lücke, welche Kontrolle hätte sie früher verhindert und muss die Risikobewertung oder Entwicklungsrichtlinie angepasst werden? So verbessert jeder Fall den Gesamtprozess.

Welche Verantwortung trägt der Prozess-Owner?

Der Prozess-Owner sorgt nicht für jeden technischen Fix selbst. Er stellt sicher, dass Quellen überwacht, Fälle priorisiert, Fristen eingehalten, Ausnahmen dokumentiert und Reviews durchgeführt werden. Außerdem hält er Vorlagen, Rollen und Eskalationswege aktuell.

Damit bekommt Vulnerability Handling einen festen organisatorischen Anker. Ohne Owner verteilt sich Verantwortung schnell zwischen Entwicklung, Support und Compliance, während niemand den Gesamtstatus kennt.