Schwachstellen und Updates

Woher die CVE-Daten kommen, wie verglichen wird, wo die Grenzen liegen.

Woher die Daten kommen #

NODE64 nutzt OSV.dev als Quelle – eine offene Schwachstellen-Datenbank, die die Sicherheitsmeldungen der Distributionen zusammenführt: Debian, Ubuntu, Alpine, Rocky, SUSE und andere. Für ein Debian-System werden also die Debian-Security-Advisories ausgewertet, nicht irgendeine allgemeine CVE-Liste.

Das ist wichtig, weil Distributionen Sicherheitslücken zurückportieren: Debian liefert oft eine alte Versionsnummer mit eingespieltem Fix. Ein Werkzeug, das nur Versionsnummern mit einer CVE-Liste vergleicht, meldet hier Fehlalarme am laufenden Band.

Wie verglichen wird #

Der Server nimmt jedes installierte Paket, sucht die Meldungen für dein Betriebssystem und vergleicht die Versionen nach den Regeln des jeweiligen Paketmanagers – bei Debian also mit dpkg-Semantik, inklusive Epoche, Tilde und Backport-Suffixen. Liegt deine Version unterhalb der reparierten, entsteht ein Befund.

Die Einstufung folgt der Schwere aus der Meldung; wo vorhanden, steht der CVSS-Wert dabei.

Auch Python-Pakete (pip) #

Neben den Betriebssystem-Paketen prüft NODE64 auch Python-Pakete, die per pip installiert wurden – gegen dieselbe Quelle (OSV.dev, Ökosystem PyPI). Das schliesst eine typische Lücke: Ein per pip install eingespieltes Django, Flask oder requests taucht im System-Paketmanager gar nicht auf, kann aber genauso eine bekannte Schwachstelle tragen. Verglichen wird nach den Python-Versionsregeln (PEP 440), nicht nach dpkg.

Erfasst werden die pip-Installationsorte (system-weites pip, pip install --user), nicht die Python-Pakete der Distribution – die laufen bereits über das Betriebssystem-Ökosystem und würden sonst doppelt zählen. Der Agent liest dafür nur die Paket-Metadaten im Dateisystem; er führt pip nicht aus. Behoben wird ein solcher Befund über pip, meist im betroffenen Projekt bzw. dessen virtueller Umgebung:

pip install --upgrade requests

Was das Ergebnis nicht ist #

• Kein Beweis für Ausnutzbarkeit. Eine Lücke in einer Bibliothek, die auf deinem System niemand aufruft, ist real, aber vielleicht nicht dringend.
• Nicht vollständig für Fremdsoftware. Was du an den Paketen vorbei installiert hast – ein Tarball unter /opt, ein selbst gebautes Binary –, kennt kein Paketmanager und damit auch NODE64 nicht. Auch andere Sprach-Ökosysteme wie npm (Node.js) sind derzeit nicht abgedeckt – Python-Pakete aus pip dagegen schon (siehe oben).
• Nicht in Echtzeit. Die Daten werden täglich aktualisiert. Zwischen der Veröffentlichung einer Lücke und ihrer Erfassung liegen Stunden.

Dringlichkeit: was zuerst #

Die Schwere eines Befunds sagt, wie schlimm es wäre. Sie sagt nichts darüber, ob es passiert. Auf einem länger nicht aktualisierten System stehen leicht 191 CVE-Befunde, davon dreißig „kritisch" – und damit ist keiner mehr kritisch.

Deshalb steht neben der Schwere eine zweite Größe: die Dringlichkeit. Sie stützt sich auf zwei Quellen.

Ausnutzungslisten (KEV). Verzeichnisse von Schwachstellen, für die eine Ausnutzung in freier Wildbahn belegt ist – nicht vermutet, belegt. NODE64 nutzt zwei:

• die EUVD der ENISA (European Union Agency for Cybersecurity), die europäische Schwachstellendatenbank. Sie ist die Primärquelle: Sie enthält die US-Liste vollständig und ergänzt sie um eigene Einträge.
• den KEV-Katalog der CISA (US-Behörde). Er läuft länger und ist die einzige Quelle, die ausweist, ob eine Lücke bei Erpressungsangriffen eingesetzt wurde.

EPSS (Exploit Prediction Scoring System, FIRST.org). Eine täglich neu berechnete Schätzung, wie wahrscheinlich eine Ausnutzung in den nächsten 30 Tagen ist.

Daraus ergeben sich vier Stufen:

Die Befundliste ist nach Dringlichkeit sortiert. Wer die alte Reihenfolge will, hängt ?sort=severity an die Adresse.

Die Grenzen dieser Einordnung #

Das hier ist der wichtigste Abschnitt dieser Seite, und er steht bewusst nicht im Kleingedruckten.

