CVE-Monitoring für Legacy-Software: Wie Schwachstellen-Tracking in der Praxis funktioniert
CVE-Monitoring klingt nach einem Thema für große IT-Abteilungen. Das ist es aber nicht. Gerade alte Software braucht es dringend. Denn Legacy-Systeme bekommen selten automatische Warnungen. Neue Sicherheitslücken tauchen trotzdem jeden Tag auf. Die Frage ist nur: Erfahren Sie davon? Oder erfährt es zuerst ein Angreifer?
Dieser Artikel zeigt, wie CVE-Monitoring in der Praxis funktioniert. Welche Datenbanken zählen. Welche Werkzeuge helfen. Und was Sie bei einem Fund konkret tun. Ohne Fachchinesisch, dafür mit einem klaren nächsten Schritt.
Was bedeutet CVE-Monitoring?
CVE steht für "Common Vulnerabilities and Exposures". Das ist eine öffentliche Liste bekannter Sicherheitslücken. Jede Lücke bekommt eine eindeutige Nummer. Zum Beispiel CVE-2026-45070 oder CVE-2026-45075. Dazu gehören eine Beschreibung, die betroffenen Versionen und ein Schweregrad.
CVE-Monitoring bedeutet: Sie beobachten diese Liste systematisch. Sie prüfen, ob Ihre Software betroffen ist. Und Sie handeln, bevor jemand die Lücke ausnutzt.
Bei Legacy Software ist das besonders wichtig. Legacy Software ist ältere Software, die noch produktiv läuft. Sie verdient Geld und trägt den täglichen Betrieb. Aber sie bekommt oft keine automatischen Updates mehr. Genau hier setzt das Monitoring an.
Warum Legacy-Software ein Sonderfall ist
Moderne Projekte melden Sicherheitslücken oft selbst. Der Hersteller schickt ein Update, das System installiert es. Bei alten Systemen fehlt dieser Mechanismus meistens.
Dafür gibt es mehrere Gründe. Die Software läuft auf einer alten Programmiersprache. Ihre Bausteine, die sogenannten Abhängigkeiten, sind veraltet. Abhängigkeiten sind fremde Programmbibliotheken, die in Ihrer Software stecken. Viele davon haben ihr End of Life längst erreicht. End of Life bedeutet: Der Hersteller pflegt das Produkt nicht mehr.
Dazu kommt: Oft schaut niemand mehr aktiv auf das System. Der ursprüngliche Entwickler hat das Unternehmen verlassen. Die Dokumentation fehlt. So sammeln sich offene Lücken still an. Das ist wie ein Konto, dessen Zinsen niemand mehr im Blick hat. Irgendwann wird die überfällige Rechnung teuer.
Welche Datenbanken und Quellen zählen
Gutes CVE-Monitoring stützt sich auf verlässliche Quellen. Drei sind für den Praxiseinsatz besonders relevant.
Die NVD als zentrale Quelle
Die National Vulnerability Database (NVD) ist die größte offene CVE-Datenbank. Sie wird von einer US-Behörde gepflegt. Jede CVE-Nummer bekommt dort einen Schweregrad und technische Details. Die NVD ist die Referenz für fast alle Werkzeuge.
Herstellerspezifische Meldungen
Zusätzlich lohnt der Blick auf die Quellen Ihrer eingesetzten Technik. Das PHP-Projekt, die Java-Community oder ein CMS wie Typo3 melden Lücken oft zuerst selbst. Diese Meldungen erscheinen manchmal früher als der NVD-Eintrag.
Die CISA-Liste aktiv ausgenutzter Lücken
Die US-Behörde CISA führt eine Liste mit dem Namen "Known Exploited Vulnerabilities". Dort stehen Lücken, die nachweislich bereits angegriffen werden. Diese Liste ist Gold wert. Sie zeigt, welche CVEs wirklich brennen und keine Zeit lassen.
Werkzeuge für den Praxiseinsatz
Sie müssen die Datenbanken nicht von Hand durchsuchen. Werkzeuge gleichen Ihre Software automatisch mit den CVE-Listen ab. Bei Legacy-Software gibt es dabei eine Besonderheit.
Viele alte Projekte wurden ohne Paketverwaltung gebaut. Bibliotheken wurden früher einfach manuell in den Code kopiert. Dann findet ein Standard-Scanner die Abhängigkeiten nicht automatisch. Der erste Schritt ist deshalb oft eine Bestandsaufnahme: Welche Bausteine stecken überhaupt im System?
Wo eine Paketverwaltung vorhanden ist, helfen einfache Befehle. Für PHP prüft composer audit alle Abhängigkeiten. Im Node-Umfeld leistet npm audit dasselbe. Für gemischte Systeme eignet sich OWASP Dependency-Check. Dienste wie Dependabot oder Snyk beobachten das Projekt dauerhaft und melden neue Treffer.
Welches Werkzeug zu welchem Stack passt, erklären wir ausführlich im Artikel Wie CVE-Monitoring funktioniert.
Alerts sinnvoll filtern
Ein häufiger Fehler: zu viele Warnungen. Wer jede Meldung gleich behandelt, verliert schnell den Überblick. Dann wird die wichtige Lücke zwischen hundert unwichtigen übersehen.
Deshalb priorisieren Sie. Der Schweregrad einer CVE wird als CVSS-Wert angegeben. CVSS reicht von 0 bis 10. Ein Wert ab 9,0 gilt als kritisch. Aber der Wert allein reicht nicht.
Drei Fragen helfen bei der Einordnung. Ist die betroffene Komponente überhaupt aus dem Internet erreichbar? Wird die Lücke bereits aktiv ausgenutzt? Und wie wichtig ist die betroffene Funktion für Ihren Betrieb? Eine kritische Lücke in einem abgeschotteten Modul kann warten. Eine mittlere Lücke im öffentlichen Login-Bereich nicht.
Was tun bei einem Fund?
Ein Treffer im Monitoring ist kein Grund zur Panik. Er ist ein Grund zum strukturierten Handeln. Drei Schritte reichen als Grundgerüst.
Zuerst ordnen Sie die Lücke ein. Betrifft sie Ihr System wirklich? Läuft die genannte Version tatsächlich bei Ihnen? Nicht jeder Treffer ist auch ein reales Risiko.
Dann schließen Sie die Lücke. Im besten Fall gibt es einen Security Patch, also ein gezieltes Sicherheitsupdate. Wenn kein Patch existiert, hilft eine Zwischenlösung. Sie können die betroffene Funktion absichern oder vorübergehend abschalten.
Zuletzt dokumentieren Sie den Vorgang. Was war betroffen? Was haben Sie getan? Diese Notiz spart bei der nächsten Prüfung viel Zeit. Sie ist auch bei einer Frage nach der DSGVO ein wichtiger Nachweis.
Mehr zum Umgang mit Updates lesen Sie in unserem Artikel Warum Updates wichtig sind. Wer die laufende Beobachtung abgeben will, findet Details unter Software-Wartung.
Wie oft sollten Sie prüfen?
Ein einmaliger Scan bringt wenig. Neue Lücken entstehen ständig. Das Monitoring lebt von der Wiederholung.
Für aktiv beobachtete Dienste läuft die Prüfung idealerweise automatisch. Einmal pro Tag ist ein guter Wert. Viele Werkzeuge lassen sich so einstellen. Sie melden nur, wenn wirklich etwas Neues auftaucht.
Bei Legacy-Software ohne Automatik hilft ein fester Rhythmus. Eine manuelle Prüfung pro Monat ist das absolute Minimum. Bei kritischen Systemen prüfen Sie besser wöchentlich. Zusätzlich lohnt ein Blick, sobald eine große Lücke durch die Medien geht.
Wichtig ist die Verlässlichkeit. Ein Monitoring, das nach zwei Wochen einschläft, schützt niemanden. Deshalb gehört die Zuständigkeit klar geregelt. Eine Person prüft, dokumentiert und meldet. So bleibt kein Fund liegen.
Häufige Fehler beim CVE-Monitoring
Zwei Fehler sehen wir immer wieder. Der erste: Warnungen werden gesammelt, aber nie abgearbeitet. Dann wächst eine lange Liste offener Punkte. Genau die wollte das Monitoring verhindern.
Der zweite Fehler: Nur die eigene Anwendung wird geprüft. Der Server darunter bleibt außen vor. Auch das Betriebssystem und die Datenbank haben CVEs. Ein gutes Monitoring denkt den ganzen Stack mit.
Fazit: Monitoring ist günstiger als der Schaden
CVE-Monitoring ist kein Luxus. Es ist die Grundlage, um alte Systeme sicher zu betreiben. Ohne Beobachtung fahren Sie im Nebel. Mit Beobachtung sehen Sie das Risiko, bevor es zum Vorfall wird.
Der Aufwand ist überschaubar. Der Schaden eines Angriffs ist es nicht. Gerade bei Legacy-Software zahlt sich systematisches Monitoring schnell aus.
Sie wissen nicht, welche Lücken sich in Ihrem System angesammelt haben? Sprechen Sie uns an. Wir schauen hin und sagen Ihnen ehrlich, wo Sie stehen. Das Erstgespräch ist kostenlos.
