CVE-Monitoring: Sicherheitslücken im Blick behalten

Jede Woche werden hunderte neue Sicherheitslücken in Software dokumentiert. Manche betreffen Nischenprodukte, manche grundlegende Bibliotheken, die in tausenden Projekten stecken. Die Frage ist nicht, ob Ihre Software irgendwann von einer betroffen ist. Sondern: Wann merken Sie es?

CVE-Monitoring ist der systematische Prozess, der diese Frage beantwortet. Dieser Artikel erklärt, wie er in der Praxis aussieht.

Was ist eine CVE?

CVE steht für "Common Vulnerabilities and Exposures". Mehr dazu im Glossar: CVE-Sicherheitslücke.

Jede dokumentierte Sicherheitslücke bekommt eine eindeutige Nummer, etwa CVE-2024-1874. Dazu eine Beschreibung, betroffene Versionen, ein Schweregrad und idealerweise auch eine Empfehlung zur Behebung.

Die Datenbank ist öffentlich und wird von der Mitre Corporation verwaltet. Sie ist die zentrale Wahrheitsquelle für bekannte Software-Schwachstellen. Wer Software betreibt, sollte diese Quelle kennen, ob direkt oder über automatische Werkzeuge.

Warum manuelles Beobachten nicht reicht

Theoretisch könnten Sie täglich die CVE-Datenbank lesen und prüfen, ob Ihre Software betroffen ist. In der Praxis funktioniert das nicht.

Ein modernes Webprojekt hat schnell 200 bis 500 direkte und indirekte Abhängigkeiten. Bibliotheken, die andere Bibliotheken nutzen, die wiederum andere Bibliotheken nutzen. Wer das manuell verfolgen will, ist Vollzeit beschäftigt.

Deshalb gibt es Werkzeuge, die das automatisch tun. Sie scannen Ihr Projekt, gleichen die genutzten Versionen mit der CVE-Datenbank ab und melden Treffer.

Werkzeuge im Überblick

Welches Werkzeug passt, hängt vom Technologie-Stack ab.

Composer Audit (PHP)

Für PHP-Projekte mit Composer steht der Befehl composer audit zur Verfügung. Er prüft alle Abhängigkeiten gegen die offizielle Datenbank von FriendsOfPHP und meldet bekannte Lücken.

Vorteil: Eingebaut, kostenlos, schnell. Wer Composer nutzt, hat das Werkzeug bereits.

npm audit (JavaScript/Node)

Im Node-Ökosystem leistet npm audit dasselbe. Auch hier eingebaut und ohne zusätzliche Installation nutzbar. Das Werkzeug schlägt teilweise direkt Befehle zum Aktualisieren vor.

In großen Projekten erzeugt npm audit oft viele Treffer. Nicht alle sind kritisch, aber alle gehören eingeordnet.

OWASP Dependency-Check (sprachübergreifend)

Für komplexere Projekte mit mehreren Sprachen oder für Build-Pipelines gibt es OWASP Dependency-Check. Das Werkzeug unterstützt Java, .NET, Node, Python und andere Stacks.

Es erzeugt detaillierte Berichte und lässt sich gut in Continuous-Integration-Systeme einbinden. Die Einrichtung ist aufwändiger, der Nutzen bei großen Projekten aber hoch.

Dependabot und ähnliche Dienste

GitHub Dependabot, GitLab Dependency Scanning, Snyk und Renovate gehen einen Schritt weiter. Sie scannen nicht nur, sondern öffnen automatisch Pull-Requests mit den nötigen Aktualisierungen.

Das nimmt viel Routine ab. Allerdings entsteht so auch eine Flut von Updates, die jemand sichten und entscheiden muss.

CVSS: Wie schlimm ist die Lücke?

Nicht jede CVE ist gleich wichtig. Zur Einordnung gibt es CVSS (Common Vulnerability Scoring System), eine Bewertungsskala von 0,0 bis 10,0.

Die grobe Einteilung lautet:

• 0,1 bis 3,9: Niedrig. Theoretische Risiken, oft schwer auszunutzen.
• 4,0 bis 6,9: Mittel. Sollte zeitnah, aber nicht panisch behoben werden.
• 7,0 bis 8,9: Hoch. Klare Handlungspflicht innerhalb von Tagen.
• 9,0 bis 10,0: Kritisch. Sofort handeln. Nicht warten.

Wichtig: Der CVSS-Wert allein reicht nicht. Eine kritische Lücke in einer Bibliothek, die Sie nur für interne Tests nutzen, ist weniger akut als eine mittlere Lücke in einer öffentlich erreichbaren Komponente.

