Schwachstellen: von der CVE zur Fachanwendung
Jede Woche bringt ihre kritischen Schwachstellen. Die eigentliche Frage lautet: Welche davon betreffen Ihre Fachanwendungen, und wer muss handeln? KANAP kann Ihnen helfen, von der veröffentlichten CVE bis zur dokumentierten Entscheidung, einschließlich der Ermittlung der betroffenen Server und Anwendungen.
Donnerstagmorgen meldet der Feed dreißig neue kritische Schwachstellen. Der CISO fragt, welche davon uns betreffen. Das Infrastrukturteam öffnet eine Tabelle, sucht Produkte, Versionen und Server heraus und meldet sich mal hier, mal dort an, um nachzusehen. Am nächsten Tag ist sich noch immer niemand sicher, vollständige Informationen zu haben.
Das Problem ist der Weg von einer veröffentlichten Schwachstelle zu der Fachanwendung, die sie bedroht. Hier ist die Methode, um dieser Spur zu folgen, und so bringt KANAP sie auf einen einzigen Bildschirm.
Vier Kettenglieder für eine Antwort
Eine Schwachstelle betrifft ein Produkt und bestimmte Versionen. Um zu wissen, ob sie Sie betrifft, müssen vier Kettenglieder verbunden werden:
- Die Technologie: SQL Server, Tomcat, vCenter, das, was Ihre Anwendungen zum Funktionieren brauchen.
- Ihre Version: SQL Server 2019 hat nicht dieselben Schwachstellen wie SQL Server 2022.
- Der Server, auf dem sie läuft.
- Die Fachanwendung, die davon abhängt, mit ihrer Kritikalität und ihrem Verantwortlichen.
In KANAP sind alle diese Glieder vorhanden: die Anwendungen und ihre Server in der IT-Landschaft, die Technologien und ihre Versionen dazwischen.
Zwei offizielle Quellen, kombiniert

Alle 6 Stunden liest KANAP die NVD, die US-amerikanische Schwachstellendatenbank, und gleicht jede Schwachstelle Version für Version mit Ihren Technologien ab. Die NVD ist die Referenz, hat aber eine Schwäche: Sie ordnet Schwachstellen den Produkten mit Verzögerung zu, und manchmal gar nicht.
Ein Beispiel mit einer Technologie, die alle einsetzen. Im Jahr 2026 hat die Apache Software Foundation 60 Schwachstellen von Apache Tomcat veröffentlicht. Am 23. Oktober hatte die NVD 40 davon dem Produkt zugeordnet. Die übrigen 20, veröffentlicht am 23. September und am 20. Oktober, darunter 6 kritische und 7 hohe, hatten in der NVD noch kein Produkt.
KANAP liest deshalb eine zweite Quelle: die Einträge, die die Hersteller selbst auf CVE.org veröffentlichen, mit ihren Produkten und Versionen. Eine Zeile entsteht, sobald eine der beiden Quellen die Schwachstelle Ihrer Technologie zuordnet. Hat die NVD eine Schwachstelle noch nicht bewertet, zeigt KANAP die Bewertung des Herstellers an.
Jede Zeile sagt, welche Quelle sie gefunden hat: die NVD, der Hersteller oder beide. „Warum diese Zeile“ nennt das Kriterium im Klartext, zum Beispiel „Apache Tomcat: Versionen 9.0.0 bis 9.0.98 betroffen“. Und die Seite zeigt, wann jede Quelle zuletzt gelesen wurde, mit einem Hinweis, wenn ein Abruf fehlgeschlagen ist.
Ausgenutzte Schwachstellen zuerst

Der CVSS-Score gibt den theoretischen Schweregrad einer Schwachstelle an, nicht das tatsächliche Risiko, das von ihr ausgeht. Eine mit 9,8 bewertete Schwachstelle, die niemand ausnutzt, wiegt weniger als eine mit 7,5 bewertete, die aktiv genutzt wird. KANAP kombiniert daher drei Signale zur Ausnutzung:
- Die Kataloge ausgenutzter Schwachstellen der CISA, der US-amerikanischen Behörde, und der Europäischen Union. Eine Schwachstelle, die dort aufgeführt ist, trägt ein Warnsymbol, dessen Tooltip die Kataloge nennt und, wenn die CISA es festgestellt hat, den Einsatz durch Ransomware.
- EPSS, die Wahrscheinlichkeit, dass eine Schwachstelle innerhalb von 30 Tagen ausgenutzt wird, täglich vom FIRST berechnet.
- Die europäische Schwachstellendatenbank der ENISA, auf die sich NIS2 bezieht: Jede Schwachstelle verweist darauf, wenn sie dort geführt wird.
Die Liste öffnet sich mit den ausgenutzten Schwachstellen, dann den schwersten. Der Filter „Nur ausgenutzte“ behält nur diese: Das ist die wichtigste Ansicht.
Die Auswirkungsanalyse
Dieselbe Schwachstelle wiegt auf dem Kundenportal nicht so schwer wie auf einem Testserver. Hier unterscheidet sich KANAP von einer einfachen CVE-Liste: Jede Zeile sagt, wie viele Server und Anwendungen sie erreicht, und mit den Filtern können Sie von einem Server oder einer Anwendung ausgehen, um deren Schwachstellen zu sehen.

