Vulnerability-Tracking: CVEs monitoren & CRA-konform melden
SBOMfunk ordnet Schwachstellen den Komponenten und Produkten in Ihrer SBOM zu, bündelt Signale aus NVD, OSV und CISA KEV und unterstützt Ihr Team bei Triage, VEX-Dokumentation und dem Meldeworkflow nach CRA Artikel 14.
Was Vulnerability-Tracking im CRA-Kontext leisten muss
Eine CVE-Liste allein beantwortet nicht, ob Ihr Produkt betroffen oder eine Meldung erforderlich ist. Der operative Prozess verbindet aktuelle SBOM-Daten mit Schwachstellenquellen, Produktkontext und einer dokumentierten Entscheidung.
Komponenten zuordnen
Paketname, Version und Identifier aus der SBOM werden gegen bekannte Schwachstellen und betroffene Versionsbereiche geprüft.
Ausnutzung bewerten
CVSS hilft bei der technischen Priorisierung. Für Artikel 14 ist zusätzlich entscheidend, ob die Schwachstelle aktiv ausgenutzt wird und im eigenen Produkt enthalten ist.
Entscheidung belegen
Betroffenheit, Nicht-Betroffenheit, Gegenmaßnahmen und Meldezeitpunkte werden nachvollziehbar dokumentiert.
NVD, OSV und CISA KEV: drei Quellen, drei Aufgaben
SBOMfunk ist für einen täglichen Abgleich konzipiert. Die Quellen ergänzen sich; keine einzelne Datenbank ersetzt die produktspezifische Triage durch Ihr verantwortliches Team.
| Quelle | Spezialisierung | Rolle im Workflow |
|---|---|---|
| NVD | CVE-Datensätze, Referenzen und CVSS-Bewertungen | Breite Basis für bekannte Schwachstellen und technische Einordnung |
| OSV | Open-Source-Pakete, Versionen und betroffene Versionsbereiche | Paketnahes Matching für Abhängigkeiten aus der SBOM |
| CISA KEV | Nachweislich aktiv ausgenutzte Schwachstellen | Priorisierungssignal für die Prüfung eines CRA-Meldetriggers |
Ein CISA-KEV-Treffer ist ein starkes Signal für aktive Ausnutzung, aber noch keine automatische Feststellung, dass Ihr konkretes Produkt betroffen ist. Komponenten-Version, Ausführbarkeit, Konfiguration und Produktarchitektur bleiben zu prüfen.
„Aktiv ausgenutzt“ ist der zentrale Melde-Trigger
Artikel 14 erfasst aktiv ausgenutzte Schwachstellen, die in einem Produkt mit digitalen Elementen enthalten sind und von denen der Hersteller Kenntnis erlangt. Deshalb trennt eine belastbare Triage mindestens drei Fragen: Ist die Komponente vorhanden? Ist die Schwachstelle im Produkt ausnutzbar? Liegen Hinweise auf aktive Ausnutzung vor?
Hoher CVSS-Score und aktive Ausnutzung sind nicht dasselbe. Auch eine schwere CVE löst nicht allein wegen ihres Scores die Meldepflicht für aktiv ausgenutzte Schwachstellen aus.
VEX-Statements reduzieren Fehlalarme nachvollziehbar
Ein VEX-Statement hält maschinenlesbar fest, ob und warum ein Produkt von einer bekannten Schwachstelle betroffen, nicht betroffen oder noch in Prüfung ist. Typische Gründe für „nicht betroffen“ sind nicht ausgeführter Code, eine nicht erreichbare Funktion oder eine nicht vorhandene Konfiguration.
- Entscheidung mit Produkt- und Versionsbezug
- Begründung statt bloßem Statuswechsel
- Zeitstempel und verantwortliche Prüfung
- Aktualisierung, wenn neue Erkenntnisse eintreffen
Der 3-Stufen-Workflow nach CRA Artikel 14
Die gesetzlichen Fristen knüpfen an die Kenntnis des Herstellers an. Die dritte Stufe ist bei Schwachstellen an die Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme gekoppelt.
Frühwarnung
Unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntnis: erste Angaben zur aktiv ausgenutzten Schwachstelle und zu betroffenen Märkten vorbereiten.
Schwachstellenmeldung
Spätestens innerhalb von 72 Stunden nach Kenntnis: verfügbare Informationen zur Schwachstelle, Ausnutzung, zum Produkt und zu Maßnahmen ergänzen.
Abschlussbericht
Spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme: Beschreibung, Schweregrad, Ausnutzung und Korrektur dokumentieren.
Rechtsgrundlage: Verordnung (EU) 2024/2847, Artikel 14 Absatz 1 und 2. Die Meldepflichten gelten ab 11. September 2026.
Beispiel-Timeline: vom KEV-Treffer zur Frühwarnung
Das Beispiel zeigt einen internen Ablauf. Der tatsächliche Fristbeginn richtet sich nach der Kenntnis des Herstellers, nicht pauschal nach der Veröffentlichung eines Datenbankeintrags.
Treffer erkannt
Eine Komponente aus der aktuellen SBOM wird einem neuen CISA-KEV-Eintrag zugeordnet.
Produktbezug prüfen
Das Product-Security-Team prüft betroffene Versionen, Erreichbarkeit, Konfiguration und tatsächliche Ausnutzbarkeit.
Entscheidung dokumentieren
Betroffen: Meldeworkflow und Fristen starten. Nicht betroffen: Begründung als VEX-Statement revisionsfähig festhalten.
Frühwarnung vorbereiten
Bei bestätigtem CRA-Meldetrigger stehen Produkt-, CVE- und Bewertungsdaten für die erste Meldestufe bereit.
Alerts dort, wo Ihr Team arbeitet
Relevante Treffer lassen sich an zuständige Teams weitergeben, damit Prüfung und Dokumentation nicht in einem isolierten Dashboard liegen bleiben.
Slack
Hinweise für Security- und Produktkanäle.
Benachrichtigungen an definierte Verantwortliche.
Webhook
Übergabe an eigene Workflows und Ticket-Systeme.
Frist-Status
Meldestufen und dokumentierte Kenntnisnahme im Blick.
Vulnerability-Tracking mit Ihrer SBOM verbinden
Sichern Sie sich einen Beta-Platz für SBOMfunk und testen Sie den Workflow von der Komponentenliste über die CVE-Triage bis zur Vorbereitung der CRA-Meldung.
Beta-Zugang sichernDie finale rechtliche Bewertung und Meldentscheidung verbleibt bei Ihrem Unternehmen.