Ein kritischer CVE ist nicht automatisch kritisch fuer euer Projekt. Der Kontext entscheidet.
Ein CVE mit einem hohen CVSS-Score klingt beaengstigend. Ist die betroffene Komponente aber nur intern genutzt, nicht aus dem Internet erreichbar, und setzt der Exploit-Pfad eine Authentifizierung voraus, die bereits vorhanden ist, dann ist das Risiko real ueberschaubar.
Wer jeden kritischen CVE mit gleicher Prioritaet behandelt, verbrennt Kapazitaet, und vernachlaessigt vielleicht einen mittleren CVE, der im eigenen Setup hochgefaehrlich ist.
Risikobewertung im Kontext
Relevante Fragen pro CVE: Ist die betroffene Komponente von aussen erreichbar? Gibt es einen bekannten, aktiv genutzten Exploit? Welche Daten waeren bei Ausnutzung gefaehrdet? Tools wie Snyk oder Dependabot liefern teilweise Reachability-Analysen, die pruefen, ob der verwundbare Code-Pfad im eigenen Projekt ueberhaupt erreichbar ist.
Ein Priorisierungs-Framework
Sofort, innerhalb von 24 Stunden, bei kritischem CVE mit aktivem Exploit und externer Erreichbarkeit. Innerhalb einer Woche bei kritischem CVE ohne aktiven Exploit oder mit eingeschraenktem Exposure. Zum naechsten Release bei mittleren CVEs. In den Backlog bei niedrigen CVEs ohne realistischen Exploit-Pfad.
Wenn ein Update Breaking Changes hat
Manchmal gibt es keinen schnellen Patch. Dann helfen temporaere Mitigations wie eine WAF-Regel, Netzwerk-Segmentierung oder das Deaktivieren einer Funktion, bis ein kompatibles Update moeglich ist, dokumentiert als bewusste, temporaere Entscheidung.
Checkliste: Dependency-Scan im CI mit CVE-Output, kontext-basierte Risikobewertung statt reinem CVSS-Score, aktiv ausgenutzte CVEs als Quelle beruecksichtigt, Priorisierungs-Framework dokumentiert, Mitigation-Strategie fuer Breaking-Change-Updates definiert.
Ein Beispiel aus der Praxis
Ein Team erhielt eine automatische Warnung ueber eine kritische Schwachstelle in einer Bibliothek mit dem hoechstmoeglichen CVSS-Score und reagierte zunaechst mit Alarmstimmung. Eine genauere Pruefung zeigte, dass die betroffene Funktion im eigenen Projekt gar nicht aufgerufen wurde, der verwundbare Codepfad war schlicht nicht erreichbar. Statt eines riskanten Notfall-Updates am selben Abend wurde das Update regulaer in den naechsten geplanten Release aufgenommen, getestet und ohne Zeitdruck ausgerollt.
Security-Patch-Prozess fuer euer Projekt aufsetzen? markom.digital implementiert strukturiertes Vulnerability Management, von der Erkennung bis zur Behebung.