• EPSS schätzt Ausnutzung irgendwo, nicht Betroffenheit hier. Ein Wert von 60 % heißt nicht, dass dieses System zu 60 % angegriffen wird. FIRST schreibt dazu selbst, EPSS berücksichtige weder, „whether it affects your environment", noch vorhandene Gegenmaßnahmen – es ist eine Aussage über die Welt, nicht über Ihren Server.
• Ein fehlender EPSS-Wert ist keine Entwarnung. EPSS kennt sehr viele, aber nicht alle Kennungen. Wo nichts steht, sagt die Quelle nichts – der Befund bleibt regulär und verschwindet nicht.
• KEV ist US-behördlich geprägt und dadurch unvollständig. Der CISA-Katalog entstand für US-Bundesbehörden; was dort nicht auftaucht, ist deshalb nicht ungefährlich. Die EU-Liste gleicht das teilweise aus, aber auch sie ist eine Auswahl, keine Gesamtschau.
• Beides ersetzt kein Aktualisieren. Die Dringlichkeit ordnet die Reihenfolge. Sie verkleinert die Liste nicht.
• Aufwandsangaben sind Schätzungen. Unter „Was zuerst" steht neben jedem Schritt eine Aufwandsklasse – gering, mittel, hoch. Wie lange es tatsächlich dauert, hängt von Ihrem Betriebsfenster, Ihren Neustartregeln und Ihren Abhängigkeiten ab. Deshalb steht dort eine Klasse und keine Minutenzahl.

Eine Mail bekommen Sie nur in einem Fall #

Aus einem neuen Befund wird nicht automatisch eine Nachricht – sonst wäre der erste Auswertungslauf eines vernachlässigten Systems eine Mailflut. Normalerweise fasst NODE64 alles in eine Sammelnachricht.

Die einzige Ausnahme ist ein Befund der Stufe Sofort: eine Schwachstelle, die auf Ihrem System vorliegt und für die eine Ausnutzung belegt ist. Die geht unmittelbar raus, und die Mail sagt dazu, warum sie unmittelbar kam.

Quellenangaben #

• EUVD – European Vulnerability Database, ENISA: <https://euvd.enisa.europa.eu/>
• CISA Known Exploited Vulnerabilities Catalog (veröffentlicht unter CC0 1.0): <https://www.cisa.gov/known-exploited-vulnerabilities-catalog>
• EPSS – Exploit Prediction Scoring System, FIRST.org: <https://www.first.org/epss/>

Alle drei werden einmal täglich abgerufen, nicht bei jedem Seitenaufruf.

Container #

Für laufende Container erfasst NODE64 Image, Tag und Digest. Ein Befund entsteht, wenn ein Image gegenüber dem veröffentlichten Stand veraltet ist – entweder weil derselbe Tag inzwischen neu gebaut wurde (häufig ein Sicherheits-Patch) oder weil eine neuere Version existiert.

Was du tun kannst #

Der übliche Weg steht am Befund:

apt update
apt install --only-upgrade openssl

Bei vielen betroffenen Paketen lohnt der Blick auf den Upgrade-Plan als Skript in der Geräteansicht – er fasst alles zusammen.

Nach dem Update prüfen, ob ein Neustart nötig ist. Eine aktualisierte Bibliothek wirkt erst, wenn die Prozesse sie neu laden. NODE64 meldet ausstehende Neustarts als eigenen Befund.

Welche Systeme abgeglichen werden #

Jedes dieser Ökosysteme bringt seine eigene Versionsregel mit. Debian vergleicht mit dpkg-Semantik, Rocky und AlmaLinux mit rpmvercmp, FreeBSD mit den Portsregeln (_revision, ,epoche, Vorabstufen wie rc1), PyPI nach PEP 440. Wer das gleichsetzt, meldet entweder längst behobene Lücken oder – schlimmer – meldet vorhandene nicht.

Ein Detail, das nicht auf den ersten Blick einleuchtet: Rocky Linux und AlmaLinux benennen dieselben Pakete unterschiedlich. Rocky führt seine Meldungen über das Quellpaket (openssl), AlmaLinux über die einzelnen Binärpakete (openssl-libs). NODE64 gleicht bei beiden über beide Namen ab.

Wenn kein Abgleich möglich ist #

Für manche Systeme gibt es keinen auswertbaren Katalog. Bis zu dieser Ausbaustufe bekamen sie schlicht null Befunde – und null Befunde sehen aus wie ein sauberes System. Genau das ist die gefährlichste Art von Fehlanzeige, weil sie beruhigt.

Deshalb steht in der Geräteansicht und im Bericht jetzt ausdrücklich, warum nicht verglichen wird:

• Debian-Derivat ohne Basisangabe. Systeme wie Parrot oder Kali melden ihre eigene Versionsnummer, nicht die zugrunde liegende Debian-Ausgabe. Die echte Basis steht in /etc/debian_version; ältere Agenten übertragen sie nicht. Nach einem Agent-Update greift der Abgleich von selbst.
• Kein Feed vorhanden. Arch, OpenWrt, Gentoo und NixOS veröffentlichen ihre Meldungen nicht in einem Format, das sich maschinell auswerten liesse.
• Feed nach Produkt aufgeteilt. Bei SUSE, Red Hat und CentOS hängt die richtige Kennung nicht nur an der Version, sondern auch an den aktivierten Modulen. Eine vereinfachte Zuordnung würde einen Teil der Pakete stillschweigend überspringen – lieber kein Abgleich als ein halber, der wie ein vollständiger aussieht.

Die Härtungsprüfungen laufen in allen diesen Fällen weiter. Nur der Paketabgleich fällt aus.