Schwachstellen finden, ohne die Server anzufassen

„Keine Sicherheitslücken gefunden” ist ein beruhigender Satz – und einer der gefährlichsten, die ein Werkzeug ausgeben kann. Er stimmt nämlich auch dann, wenn gar nicht richtig gesucht wurde. Wie LCM den Paketbestand seiner Server auf bekannte Schwachstellen prüft, hängt deshalb an drei Fragen: Wo läuft der Scan, was ist ein Fund wert, und wie frisch sind die Daten?

Der Scan findet gar nicht auf den Servern statt

LCM verwaltet Server agentenlos über SSH und führt dabei ohnehin Buch über jedes installierte Paket. Für die CVE-Bewertung wird aus diesen Datensätzen pro Server ein SBOM erzeugt – eine Stückliste der Software – und lokal auf dem LCM-Host gegen die Trivy-Schwachstellendatenbank geprüft.

Die verwalteten Server werden dafür nicht erneut kontaktiert. Es muss nichts installiert, nichts geöffnet und nichts zusätzlich ausgeführt werden; der Scan belastet weder die Maschinen noch das Wartungsfenster. Standardmäßig läuft er täglich um vier Uhr morgens, die Zeit ist einstellbar.

Wichtiger als der Zeitplan ist aber der zweite Auslöser: Sobald LCM Pakete aktualisiert – egal ob von Hand oder per Regel –, wird der Bestand neu eingelesen und die Bewertung des Servers sofort neu erstellt. Sonst hinge das rote Etikett noch tagelang an einer Lücke, die längst geschlossen ist.

Der Scanner läuft eingesperrt

Ein Schwachstellen-Scanner ist Fremdcode, der regelmäßig aktualisiert wird – und er liefe als Kindprozess von LCM mit denselben Rechten. Er käme damit an das Verzeichnis, in dem Datenbank und Master-Key liegen, und daraus ließen sich die SSH-Schlüssel und Passwörter aller verwalteten Server entschlüsseln. Angriffe über die Lieferkette von Entwickler- und Admin-Werkzeugen sind keine graue Theorie; ein Scanner ist dafür ein denkbar attraktives Ziel.

LCM startet ihn deshalb in einer Sandbox. Sichtbar ist nur, was der Scan wirklich braucht: das Binary, die Systembibliotheken, das erzeugte SBOM, der Datenbank-Cache und ein eigenes, leeres /tmp. Alles Übrige ist für den Prozess nicht etwa gesperrt, sondern schlicht nicht vorhanden – ein Leseversuch endet mit „Datei nicht gefunden”.

Dazu kommt die Netztrennung: Der SBOM-Scan wertet nur die lokale Datenbank aus und läuft ganz ohne Netz. Selbst ein manipulierter Scanner hätte dabei keinen Weg nach draußen.

Umgesetzt ist das mit bubblewrap, ersatzweise mit Landlock. Fehlt beides, läuft der Scan ungesperrt – dann aber mit einem sichtbaren Hinweis an der Scanner-Anzeige. Ein stiller Rückfall wäre die schlechteste Variante: Man hielte sich für geschützt, ohne es zu sein.

Nicht jeder Fund wiegt gleich schwer

Die Security-Seite zeigt die Roh-Bewertung, wie der Scanner sie liefert. Für Ampel und Alarme gewichtet LCM sie aber nach Kontext – sonst versinkt das Dringende im Grundrauschen:

• CVEs in Container-Images zählen standardmäßig nicht. Die Isolation begrenzt den Schaden, und für den Inhalt eines Images ist dessen Anbieter zuständig. Wer einzelne Container anders bewertet wissen will, markiert sie als CVE-relevant – dann fließen sie mit voller Schwere ein.
• CVEs exponierter Pakete zählen eine Stufe höher. Webserver, Reverse-Proxies, Mail-, DNS- und Datenbankdienste. Die Liste ist pflegbar, und zusätzlich erkennt LCM selbst, welche Pakete auf von außen erreichbaren Ports lauschen.

Unabhängig von einzelnen Funden wird ein Server rot, wenn seine Distribution keine Sicherheitsupdates mehr bekommt oder in weniger als einem Monat aus dem Support fällt. Und über dem grünen „OK” gibt es eine weitere Stufe: „Sehr gut” – keine einzige bekannte CVE, SSH gehärtet, Firewall aktiv.

Wie alt ist die Datenbank?

Trivy lädt seine Schwachstellendatenbank selbst nach. Klappt das nicht – kein Netz, ein Proxy, ein Rate-Limit –, dann bricht der Scan nicht ab, sondern läuft mit der alten Datenbank weiter. Das Ergebnis heißt dann nicht „Fehler”, sondern „keine Sicherheitslücken gefunden”.

Eine drei Wochen alte Datenbank sieht in der Übersicht also genauso aus wie ein tatsächlich sauberer Server. Deshalb macht LCM den Stand sichtbar:

Alter der Datenbank	Bewertung	Wirkung
unter 48 Stunden	aktuell	keine Anzeige
ab 48 Stunden	veraltet	Warnung auf der Sicherheitsseite, Hinweis je Server, Alarm
ab 7 Tagen	kritisch	dasselbe, deutlicher hervorgehoben

Maßgeblich ist dabei, wann der Hersteller die Datenbank gebaut hat – nicht, wann dieser Host sie geholt hat. Wer dieselbe alte Datenbank täglich neu herunterlädt, hat trotzdem alte Daten.

Die Ampel der einzelnen Server bleibt davon übrigens unberührt. Eine veraltete Datenbank ist ein Problem des LCM-Hosts; alle Server deswegen einzufärben würde eine einzige Ursache vielfach als Server-Problem ausgeben.

Ein Sonderfall zum Schluss: der laufende Kernel

Nach einem Kernel-Update ist der neue Kernel installiert, läuft aber erst nach einem Neustart. Die Paketliste meldet dann „alles aktuell”, während die Maschine weiter mit dem alten Kernel arbeitet – samt der Lücken, die der neue schließt.

LCM trennt beides: Der laufende Kernel kommt aus uname -r, der einzigen Quelle, die dabei nicht irren kann. Die installierten Kernel stehen daneben als eigene Liste, jeweils markiert als läuft, wartet auf Neustart oder Rückfallebene – letztere sind das, was einen rettet, wenn ein neuer Kernel nicht bootet.

Zum Nachlesen

Die vollständige Beschreibung steht in der Dokumentation unter Sicherheit & CVE-Scans, die Herleitung der Ampel unter Status-Berechnung. Einen Überblick über LCM gibt es auf der Produktseite, zum Ausprobieren steht das Demo-System unter lcm-demo.techeve.de bereit.