CRA-Schwachstellen: SBOM, CVD, PSIRT & Meldungen

Ein belastbarer CRA-Prozess führt vom Erkennen einer Schwachstelle über Bewertung und Behebung bis zu Updates, Nutzerinformation und gegebenenfalls einer Meldung. Seit 11. September 2026 gelten die Hersteller-Meldepflichten nach Artikel 14. CVD, PSIRT und SBOM unterstützen diesen Ablauf, erfüllen aber jeweils unterschiedliche Aufgaben.

Stand: 3. Oktober 2026. Diese Themenübersicht führt von der ersten Einordnung zu konkreten Fachartikeln. Den Zusammenhang des Regelwerks erklärt der Überblick zum Cyber Resilience Act.

Was muss beim Eingang einer Sicherheitsmeldung passieren?

Erfassen Sie Meldungen über einen erreichbaren Kontakt und dokumentieren Sie Eingang, Kenntniserlangung, Produkt und betroffene Versionen. Bewerten Sie die Sicherheitswirkung und verlässliche Hinweise auf aktive Ausnutzung. Entscheiden Sie parallel über Maßnahmen und mögliche Meldepflichten. Eine unvollständige Ursachenanalyse darf den erforderlichen fristgerechten Bericht nicht blockieren.

Die Fachthemen im Zusammenhang

SBOM als Grundlage für die Betroffenheitsanalyse nutzen

Ordnen Sie Komponenten und Versionen den tatsächlich ausgelieferten Releases zu. Dann lässt sich bei einer neuen Schwachstelle ermitteln, welche Produkte betroffen sein könnten. Die SBOM braucht Pflege und eine Verbindung zu den Analyse- und Freigabeprozessen.

CRA und SBOM: Software Bill of Materials richtig aufbauen und im Prozess nutzen →

Schwachstellenmanagement vom Eingang bis zum Abschluss führen

Ein Vorgang benötigt Priorität, Verantwortliche, Entscheidung, Maßnahme und Wirksamkeitskontrolle. Beziehen Sie Drittkomponenten und unterstützte Altversionen ein. Der Detailartikel beschreibt einen durchgängigen Ablauf statt einer Sammlung nicht abgearbeiteter Scannerbefunde.

CRA-Schwachstellenmanagement: Vulnerability Handling nach Anhang I Teil II →

CVD für externe Finder und koordinierte Veröffentlichung aufbauen

Eine erreichbare Kontaktstelle und klare Regeln erleichtern qualifizierte Meldungen. Vereinbaren Sie sichere Kommunikation, Rückmeldung und eine abgestimmte Veröffentlichung. CVD ersetzt keine gesetzlichen Meldefristen; beide Prozesse müssen miteinander verbunden werden.

CRA Coordinated Vulnerability Disclosure: CVD-Policy, Security-Kontakt und Ablauf →

PSIRT als verantwortliche Produkt-Sicherheitsfunktion organisieren

Das Team oder die benannten Verantwortlichen koordinieren Produktbetroffenheit, Entwicklung, Kommunikation und Eskalation. Ein bestimmter Teamname ist keine pauschale CRA-Pflicht. Wichtig ist, dass die Funktion tatsächlich entscheiden, vertreten und zeitgerecht handeln kann.

CRA-PSIRT aufbauen: Rollen, Prozesse und Eskalation für Produktsicherheit →

Sicherheitsupdates wirksam und sicher verteilen

Behebung endet nicht beim fertigen Patch. Integrität, Verteilung, Installationshinweise und die unterstützten Versionen müssen berücksichtigt werden. Prüfen Sie außerdem, ob die Korrektur das Problem beseitigt und keine neuen Sicherheitsrisiken erzeugt.

CRA-Sicherheitsupdates: Automatische Updates, Patch-Prozess und sichere Verteilung →

CRA-Meldungen über die Single Reporting Platform vorbereiten

Die Herstellerberichte werden über die ENISA-Plattform eingereicht. Bereiten Sie Zugang, Zuständigkeit, Produktdaten und Fristenkontrolle vor. Der Detailartikel unterscheidet Frühwarnung, weitergehende Meldung und die unterschiedlichen Abschlussfristen.

