Warum werden es jede Woche mehr Meldungen – und nicht weniger?
Die Zahlen sind eindeutig. 2025 wurden 48.185 Schwachstellen als CVE veröffentlicht, ein Zuwachs von 20,6 Prozent gegenüber dem Vorjahr. Seit 1999 sind rund 308.900 zusammengekommen — jede sechste davon allein im letzten Jahr.
Wie sich das im Alltag anfühlt, sehe ich an unserem eigenen Lagebild-Radar. Vom 7. bis 9. September 2026 liefen dort 275 Meldungen des CERT-Bund auf, 80 davon neu, der Rest Aktualisierungen. 125 sind als „hoch“ eingestuft, sechs als „kritisch“. Drei Tage. Ein Bundesamt. Eine Quelle von vielen. Das Schaubild zeigt, wie schmal es dabei wird — und wo die Verengung aufhört.
Das wächst sich auch nicht aus. Es kommt mehr Software zum Einsatz, mehr Hersteller melden selbst, mehr wird automatisiert gesucht. Die Kurve zeigt nach oben und bleibt da.
Der erste Reflex ist immer derselbe: schneller werden. Mehr Automatisierung, kürzere Patchfenster, noch ein Scanner. Kann ich verstehen. Ist trotzdem der falsche Hebel. Wer 275 Meldungen schneller abarbeitet, arbeitet immer noch 275 Meldungen ab — und die allermeisten davon gehen ihn nichts an.
Warum CVSS im Mittelstand nicht als Priorisierung taugt
Der CVSS-Wert sagt Ihnen, wie schlimm eine Lücke unter Laborbedingungen ist. Er sagt Ihnen nicht, wie schlimm sie bei Ihnen ist. Daran scheitert nach meiner Erfahrung fast jede Bewertung.
Eine Zahl dazu: Der KEV-Katalog der US-Behörde CISA führt nur Schwachstellen, für die ein tatsächlicher Angriff belegt ist. Seit dem Start 2021 stehen dort 1.699 Einträge. Gemessen an rund 308.900 CVEs, die es bis Ende 2025 insgesamt gab, sind das 0,55 Prozent.
Nicht einmal ein Prozent aller je gemeldeten Lücken hat es je in diesen Katalog geschafft. Der Katalog ist nicht vollständig — CISA nimmt vor allem auf, was US-Behörden betrifft. Die Größenordnung sagt trotzdem genug: Der weitaus größte Teil dessen, was bei Ihnen aufschlägt, ist real, aber nicht dringend.
Jetzt könnte man sagen: gut, dann nehmen wir eben diese Liste. Löst die Frage nur leider nicht. Auch von den 1.699 betrifft Sie bloß ein Bruchteil. Nämlich der, für den Sie das Produkt wirklich im Einsatz haben. In der betroffenen Version. In einer Umgebung, in der die Lücke überhaupt erreichbar ist.
Welcher Bruchteil das ist, sagt Ihnen kein Katalog der Welt. Das sagt Ihnen nur Ihr eigenes Verzeichnis.
Welche drei Fragen muss jede Meldung an Ihre Umgebung stellen?
Zum Sortieren brauchen Sie keine zehn Kriterien. Drei reichen. Sie müssen sie nur beantworten können, ohne dass jemand eine Stunde herumtelefoniert.
| Frage | Was Sie dafür brauchen | Wenn die Antwort fehlt |
|---|---|---|
| Setzen wir das Produkt in der betroffenen Version ein? | Verzeichnis mit Produkt, Version, Anzahl | Die Meldung bleibt offen und wandert in eine Liste, die keiner mehr liest |
| Ist das System von außen erreichbar? | Netzplan und Zuständigkeit je System | Sie nehmen das teuerste Szenario an — oder gar keins |
| Hängt ein Geschäftsprozess direkt daran? | Verknüpfung System zu Prozess und Fachbereich | Die IT entscheidet allein, was wichtig ist, und liegt regelmäßig daneben |
Die drei Fragen sind simpel. Beim Kunden kann sie trotzdem kaum jemand aus dem Stand beantworten.
Und genau das ist der Punkt. Nicht die Bewertung ist schwierig — es fehlen die Daten. Jede der drei Fragen geht an ein Inventar, und zwar an eines, das Version, Netzlage und fachliche Verantwortung kennt. Eine Liste von Hostnamen aus dem Monitoring reicht dafür nicht.
Was fehlt, wenn das Sortieren trotzdem nicht klappt?
Ich sehe das regelmäßig in Mandaten. Ein Schwachstellenmanagement ist da. Es gibt einen Scanner, es gibt einen Bericht, es gibt sogar einen monatlichen Termin. Was es nicht gibt: ein vollständiges Verzeichnis der eingesetzten Systeme.
Das Ergebnis ist immer dasselbe. Der Scanner findet, was er erreicht — und er erreicht das, was ohnehin bekannt ist. Die Altanlage in der Fertigung, der Terminalserver für die zwei Außenstellen, das Gerät, das ein Dienstleister vor Jahren mitgebracht hat: nicht im Scan, nicht im Bericht, nicht in der Bewertung. Das ist keine Schlamperei. Das hat nur nie jemand aufgeschrieben.
Und dann wird nach dem entschieden, was übrig bleibt. Nach dem Herstellernamen. Danach, ob es vorgestern in der Fachpresse stand. Nach dem Gefühl des Kollegen, der am längsten dabei ist.
Das ist keine Priorisierung. Das ist Raten mit einem Bericht als Deckung.
An der Stelle kommt fast immer derselbe Einwand: Wir haben doch eine CMDB. Stimmt meistens sogar. Nur wurde die für den Betrieb gebaut, nicht für Sicherheitsentscheidungen. Sie kennt den Server, aber nicht die Version der Anwendung darauf. Sie kennt eine Zuständigkeit in der IT, aber keine im Fachbereich. Für die drei Fragen oben ist sie ein Anfang. Mehr nicht.
Deshalb bin ich hier unbequem: Wer beim Schwachstellenmanagement weiterkommen will, sollte kein Werkzeug kaufen. Er sollte ein halbes Jahr Inventar machen. Das ist undankbar, es sieht nach nichts aus, und in einer Vorstandsvorlage macht es sich schlecht. Aber alles, was ohne diese Grundlage aufgesetzt wird, ist Beschäftigungstherapie mit Prüfspur.
Was NIS2 beim Schwachstellenmanagement wirklich verlangt
Ein Blick ins Gesetz hilft an der Stelle — er rechtfertigt nämlich den Aufwand. NIS2 ist in Deutschland über das BSI-Gesetz umgesetzt, einschlägig ist § 30 BSIG. Der gilt nicht für jeden. Er gilt für Einrichtungen, die das Gesetz als besonders wichtig oder als wichtig einstuft. Wen er trifft, der muss technisch und organisatorisch etwas tun, das geeignet ist, im Verhältnis steht und tatsächlich wirkt. Dahinter hängt ein Katalog mit zehn Feldern — darunter Risikoanalyse, der Umgang mit Sicherheitsvorfällen und ausdrücklich auch, wie Sie mit Schwachstellen umgehen.
Was dort nicht steht: eine Frist, in der Sie eine einzelne Lücke schließen müssen. Auch kein Werkzeug, das Sie kaufen sollen. Für Cloud-Anbieter, Managed Service Provider und ähnliche Dienste kann die EU Genaueres vorgeben, das dann vorgeht. Für den klassischen Mittelständler bleibt es beim Katalog.
Der eigentliche Hebel steht davor. Das Gesetz sagt nämlich selbst, woran sich dieses Verhältnis bemisst: daran, wie stark Sie einem Risiko ausgesetzt sind, wie groß Ihr Unternehmen ist, was die Maßnahmen kosten, wie wahrscheinlich und wie schwer ein Vorfall wäre — und was er wirtschaftlich und gesellschaftlich anrichten würde. Und Sie müssen dokumentieren, dass Sie sich daran halten.
Wie stark Sie einem Risiko ausgesetzt sind. Das wissen Sie nur, wenn Sie wissen, welche Systeme Sie betreiben. Ohne Verzeichnis können Sie es weder bestimmen noch aufschreiben. Nicht gegenüber einer Aufsicht. Nicht gegenüber einem Versicherer. Und schon gar nicht gegenüber der eigenen Geschäftsführung, wenn die fragt, warum dieses Patchfenster gerade drei Projekte schiebt.
Wie fangen Sie an, wenn drei Leute den Betrieb machen?
Nicht mit dem großen Wurf. Ein vollständiges Verzeichnis nach Lehrbuch ist im Mittelstand ein Zweijahresprojekt — und wird deshalb nie fertig.
Was funktioniert, ist der umgekehrte Weg. Fangen Sie bei den Systemen an, die Sie ohnehin kennen. Schreiben Sie zu jedem drei Angaben dazu: Version, Netzlage, fachlich verantwortliche Person. Mehr nicht. Klingt nach wenig. Ist aber die halbe Miete, denn genau diese drei Felder beantworten die drei Fragen von oben.
Dann nehmen Sie einen Monat lang jede Meldung, die bei Ihnen aufschlägt, und halten sie gegen das Verzeichnis. Jedes Mal, wenn Sie eine Frage nicht beantworten können, ist das keine Niederlage — das ist ein gefundener Eintrag. Schreiben Sie ihn auf. Nach vier Wochen kennen Sie Ihre größten Lücken, und zwar belegt statt vermutet.
Eins sollten Sie gleich mitregeln: Jeder vorgezogene Patch verdrängt etwas aus dem Betriebskalender. Machen Sie das sichtbar. Wenn Sicherheit im Stillen gegen Projekte entscheidet, verlieren beide.
Ein Blick von außen hilft hier oft mehr als noch ein Werkzeug. Nicht, weil er mehr weiß. Sondern weil er die unangenehme Frage stellt, ob die Liste wirklich vollständig ist. Genau das machen wir im IT-Lagebild: erst den Bestand aufnehmen, dann über Maßnahmen reden.
Häufige Fragen
Reicht ein Schwachstellenscanner nicht als Inventar?
Nein. Ein Scanner findet, was er im Netz erreicht und wofür er Zugangsdaten hat. Systeme in getrennten Netzen, Anlagen in der Fertigung und Geräte von Dienstleistern fehlen darin regelmäßig — und das sind genau die, die im Ernstfall wehtun. Der Scan ist ein guter Anfang für Ihr Verzeichnis. Er ersetzt es nicht.
Wie ausführlich muss ein Verzeichnis am Anfang sein?
Drei Felder je System reichen, um loszulegen: eingesetzte Version, Erreichbarkeit von außen, fachlich verantwortliche Person. Der Rest kommt dazu, sobald Sie merken, dass es etwas bringt. Ein Verzeichnis, das auf Vollständigkeit wartet, wird nie benutzt.
Muss ich als mittelständisches Unternehmen jede kritische Schwachstelle sofort patchen?
Zunächst: § 30 BSIG greift nur, wenn Ihr Unternehmen überhaupt unter das Gesetz fällt. Ist das so, verlangt die Norm Maßnahmen, die geeignet sind, im Verhältnis stehen und wirken — aber keine feste Frist für jede einzelne Lücke. Sie müssen die Maßnahmen allerdings daran ausrichten, wie stark Sie einem Risiko ausgesetzt sind, und Sie müssen das dokumentieren. Heißt konkret: Sie müssen begründen können, welches System betroffen ist, wie es erreichbar ist und welcher Prozess daranhängt. Ohne Verzeichnis geht das nicht.
Wer sollte im Unternehmen über die Dringlichkeit entscheiden?
Die IT-Leitung bewertet die technische Lage. Die Abwägung gegen laufende Vorhaben gehört aber auf dieselbe Ebene wie jede andere Priorisierung — also dorthin, wo auch über das Projektportfolio entschieden wird. Sonst entscheidet der Zufall, wer lauter ruft.
Woher bekomme ich verlässliche Meldungen über neue Schwachstellen?
Für den deutschen Mittelstand ist der Warndienst des CERT-Bund die naheliegende Quelle, dazu die Herstellerkanäle der Produkte, die Sie tatsächlich einsetzen. Der KEV-Katalog der CISA hilft bei der Dringlichkeit: Steht eine Lücke dort, wurde sie nachweislich angegriffen.