Wie Sie sinnvoll priorisieren

Eine sinnvolle Priorisierung kombiniert drei Faktoren.

Schweregrad der Lücke. Der CVSS-Wert als Ausgangspunkt.

Erreichbarkeit der betroffenen Komponente. Läuft sie öffentlich oder intern? Verarbeitet sie Nutzereingaben?

Verfügbarkeit eines Exploits. Gibt es schon fertigen Angriffscode? Wenn ja, ist Eile geboten.

In der Praxis arbeiten wir mit einer einfachen Reihenfolge: Kritische Lücken in öffentlich erreichbaren Systemen sofort. Hohe Lücken binnen einer Woche. Mittlere binnen eines Monats, im Rahmen der normalen Wartung. Niedrige im nächsten regulären Update-Zyklus.

Wie ein Patch-Prozess in der Praxis aussieht

CVE-Monitoring ohne Prozess bringt wenig. Ein realistischer Ablauf hat fünf Schritte.

1. Automatischer Scan

Mindestens täglich, idealerweise bei jedem Build. Das Werkzeug meldet neue Treffer und vergleicht mit dem letzten Stand.

2. Sichtung

Jemand schaut sich die neuen Meldungen an. Sind sie relevant? Welche Komponente betrifft es? Welcher Schweregrad?

Dieser Schritt lässt sich nicht voll automatisieren. Auch das beste Werkzeug erkennt nicht, ob Ihr Projekt eine Funktion wirklich nutzt, oder ob die betroffene Codestelle gar nicht erreichbar ist.

3. Entscheidung

Sofort patchen? In den nächsten Sprint einplanen? Auf eine sicherere Alternative ausweichen? Diese Entscheidung trifft jemand mit Überblick über das Gesamtsystem.

4. Update und Test

Das Update wird in einer Testumgebung eingespielt. Automatisierte Tests prüfen, ob nichts Bestehendes kaputtgeht. Bei kritischen Lücken kann auch ein manueller Smoke-Test sinnvoll sein.

5. Ausrollen und Dokumentieren

Das geprüfte Update geht in Produktion. Im Anschluss wird festgehalten: Wann wurde gepatcht? Welche CVE wurde geschlossen? Wer hat es freigegeben?

Diese Dokumentation ist auch für Aufsichtsbehörden und Auditoren wichtig. Sie zeigt, dass Sie Sicherheit ernst nehmen.

Häufige Missverständnisse

"Wir haben doch ein Werkzeug, das reicht." Ein Werkzeug ohne klaren Prozess produziert nur Berichte, die niemand liest. Die Verantwortung muss klar zugeordnet sein.

"Jedes Update sofort einspielen." Auch Updates können Fehler enthalten. Ohne Tests führt blindes Patchen zu neuen Problemen. Die Faustregel: schnell, aber nicht hastig.

"Wir patchen, wenn was passiert." Dann ist es meist zu spät. Bekannte Lücken werden binnen Tagen massenhaft ausgenutzt.

"Unsere Software ist intern, das betrifft uns nicht." Auch interne Systeme sind über Mitarbeiter-Rechner und seitliche Angriffe erreichbar. Die meisten erfolgreichen Angriffe nutzen genau diesen Weg.

CVE-Monitoring als Teil der Wartung

CVE-Monitoring ist kein einmaliges Projekt, sondern ein Dauerlauf. Es gehört zur normalen Software-Wartung, genauso wie regelmäßige Backups oder die Beobachtung der Server-Auslastung.

Wer das in Eigenregie aufsetzt, braucht Werkzeuge, Prozesse und jemanden, der sich kümmert. Wer das auslagert, kauft sich die Routine und die Verantwortung mit ein. Unsere Leistung Sicherheit & Härtung deckt genau diesen Bereich ab.

Fazit

Bekannte Sicherheitslücken sind das größte einzelne Risiko für Web-Anwendungen. Sie sind dokumentiert, auffindbar und in den meisten Fällen mit einem einfachen Update zu schließen. Was fehlt, ist meist nicht das Wissen, sondern der Prozess.

CVE-Monitoring schafft diesen Prozess. Mit den richtigen Werkzeugen, einer klaren Priorisierung und einer Person, die zuständig ist. Das ist kein Hexenwerk. Aber es muss jemand machen.

Wenn Sie unsicher sind, ob Ihre Software systematisch beobachtet wird, sprechen Sie uns an. Das Erstgespräch ist kostenlos. Jetzt Kontakt aufnehmen.