CRA-Meldepflichten: 24 Stunden, 72 Stunden und Abschlussbericht richtig vorbereiten →

Vier Arbeitsschritte für die Praxis

Sicherheitsmeldung erfassen, zuständiges Team und Vertretung einschalten.
Betroffene Versionen und Komponenten identifizieren; aktive Ausnutzung und Schwere prüfen.
Behebung und Nutzerinformation organisieren; notwendige Meldungen ohne unangemessene Verzögerung einreichen.
Updatewirksamkeit kontrollieren, Abschlussbericht und Prozessverbesserung dokumentieren.

Welche Ergebnisse sollten Sie festhalten?

Verwenden Sie einen produktbezogenen Entscheidungsvermerk. Er benennt Produkt und Version, betrachtete Funktionen, verantwortliche Gesellschaft und das Datum der Bewertung. Halten Sie außerdem die verwendeten Quellen und die offenen Fragen fest. Eine Entscheidung ist erst belastbar, wenn erkennbar ist, auf welchen Informationen sie beruht und wer sie freigegeben hat.

Für jedes offene Arbeitspaket sollten Verantwortliche, Vertretung, Zieltermin und Nachweisziel feststehen. Prüfen Sie den Fortschritt anhand von Ergebnissen: eine freigegebene Bewertung, ein getesteter Prozess oder eine eindeutig zugeordnete Dokumentation. Ein Termin im Kalender oder ein begonnenes Dokument zeigt allein noch nicht, dass die Anforderung umgesetzt ist.

Wann ist eine erneute Prüfung sinnvoll?

Überprüfen Sie die Einordnung bei relevanten Produktänderungen, neuen Vertriebsmodellen, geänderten Lieferanten oder aktualisierten rechtlichen Vorgaben. Ordnen Sie die Überprüfung einem konkreten Anlass zu und bewahren Sie frühere Entscheidungen nachvollziehbar auf. So können Entwicklung und Compliance erkennen, welche Annahmen weiterhin gelten und welche neu bewertet werden müssen.

Nächster Schritt: Wählen Sie oben den Fachartikel, der Ihre wichtigste offene Frage beantwortet. Wenn die Betroffenheit noch unklar ist, beginnen Sie mit dem kostenlosen CRA-Schnellcheck und dokumentieren Sie das Ergebnis anschließend anhand Ihres konkreten Produkts.

Häufige Fragen

Muss jede gefundene Schwachstelle sofort an ENISA gemeldet werden?

Artikel 14 erfasst aktiv ausgenutzte Schwachstellen und bestimmte schwere Sicherheitsvorfälle. Eine bloße Scanner-Fundstelle ist nicht automatisch eine Pflichtmeldung; sie muss dennoch fachlich bewertet und behandelt werden.

Beginnen die 72 Stunden erst nach der Frühwarnung?

Nein. Die gesetzliche 72-Stunden-Frist knüpft wie die Frühwarnfrist an die Kenntniserlangung an. Führen Sie eine eigene Fristenkontrolle und verlassen Sie sich nicht allein auf Anzeigen der Plattform.

Müssen Open-Source-Stewards bereits seit September 2026 melden?

Die besonderen Pflichten für Stewards nach Artikel 24 Absatz 3 beginnen am 11. Dezember 2027. Für eine Organisation, die selbst Hersteller ist, gilt die Herstellerrolle gesondert.

Fachliche Grundlage und weiterführende Themen

Die Einordnung stützt sich auf die Verordnung (EU) 2024/2847 und die Erläuterungen der Europäischen Kommission. Für den Plattformbetrieb und aktuelle Meldeabläufe sind die ENISA-FAQs zur Single Reporting Platform maßgeblich.

Redaktioneller Quellenabgleich dieser Übersicht: 3. Oktober 2026. Beispiele und Arbeitsschritte dienen der praktischen Orientierung; die verbindliche Einordnung richtet sich nach dem geltenden Recht und den Eigenschaften des einzelnen Produkts.

Aktuelle Fachbeiträge vertiefen

Die folgenden veröffentlichten Beiträge ergänzen die Themenübersicht mit konkreten Prüfungen und Umsetzungsschritten.

CRA Schwachstellen & Meldeprozesse: SBOM, CVD, PSIRT und Incident Response