Warum die halbe CVE-Liste Zeitverschwendung ist

Ein einziger Scan gegen einen exponierten Host, und die Liste zählt 672 bekannte Schwachstellen. Vom Uralt-Fund aus dem Jahr 2009 bis zur frischen CVE von diesem Jahr, kritische 9.8er direkt neben Einträgen, die gar keinen Schweregrad tragen. Wer diese Liste von oben nach unten abarbeitet, ist Wochen beschäftigt und am Ende kaum sicherer. Denn die Liste beantwortet nicht die einzige Frage, die zählt: Welche dieser Lücken bedroht wirklich mich?

Warum der CVSS-Score in die Irre führt

Der CVSS-Score misst, wie schlimm eine Schwachstelle im schlimmsten Fall wäre, nicht ob sie in Ihrer Umgebung überhaupt eine Rolle spielt. Eine 9.8 auf einer Software, die bei Ihnen nicht läuft, ist harmloser als eine 6.5, die aus dem Internet erreichbar und aktiv im Umlauf ist. Nach reinem Score zu patchen heißt, die theoretisch schlimmsten Lücken zuerst zu jagen statt der tatsächlich gefährlichsten. Das fühlt sich nach Fortschritt an und ist doch oft die falsche Reihenfolge.

Drei Fragen, die aus einer CVE ein Risiko machen

Aus einer Fundliste wird erst dann eine Prioritätenliste, wenn drei Fragen dazukommen. Sie gelten unabhängig vom Werkzeug:

• Betrifft es mich überhaupt? Läuft die verwundbare Version wirklich, oder hat der Scanner nur einen Namen gematcht? Ein großer Teil jeder Liste fällt schon hier weg.
• Ist es erreichbar? Steht das Asset exponiert am Internet oder im internen Netz hinter mehreren Schichten? Erreichbarkeit entscheidet über die Dringlichkeit mehr als der Score.
• Wird es ausgenutzt? Gibt es einen öffentlichen Exploit, taucht die Lücke in Quellen wie der CISA-KEV-Liste auf, ist die Ausnutzungswahrscheinlichkeit (EPSS) hoch? Eine ausgenutzte 7 schlägt eine ruhige 9.

Nach diesen drei Filtern schrumpfen 672 Funde auf eine Handvoll, die wirklich zuerst dran ist. Der Rest ist nicht ignoriert, nur einsortiert.

Warum das ohne Kontext nicht geht

Das Problem ist selten der fehlende Wille, sondern die Trennung: Die Score-Liste entsteht im Schwachstellen-Scanner, der Kontext liegt woanders. Welches Asset genau, ob es exponiert ist, was daran hängt, welche Entscheidung schon getroffen wurde. Solange Fund und Kontext in zwei Werkzeugen leben, priorisiert man blind und dokumentiert doppelt.

Wie isidaten das zusammenführt

Bei isidaten hängt jeder Fund am konkreten Asset, das der Scan oder die Discovery gefunden hat. Zur Schwachstelle kommt die Hersteller-Advisory samt Exploit-Verfügbarkeit und Erreichbarkeit, und die getroffene Behandlung, ob beheben, kompensieren oder bewusst akzeptieren, bleibt am selben Objekt. Aus 672 Zeilen wird so eine begründete Reihenfolge statt einer Abarbeitungsliste. Wie das Schwachstellenmanagement konkret arbeitet, zeigt die Modulseite, oder direkt in einer Demo.