Im Datensatz einer Anwendung fasst der Abschnitt Schwachstellen ihre Schwachstellen Technologie für Technologie zusammen, mit der Zahl der kritischen, hohen und mittleren. Ein Abzeichen in der Kopfzeile weist auf schwere Schwachstellen hin. Der Verantwortliche der Anwendung sieht, wie exponiert sie ist, ohne die Seite Schwachstellen zu öffnen.

Im Dashboard stellt die Kachel „Schwachstellen im Bestand“ die Fragen in der Reihenfolge eines CIO: Wie viele Anwendungen der höchsten Kritikalität haben eine kritische oder hohe Schwachstelle, wie viele kritische Schwachstellen wurden in den letzten 7 und 30 Tagen veröffentlicht, wie viele werden ausgenutzt, wie viele Server haben eine schwere Schwachstelle. Jede Zeile öffnet die passende Liste. Die Kritikalität stammt aus der Klassifizierung Ihrer Anwendungen, vorgestellt im Artikel Anwendungen klassifizieren.
Sie bestimmen, was eine Warnung auslöst
Nicht jede Technologie verdient dieselbe Aufmerksamkeit. Bei jeder Technologie nimmt ein Schalter sie in die Warnungen auf oder schließt sie aus, und jede Version kann ihren eigenen haben.
Zwei Familien starten standardmäßig ohne Warnungen; es steht Ihnen frei, sie zu aktivieren. Zunächst die Betriebssysteme: KANAP kennt den Patchstand eines Servers nicht, und ein vollständiges Betriebssystem würde Hunderte bereits behobener Schwachstellen melden. Dann die Online-Dienste: Der Anbieter patcht einen Dienst, den er betreibt, selbst. Wenn Sie eine bestimmte Version verfolgen möchten, etwa die Ihrer am stärksten exponierten Server, genügt es, ihren Schalter zu aktivieren.
Verborgen wird dadurch nichts. Eine Version außerhalb der Warnungen wird weiterhin mit den Schwachstellen abgeglichen und bleibt unter dem Filter „Warnungen“ sichtbar: Sie wird lediglich in den Zählungen, den Kacheln und den E-Mails beiseitegelassen.
Die Bearbeitung der Warnungen nachvollziehbar machen
Eine Schwachstelle ist nie einfach „gesehen“: Sie ist behandelt, mit einer Begründung ausgeschlossen oder noch zu prüfen. Jede Zeile trägt einen dieser drei Status (zu prüfen, behandelt, nicht betroffen) und eine Notiz: „gepatcht am 12. März, Change CHG-123“. Das Audit-Log hält fest, wer welchen Status geändert hat, und wann.
Die Massenbearbeitung erspart die Arbeit Zeile für Zeile. Zum Beispiel, um die Schwachstellen von PostgreSQL auf Installationen auszuschließen, deren Version nicht erfasst ist: ein Filter auf Technologie und Version, ein Kontrollkästchen, der Status „nicht betroffen“ und die Begründung in der Notiz. Vor der Bestätigung sagt KANAP, wie viele Zeilen und Schwachstellen die Änderung betrifft.
Der Rest ergibt sich von selbst. Der CSV-Export übernimmt die angezeigten Filter, für den Sicherheitsausschuss oder den Auditor. Die IT-Verantwortlichen einer Technologie erhalten eine E-Mail zu ihren neuen kritischen, hohen oder ausgenutzten Schwachstellen, nur einmal pro Schwachstelle. Und Plaid, der in KANAP integrierte Assistent, beantwortet Fragen zu Schwachstellen, im Rahmen der Rechte jedes Einzelnen.
Genau das erwartet ein NIS2-Audit: keine Liste von Schwachstellen, sondern den Nachweis dessen, was das Team damit gemacht hat.
KANAP ist kein Scanner, es ergänzt ihn
Ein Schwachstellenscanner sieht die Hosts, die installierten Pakete, die eingespielten Patches. KANAP sieht etwas anderes: die Fachanwendungen, ihre Kritikalität, ihre Verantwortlichen und die Technologien, von denen sie abhängen. Es sagt nicht, ob ein Patch auf einem bestimmten Server eingespielt ist; es sagt, welche Anwendungen eine Schwachstelle treffen kann und wer hinschauen muss.
Wo Sie anfangen
- Legen Sie Ihre Technologien aus dem Katalog an: 192 Produkte, deren Versionen, Supportdaten und Schwachstellenkennungen bereits hinterlegt sind und direkt genutzt werden können.
- Erfassen Sie die Versionen auf Ihren Servern und Anwendungen, oder importieren Sie die Verknüpfungen per CSV-Datei.
- Benennen Sie die IT-Verantwortlichen jeder Technologie: Sie erhalten die Warnungen.
- Öffnen Sie die Seite Schwachstellen mit „Nur ausgenutzte“.
Wenn Sie KANAP selbst betreiben, aktivieren Sie zuerst die Schwachstellen und hinterlegen Sie einen NVD-Schlüssel, wie es die Konfigurationsanleitung erklärt.
Um all das live zu erleben, bietet eine kostenlose 14-tägige Testphase unserer gehosteten Version Zugang zu den Beispieldaten der fiktiven Gruppe Fromage & Co, in einer Minute geladen. KANAP ist vollständig Open Source: Sie können es auch kostenlos auf Ihren eigenen Servern installieren.