Risikobasierte Schwachstellenpriorisierung: Wie der Asset-Kontext den CVSS-Score ergänzt

2025 war ein Rekordjahr in Bezug auf die Anzahl veröffentlichter Schwachstellen. Über 48.000 Schwachstellen wurden erfasst, was im Durchschnitt 130 pro Tag entspricht. (https://cve.icu/index.html) Der Trend verlangsamt sich nicht: In der ersten Hälfte des Jahres 2026 wurden 36.000 Schwachstellen veröffentlicht – fast 50 % mehr als im selben Zeitraum des Vorjahres. Laut der Prognose von FIRST werden bis Jahresende rund 66.000 neue Schwachstellen erwartet. (https://www.first.org/newsroom/releases/20260615)

Dieses Wachstum fordert seinen Tribut von den Sicherheitsteams, die für das Schwachstellenmanagement verantwortlich sind. Das Ungleichgewicht zwischen der Zahl der zu bewertenden Punkte und der Kapazität, sie zu beheben, vertieft sich immer weiter. Es ist sogar bei Institutionen spürbar, die eigens zur Katalogisierung von Bedrohungen geschaffen wurden, etwa bei der amerikanischen NVD (National Vulnerability Database). Laut ihrer Ankündigung vom 15. April 2026 ändern sie ihren Priorisierungsmechanismus. Sie werden zunächst Schwachstellen aus dem KEV-Katalog (CISAs Known Exploited Vulnerabilities – https://www.cisa.gov/known-exploited-vulnerabilities-catalog) anreichern, die föderale und kritische Software betreffen (wie definiert in https://www.nist.gov/system/files/documents/2026/04/15/EO%2014028%20Critical%20FINAL.pdf). Die übrigen Schwachstellen werden weiterhin in die NVD-Datenbank aufgenommen, aber als niedrig priorisiert markiert – ohne dass eine unmittelbare Analyse oder Anreicherung ihrer Beschreibungen geplant ist.

Diese Situation verdeutlicht klar, dass der traditionelle Ansatz auf Basis des CVSS-Scores (Common Vulnerability Scoring System) unter den heutigen Bedingungen unzureichend ist. Das Beispiel der NVD bestätigt, dass ein neuer Ansatz im Schwachstellenmanagement erforderlich ist, denn die heutige Herausforderung lautet nicht mehr „Wie patche ich jede Lücke?”, sondern „Was sollte zuerst behoben werden, um das Risiko am wirksamsten zu senken?”. Eine solche Lösung ist in SecureVisio umgesetzt – im Folgenden zeigen wir, wie dieselbe Schwachstelle je nach Bedeutung des Assets, auf dem sie auftritt, unterschiedliche Prioritäten erhalten kann.

Was CVSS misst – und was nicht

CVSS – das Common Vulnerability Scoring System – ist ein internationaler, offener Standard zur Bewertung von Schwachstellen in Systemen und in der Softwaresicherheit. Er legt fest, wie schwer eine bestimmte Schwachstelle auszunutzen ist und wie schwerwiegend die Folgen einer erfolgreichen Kompromittierung wären. Den CVSS-Standard gibt es in mehreren Versionen, z. B. v2.0 (Legacy), v3.x und v4.0. Letztere ist die neueste und wird seit 2023 verwendet. Datenbanken wie CVE und NVD sowie Software zum Scannen und Verwalten von Schwachstellen arbeiten typischerweise mit mehreren Versionen parallel, weshalb dieselbe Schwachstelle oft zwei oder sogar drei Scores trägt, die den verschiedenen Versionen des Standards entsprechen.

Diese Scores bestehen aus drei Metrikgruppen, die für jede Version gleich sind, auch wenn sich die enthaltenen Metriken unterscheiden. Nachfolgend eine Beschreibung von v3.1, da diese am häufigsten anzutreffen ist – v2 ist bereits veraltet, und v4 wird erst jetzt eingeführt.

CVSS v3.1 unterteilt den Score in drei Metrikgruppen:

Basis-Metriken (Base Metrics) – statische Merkmale der Schwachstelle, unabhängig von Zeit und Umgebung. Sie sind verpflichtend, da sie den „rohen” CVSS-Score erzeugen.Zeitliche Metriken (Temporal Metrics) – diese verändern sich über die Lebensdauer der Schwachstelle und spiegeln den aktuellen Wissensstand und die Reaktion auf die CVE wider. Sie sind optional und können den Base Score senken. Umgebungs-Metriken (Environmental Metrics) – diese passen den Score an eine konkrete Organisation/Infrastruktur an. Sie sind optional und erlauben es, den Base Score zu überschreiben und ein geschäftliches Gewicht hinzuzufügen.

Man erkennt hier den Versuch, das Problem des Risikos zu adressieren, das aus den Merkmalen eines konkreten Systems entsteht. In der Praxis ist jedoch fast ausschließlich der Base Score im Umlauf: In Datenbanken wie der NVD veröffentlichte Schwachstellen enthalten diese Metrik, während die übrigen meist leer bleiben. Die nächste Version des Standards, 4.0, verbessert die Präzision der technischen Bewertung selbst, ändert aber nichts daran, dass es sich um ein Maß für die Schwere handelt, nicht für das Risiko in einer konkreten Umgebung. Eine vollständige Beschreibung der einzelnen Versionen ist unter https://www.first.org/cvss/ verfügbar.

Der entscheidende Punkt ist, dass der Base Score universell ist – er ist für alle Organisationen gleich und unabhängig davon, wo eine bestimmte Schwachstelle auftritt. Er sagt nichts über die realen Folgen in einer tatsächlichen Umgebung aus. Er beschreibt die Auswirkung ausschließlich auf die verwundbare Komponente selbst, aus rein technischer Sicht, und ignoriert den organisatorischen Kontext. Die NVD selbst weist darauf hin und stellt ausdrücklich fest, dass CVSS kein Maß für das Risiko ist (https://nvd.nist.gov/vuln-metrics/cvss).

Die so verstandene Schwere mit dem Risiko gleichzusetzen führt zu fehlerhaften Entscheidungen. Das Risiko ist das kombinierte Produkt aus Schwere, Wahrscheinlichkeit der Ausnutzung und dem Wert des Assets, das die Schwachstelle exponiert – und der Base-CVSS-Score beschreibt nur das erste dieser Elemente. Daraus ergeben sich konkrete Einschränkungen:

Die Metriken, die die Umgebung beschreiben, bleiben leer. Obwohl der Standard sie vorsieht, ist es viel zu aufwendig, sie für Tausende von Einträgen manuell auszufüllen, sodass dies selten geschieht. In der Folge verliert der Score das einzige Element, das ihn mit dem Kontext der Organisation verbinden würde.

Im heutigen Ausmaß differenziert der Score allein die Schwachstellen kaum noch. 2025 wurden 8 % der veröffentlichten Schwachstellen kritische Scores zugewiesen und sogar 31 % hohe Scores (https://nvd.nist.gov/general/visualizations/vulnerability-visualizations/cvss-severity-distribution-over-time). Bei 48.000 Schwachstellen bedeutet das weit über zehntausend als dringend eingestufte Schwachstellen. Kein Team kann so viele Schwachstellen als Prioritäten behandeln, sodass diese Information für die Entscheidung über die Reihenfolge der Arbeit nicht nützlich ist.

Der Score ist statisch – er wird einmal vergeben und ändert sich in der Regel nie, selbst wenn für eine bestimmte Schwachstelle ein neuer, öffentlich und breit verfügbarer Exploit erscheint. Die Information darüber, ob eine Schwachstelle tatsächlich ausgenutzt wird, ist nicht Teil des Base Scores.

NIS2, das NIS2UmsuCG und die Schwachstellenbewertung

Die Folgen für eine konkrete Organisation bei der Bewertung von Schwachstellen zu berücksichtigen, ist nicht bloß gute Praxis. Für viele Einrichtungen ist es eine gesetzliche Pflicht, die sich aus der NIS2-Richtlinie und in Deutschland aus dem NIS2-Umsetzungsgesetz ergibt – dem NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), das NIS2 vor allem durch eine grundlegende Novellierung des BSI-Gesetzes (BSIG) in deutsches Recht überführt. Die Vorschriften schreiben weder eine bestimmte Methode der Schwachstellenpriorisierung vor noch verbieten sie CVSS, aber sie verlangen Risikomanagement und die Anwendung von Maßnahmen, die im Verhältnis zur Bedrohung stehen. Der Grundsatz der Verhältnismäßigkeit ist hier zentral. Nach § 30 BSIG muss die Auswahl der Maßnahmen dem Grad der Risikoexposition der Einrichtung, ihrer Größe sowie der Eintrittswahrscheinlichkeit und Schwere möglicher Folgen einschließlich ihrer wirtschaftlichen und gesellschaftlichen Auswirkungen entsprechen. In diesem Licht kann das Sortieren von Schwachstellen allein nach ihrer technischen CVSS-Schwere, losgelöst von den Folgen für die Organisation, kaum als ausreichend gelten, um einen risikobasierten Ansatz nachzuweisen. Eine Priorisierung, die den Asset-Kontext und die Folgen berücksichtigt, ist der natürliche Weg, diese Verhältnismäßigkeit umzusetzen – und zu dokumentieren.

Es sei ergänzt, dass die Erwartung des Regulierers mit einer breiteren Branchenentwicklung übereinstimmt, die als risikobasiertes Schwachstellenmanagement (Risk-Based Vulnerability Management, RBVM) bezeichnet wird. Dies ist nicht der Ansatz eines einzelnen Herstellers, sondern ein Marktstandard mit einem gemeinsamen Nenner: Die technische Schwere ist der Ausgangspunkt, während die Reihenfolge der Behebung durch die Wahrscheinlichkeit der Ausnutzung und die Bedeutung des Assets für die Organisation bestimmt wird. Einzelne Werkzeuge setzen dies auf unterschiedliche Weise um, und SecureVisio ist eine solche Umsetzung – eine, bei der der gesamte Kontext innerhalb einer einzigen Plattform entsteht.

Bedrohungskontext vs. Asset-Kontext

Die tatsächliche Schwachstellenpriorität – diejenige, die für ein wirksames Schwachstellenmanagement und für die Erfüllung regulatorischer Anforderungen benötigt wird – hängt von zwei unabhängigen Fragen ab:

Die erste kommt aus der Außenwelt: welche Schwachstellen existieren und wie schwerwiegend sie ihrer Natur nach sind, unabhängig von der Umgebung. Dies beantworten Schwachstellendatenbanken mit CVSS-Scores und Scanner, die Fehler in Komponenten aufspüren. Dies ist eine rein technische Ebene. Sie bestimmt nicht, was eine bestimmte Schwachstelle in einer konkreten Umgebung exponiert.

Die zweite betrifft die konkrete Organisation: was geschieht, wenn die Schwachstelle auf genau diesem Asset ausgenutzt wird – welche Prozesse betroffen sind. Dies ist Wissen an der Grenze zwischen der geschäftlichen und der technischen Welt: welches Betriebssystem auf dem Asset läuft, wie es geschützt ist, welche Daten es verarbeitet, welche Geschäftsprozesse es unterstützt. Kein externes Werkzeug und keine externe Organisation kann diese Daten liefern, weil sie für jede Organisation spezifisch sind. Und genau diese Daten sind entscheidend, wenn es darum geht, das tatsächliche Gewicht einer Schwachstelle zu bestimmen.

Ein einfaches Beispiel verdeutlicht dies. Eine kritische RCE-Schwachstelle – die Möglichkeit, Code aus der Ferne auszuführen – mit einem CVSS-Score von 9,8 auf einem Produktionsserver in der DMZ, der einen zentralen Zahlungsprozess unterstützt und personenbezogene Daten von Kunden verarbeitet: Dies ist ein potenzieller Vorfall mit gravierenden geschäftlichen und rechtlichen Folgen. Nehmen wir nun dieselbe Schwachstelle auf einem Testserver in einem isolierten Netzsegment, ohne externen Zugriff und ohne Internetverbindung, der mit Testdaten arbeitet. Hier ist die Situation weit weniger ernst – das Risiko ist begrenzt. Der CVSS-Score ist in beiden Fällen identisch; der Unterschied wird erst sichtbar, sobald der Kontext dieser Assets hinzugefügt wird. Genau dieser Ansatz ist in SecureVisio umgesetzt.

CVSS und Asset-Kontext in der Praxis

Damit ein Algorithmus zur Schwachstellenpriorisierung einen Testserver von einem Produktionssystem unterscheiden kann, benötigt er strukturiertes Wissen über die Assets. Die Kombination einer CMDB-Asset-Datenbank mit einer Business Impact Analysis (BIA) und einer Risikoanalyse kann diese Informationen liefern. Auf dieser Architektur baut die SecureVisio-Plattform auf, in der das Schwachstellenmanagement mit den übrigen Modulen integriert ist und als ein einziges, über eine gemeinsame Konsole verfügbares Werkzeug arbeitet.

SecureVisio konsolidiert die Asset-Daten über eine bidirektionale Integration zwischen dem CMDB- und dem Schwachstellenmanagement-Modul. Jedes Asset kann Informationen über seinen Eigentümer, sein Kritikalitätsniveau und die zugehörigen unterstützten Geschäftsprozesse tragen, und das System ordnet die technischen Informationen aus einem Schwachstellen-Scan automatisch konkreten Assets zu. Die CMDB fungiert hier als logische Karte der Infrastruktur, die die Verbindungen zwischen den Assets zeigt. Eine weitere Ebene fügt die BIA hinzu, die die Folgen identifiziert – was die Organisation verliert, wenn die Sicherheit eines bestimmten Assets verletzt wird. Das Risikoanalyse-Modul nutzt diese Informationen, um die Wahrscheinlichkeit konkreter Angriffe auf konkrete Assets zu bewerten und deren Auswirkung darzustellen.

In der Praxis umfasst der Asset-Kontext Attribute, die das System mit konkreten Schwachstellen abgleicht, darunter:

Standort und Exposition des Assets, z. B. Präsenz in der DMZ, IP-Adressierung, Klassifizierung des Assets, z. B. ob es sich um eine Workstation, einen Test- oder Produktionsserver oder eine Datenbank handelt, Kritikalität des Assets, zugehörige Geschäftsprozesse, autorisierte Kommunikation, z. B. die Information, dass das Asset im Rahmen eines der Geschäftsprozesse dem Internet ausgesetzt ist.

Der CVSS-Score und die Daten aus dem Schwachstellenbericht werden auf diesen Kontext aufgesetzt, sodass sich technische Informationen mit organisatorischem Wissen verbinden lassen. Dank der Kohärenz der Plattform funktioniert die Beziehung in beide Richtungen: Schwachstelleninformationen reichern die Daten in der CMDB an, und Kontextdaten verändern die Prioritäten im Schwachstellenmanagement-Modul. Auch die Risikoanalyse funktioniert in beide Richtungen – ihre Ergebnisse beeinflussen die Schwachstellenprioritäten, und Schwachstellendaten reichern die Analyse selbst an. Die Module SIEM, SOAR und UEBA können ebenfalls am Aufbau des Kontexts und an dessen Nutzung mitwirken.

Das Ergebnis dieses Ansatzes ist, dass ein abstrakter Schwere-Score in eine Information mit operativer Bedeutung überführt wird – zum Beispiel: Diese Schwachstelle betrifft ein System, das die Kundenabrechnung abwickelt und dem eine zusätzliche Schutzschicht fehlt. Eine solche Beschreibung macht es möglich, die Reihenfolge der Behebungsarbeiten realistisch festzulegen.

Die Priorisierungsformel in SecureVisio

Der Mechanismus, der in SecureVisio den Kontext in Priorität überführt, ist einfach: Der im Bericht des Schwachstellen-Scanners zurückgegebene Schwere-Score wird mit einer internen Priorität multipliziert und durch eingebaute Schwachstellen-Priorisierungsregeln modifiziert. Das Ergebnis ist ein Score, der die tatsächliche Bedeutung einer bestimmten Schwachstelle für die konkrete Organisation widerspiegelt. Er lässt sich als Formel schreiben:

Scanner-Schwere × interne Priorität × eingebaute Priorisierungsregeln = tatsächliche Priorität

Jeder dieser drei Faktoren ist für unterschiedliche Elemente der Bewertung verantwortlich und trägt eine andere Art von Kontext zum Ganzen bei.

Die Scanner-Schwere ist der in diesem Artikel ausführlich beschriebene Base Score. Das System verwirft diesen Score nicht, weil er wesentliche technische Informationen über die Schwachstelle selbst enthält und als Ausgangspunkt für die weiteren Berechnungen dient.

Die interne Priorität fügt Asset- und Geschäftskontext hinzu; sie stammt aus der CMDB, der BIA und der Risikoanalyse. Sie beantwortet die Fragen, die ein Scanner nicht verifizieren kann: wie kritisch das Asset ist, wie kritisch die darauf laufenden Geschäftsprozesse sind, welche Systeme von ihm abhängen. Es sind diese Faktoren, die scheinbar identische Schwachstellen am stärksten differenzieren.

Die eingebauten Priorisierungsregeln sind Bedingungen, die die über die verschiedenen Module des Systems gesammelten Asset-Informationen prüfen. Nicht alle wirken in dieselbe Richtung: Manche Regeln erhöhen die Priorität, andere senken sie, je nach der in einer bestimmten Regel hinterlegten Bedingung. In dieser Phase fließen die Erreichbarkeit des Assets und die realistische Möglichkeit, die Schwachstelle auszunutzen, in die Bewertung ein – etwas, das der Base Score allein nicht erkennen kann. Die Priorität wird durch Bedingungen erhöht wie: das Asset ist dem Internet ausgesetzt oder in der DMZ platziert, es fehlt ein kompensierender Mechanismus (z. B. eine WAF vor dem Dienst), oder es liegen dem Asset zugeordnete Kompromittierungsindikatoren (IoC) vor. Die Priorität wird durch die entgegengesetzten Bedingungen gesenkt, z. B.: vollständige Isolation des Assets, wirksame kompensierende Kontrollen oder geringe Kritikalität der verarbeiteten Daten. Dadurch erhält dieselbe Schwachstelle eine unterschiedliche Priorität, nicht nur auf Basis des Werts des Assets, sondern auch auf Basis dessen, wie realistisch es für einen Angreifer erreichbar ist.

Der Regelsatz ist nicht abgeschlossen. SecureVisio erlaubt es Organisationen, eigene Priorisierungsregeln zu erstellen und die Standardregeln zu modifizieren. Dies macht es möglich, die Schwachstellen- und Risikomanagement-Policy einer bestimmten Organisation abzubilden. Die Korrelations-Engine kombiniert all diese Faktoren in Echtzeit zu einem einzigen Urteil und entlastet Analysten von der Notwendigkeit, für jede von Hunderten oder gar Tausenden Schwachstellen zahlreiche Parameter manuell zu prüfen. Das Ergebnis ist eine Schwachstellenliste, geordnet nach ihrer Bedeutung für die Organisation, statt nach technischer Schwere losgelöst von der Umgebung.

Beispiel: Dieselbe Schwachstelle auf zwei Assets

Die Formel lässt sich am besten an einer einzelnen Schwachstelle demonstrieren, die auf zwei verschiedenen Assets auftritt. Die nachstehenden Werte sind illustrativ – die genaue Bewertungsskala hängt von der Konfiguration der Organisation ab –, aber die Mechanik bleibt unverändert.

Die kritische Schwachstelle CVE-2026-33824 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33824), bewertet mit 9,8, ermöglicht die Ausführung von Code aus der Ferne auf einer verwundbaren Maschine. Ein Schwachstellen-Scanner hat sie auf zwei Servern erkannt.

Server A:

PRD-DB-01 ist eine extern in der DMZ exponierte Produktionsdatenbank, die personenbezogene Daten verarbeitet. All diese Informationen sind in SecureVisio verfügbar, wie im folgenden Screenshot dargestellt.

Abbildung 1. Asset-Kontext für PRD-DB-01, verfügbar in SecureVisio

Server B:

TST-DB-01 ist eine Testdatenbank, die nur innerhalb des lokalen Netzwerks erreichbar ist, ohne Internetzugang, ohne Produktionsdaten und ohne Verbindungen zu Produktionssystemen. All diese Informationen sind in SecureVisio verfügbar, wie im folgenden Screenshot dargestellt.

Abbildung 2. Asset-Kontext für TST-DB-01, verfügbar in SecureVisio

Beide Fälle tragen einen kritischen Base Score, doch die Priorität, die den organisatorischen Kontext berücksichtigt, differenziert diese Schwachstellen erheblich. Dies ist im folgenden Screenshot sichtbar. Auf dem Produktionsserver ist die Schwachstelle als kritisch markiert (rot), während sie auf dem Testserver nur mittel ist (gelb) – sodass das Schwachstellen-Team unmittelbar bei der Erkennung weiß, welche zuerst zu bearbeiten ist. Hätte es am Standardansatz allein auf Basis von CVSS festgehalten, wäre diese Entscheidung nicht so einfach. In einem Ausmaß, das in Hunderten oder Tausenden von Schwachstellen gemessen wird, schlägt sich dieser Unterschied unmittelbar in der Wirksamkeit des gesamten Prozesses nieder. Die Schwachstelle auf dem Testserver landet mit ihrer mittleren Priorität in der Mitte der Gesamtliste, sodass ihre Bearbeitung Schwachstellen, die im Kontext der Organisation kritischer sind, nicht in den Schatten stellt.

Abbildung 3. Schwachstellenprioritäten in SecureVisio

Die Bedingung für Wirksamkeit: die Qualität der Asset-Daten

Die kontextbasierte Priorisierung hängt von den Daten ab, die sie speisen. Ist die CMDB unvollständig oder veraltet und wurden die Risiko- und Business-Impact-Analysen nicht durchgeführt, wird sich das Endergebnis nicht wesentlich von CVSS unterscheiden. Der Wert dieses Ansatzes wächst mit der Qualität der Asset-Informationen.

Die Umsetzung dieses Schwachstellenbewertungsmodells erfordert keine einmalige Revolution. Sie besteht darin, die Entscheidung von der Ebene eines einzelnen technischen Scores auf die Ebene des gesamten Prozesses zu verlagern. In der Praxis läuft es auf einige wenige Bereiche hinaus:

Asset-Inventarisierung und -Klassifizierung. Assets sollten Eigentümer, Kritikalitätsniveaus und die von ihnen unterstützten Geschäftsprozesse zugewiesen bekommen. Es lohnt sich, mit den für die Organisation wichtigsten zu beginnen.

Verknüpfung des Inventars mit Scan-Ergebnissen. Sicherstellung eines freien Informationsflusses zwischen Scanner-Berichten und der CMDB. Eine bidirektionale Integration zwischen der CMDB und dem Schwachstellenmanagement-Modul bedeutet, dass jede Schwachstelle sofort einem Asset samt seinem Kontext zugeordnet wird.

Abstimmung der Priorisierungsregeln. Übersetzung des Expertenwissens des Teams in einen wiederholbaren Mechanismus. Die Standardregeln sind ein guter Ausgangspunkt, doch es sind die Regeln, die die Besonderheiten der Organisation abbilden – zu DMZ-Exposition, erforderlicher WAF-Präsenz oder Datenklassen –, die ihr tatsächliches Risiko am besten erfassen.

Schließen des Behebungskreislaufs. Eine Priorität ohne zugewiesenen Eigentümer und ohne Nachverfolgung der Behebungszeit bleibt nur ein Score. Die Weiterleitung der höchstpriorisierten Schwachstellen an konkrete Personen und die Überwachung des Fortschritts sind es, die bessere Priorisierung in eine reale Risikoreduzierung überführen.

Je mehr dieser Elemente innerhalb einer einzigen Plattform, auf einem gemeinsamen Asset-Modell, arbeiten, desto geringer sind die Kosten für die Pflege des Ganzen und desto kleiner das Risiko, dass der Kontext zwischen getrennten Werkzeugen veraltet. Die Architektur der SecureVisio-Plattform macht es möglich, all diese Bereiche an einem gemeinsamen Ort umzusetzen. Zusätzlich ermöglicht die Kopplung mit dem SIEM-/UEBA-Modul (ebenfalls Teil von SecureVisio) eine weitreichende Automatisierung. Der CMDB-Kontext kann auf Basis der vom SIEM gesammelten Logs aufgebaut werden; dedizierte Korrelationsregeln können Dinge erkennen wie: den Asset-Typ, laufende Dienste, die wahrgenommene Rolle (z. B. DNS, Domänencontroller), den Standort der Benutzer, die sich mit Diensten verbinden, die vorhandenen Sicherheitskontrollen und so weiter. Die Vereinfachung und Beschleunigung des Inventarisierungsprozesses ist nicht der einzige Vorteil dieses Ansatzes. Den Kontext auf realen Daten aufzubauen – in diesem Fall Umgebungs-Logs – erhöht die Glaubwürdigkeit dieser Informationen erheblich. Betrachten wir folgende Situation: Vor sechs Monaten wurde auf einem Server eine Host-Firewall bereitgestellt; diese Information gelangte in das Inventar und wird bis heute in Risikobewertungen verwendet. Vor einem Monat wurden jedoch Wartungsarbeiten an diesem Asset durchgeführt, und weil die Firewall benötigten Datenverkehr blockierte, wurde sie deaktiviert. Nach den Arbeiten hat sie niemand wieder eingeschaltet. Die Schwachstellenbewertung wird auf realem, aber veraltetem Kontext durchgeführt – während SecureVisio, wenn Informationen über Sicherheitskontrollen direkt aus dem System (den Logs) bezogen werden, erkennt, dass die Host-Firewall nicht mehr aktiv ist, und die Prioritäten der erkannten Schwachstellen nicht länger senkt.

Fazit

CVSS bleibt ein wertvolles Maß für die technische Schwere, beantwortet aber nicht die Frage, vor der jedes Team beim Blick auf eine Liste von Tausenden Schwachstellen steht: was zuerst zu beheben ist. Der Base Score ist universell – identisch für eine Produktionsdatenbank in der DMZ und für eine Testmaschine –, sodass er Schwachstellen nicht nach ihrer Bedeutung für die Organisation differenziert.

Nur der Asset-Kontext leistet das: das Wissen darüber, was eine bestimmte Schwachstelle exponiert, welchen Prozess sie unterstützt und wie sie geschützt ist. SecureVisio überführt dies in eine Priorität, indem es die Scanner-Schwere mit der internen Priorität (aus CMDB, BIA und Risikoanalyse) multipliziert und mit eingebauten Regeln korrigiert. In der Folge erhält dieselbe CVE-2026-33824 eine Priorität, die davon abhängt, wo sie auftritt, und die Behebungsliste spiegelt das geschäftliche Risiko wider statt eines technischen Rankings losgelöst von der Umgebung.

Das Ganze funktioniert nur so gut, wie die Asset-Daten aktuell sind. Deshalb lohnt es sich, mit den wichtigsten Systemen zu beginnen und den Kontext, wo immer möglich, aus realen Daten (SIEM-/UEBA-Logs) aufzubauen, was ihn im Einklang mit dem tatsächlichen Zustand der Umgebung hält.