Läuft auf Ihrem Server Software mit bekannten Schwachstellen?

Ein Website-Scan sieht, was der Server nach außen zeigt: Header, offen zugängliche Dateien, TLS. Er kann nicht erkennen, dass ein Composer-Paket drei Ebenen tief, eine npm-Abhängigkeit des Builds oder die Python-Bibliothek eines Hintergrund-Workers eine veröffentlichte CVE hat – und genau danach suchen Angreifer, sobald ein Exploit öffentlich ist.

Der einzig verlässliche Weg ist, aufzulisten, was tatsächlich installiert ist, und es mit den Schwachstellendatenbanken abzugleichen. Genau das macht dieser Check – gegen OSV und die CISA-Liste aktiv ausgenutzter Schwachstellen (KEV).

Der Server wird als Stack gelesen, von unten nach oben:

1. Betriebssystem: die Distribution und der Kernel.
2. Systembibliotheken und installierte Software: openssl, nginx, docker, redis…
3. Sprachen und Frameworks: PHP mit Laravel, JavaScript mit Vue, Python…
4. Sprachbibliotheken: die Composer-, npm- und PyPI-Pakete jeder Anwendung, direkt und transitiv.

Mit --docker wird auch jeder laufende Container gelesen, direkt vor Ort, ohne sein Image zu exportieren.

wpsbom ist ein einzelnes Open-Source-Binary für Linux und macOS. Es liest nur Dateien und sendet nichts, sofern Sie es nicht ausdrücklich anweisen.

curl -fsSL https://raw.githubusercontent.com/ice-s/wpsbom/main/install.sh | sh

Es kann nicht erraten, wo Ihr Code liegt, daher geben Sie jedes Anwendungsverzeichnis mit --path an, so viele Sie brauchen:

sudo wpsbom scan / --path /srv/shop --path /srv/worker --docker \
  --out-dir scans/ -o cyclonedx-json

Wenige Sekunden später enthält scans/ eine Datei für den Server und eine pro Container-Image. Melden Sie sich dann an, öffnen Sie Mein Server im Kontomenü, benennen Sie das Projekt, wählen Sie Server und ziehen Sie die Datei hinein:

• Nur Anwendungsbibliotheken, ohne Betriebssystempakete: --no-os.
• Ein einzelnes Image: wpsbom scan --image acme/shop:1.4 -o cyclonedx-json=shop.cdx.json.
• Dateien von syft, Trivy oder cdxgen funktionieren ebenfalls (CycloneDX oder SPDX JSON).

Der Software-Stack fasst den Server zusammen: Jeder Block zeigt seine Pakete und offenen Schwachstellen nach Schweregrad, und sein linker Rand nimmt die Farbe der schwersten an. Klicken Sie auf einen Block, um nur diesen Teil zu sehen.

Die Schwachstellenliste ist genauso gegliedert. Fundort zeigt, zu welcher Anwendung ein Paket gehört und ob es eine direkte oder transitive Abhängigkeit ist; Behoben in nennt die Version und den Befehl zum Kopieren.

1. Ausgenutzt (KEV) und Kritisch: Diese werden gegen reale Server eingesetzt; aktualisieren Sie noch heute.
2. Direkte Abhängigkeiten Ihrer Anwendungen: Ihr Upgrade zieht meist auch korrigierte Versionen der transitiven nach.
3. dev-Pakete (Build-Tools) sind auf einem Produktionsserver weniger relevant, außer der Build läuft dort.

Scannen und laden Sie nach dem Upgrade erneut hoch: Die Liste zeigt, was noch übrig ist. Um sie ohne Handarbeit aktuell zu halten, erstellen Sie unter Integrationen ein API-Token und lassen wpsbom den Scan senden, zum Beispiel per täglichem Cronjob:

export WPSBOM_TOKEN=wp_…
sudo -E wpsbom push / --project demo-web-01 \
  --path /srv/shop --path /srv/worker --docker

Verbindet sich Watchpost mit meinem Server? Nein. Sie führen den Scan aus; gelesen wird nur die Datei, die Sie hochladen.

Was wird übertragen? Paketnamen, Versionen und die Pfade der Lock-Dateien. Kein Quellcode, keine Konfiguration, keine Secrets. Der Hostname wird durch einen Hash ersetzt, die hochgeladene Datei selbst wird nicht gespeichert, und Projekte sind nur für Ihr Konto sichtbar.

Welche Systeme? wpsbom liest Debian-, Ubuntu- und Alpine-Pakete sowie Composer-, npm-/yarn-, PyPI-, Go- und RubyGems-Bibliotheken; Maven- und NuGet-Bibliotheken werden ebenfalls abgeglichen, wenn die Datei aus einem anderen Tool stammt. Betriebssystempakete werden aufgelistet, aber noch nicht mit Schwachstellen abgeglichen.

Kubernetes? wpsbom k8s läuft im Cluster und verknüpft jeden Workload mit dem Scan seines Images.