Vuls: agentenloser Schwachstellenscanner für Linux, FreeBSD, Container und mehr

Das Administratorproblem, von dem Vuls ausgeht

Im Repository future-architect/vuls steht der Abschnitt Das Administratorproblem, von dem Vuls ausgeht für eine konkrete, im README beschriebene Funktion oder Einordnung. Die README beginnt mit einer konkreten Beschwerde: Für Systemadministratoren sind die tägliche Sicherheitsanalyse und Software-Updates eine Last. Da automatische Updates in Produktionsumgebungen Ausfallzeiten verursachen können, aktualisieren Administratoren oft manuell, was bedeutet, dass sie ständig die NVD oder ähnliche Datenbanken beobachten, jedes installierte Paket verfolgen und bei neuen Schwachstellen Analysearbeit leisten müssen. Vuls wird als Werkzeug positioniert, das diese drei Probleme angeht: Es informiert über Schwachstellen, die das System betreffen, über betroffene Server, automatisiert die Erkennung, um Übersehen zu vermeiden, und kann regelmäßig Berichte per CRON oder ähnlich erzeugen. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei vuls ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Das Administratorproblem, von dem Vuls ausgeht Nummer 1 sind README-Datei, Standardbranch master und veröffentlichte Tags von vuls maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob vuls den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Was Vuls scannt und welche Quellen es nutzt

Im Repository future-architect/vuls steht der Abschnitt Was Vuls scannt und welche Quellen es nutzt für eine konkrete, im README beschriebene Funktion oder Einordnung. Vuls unterstützt Linux- und FreeBSD-Distributionen wie Alpine, Amazon Linux, CentOS, AlmaLinux, Rocky Linux, Debian, Oracle Linux, Raspbian, RHEL, openSUSE, openSUSE Leap, SUSE Enterprise Linux, Fedora und Ubuntu, dazu FreeBSD, Windows und macOS, in der Cloud, on-premise und in Docker-Containern. Der Scanner verwendet NVD- und JVN-Datenbanken, OVAL-Feeds von Red Hat, Debian, Ubuntu, SUSE und Oracle Linux, Sicherheitsadvisorys von Alpine, Red Hat, Debian, Ubuntu und Microsoft CVRF, Distributionsbefehle wie yum, zypper und pkg-audit, PoC- und Exploit-Datenbanken, CERT-Meldungen, CISA- und VulnCheck-KEV-Kataloge, MITRE ATT&CK und CAPEC, aquasecurity/vuln-list und wpscan für WordPress. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei vuls ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Was Vuls scannt und welche Quellen es nutzt Nummer 2 sind README-Datei, Standardbranch master und veröffentlichte Tags von vuls maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob vuls den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Scan-Modi

Im Repository future-architect/vuls steht der Abschnitt Scan-Modi für eine konkrete, im README beschriebene Funktion oder Einordnung. Die README beschreibt mehrere Scan-Modi. Fast Scan läuft ohne Root-Rechte, benötigt keine Abhängigkeiten, belastet den Zielserver kaum und unterstützt Offline-Scans auf CentOS, AlmaLinux, Rocky Linux, Debian, Oracle Linux, Red Hat, Fedora und Ubuntu. Fast Root Scan läuft mit Root-Rechten, erkennt mit yum-ps von Updates betroffene Prozesse auf Amazon Linux, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, Fedora und RedHat und nutzt checkrestart von debian-goodies auf Debian und Ubuntu; Offline-Modus wird ebenfalls unterstützt. Remote Scan benötigt eine Maschine, die per SSH mit den Zielservern verbunden ist, Local Scan läuft ohne zentrale SSH-Verbindung, und Server-Modus startet Vuls als HTTP-Server, sammelt Softwareinformationen über Befehle auf dem Ziel und liefert JSON-Ergebnisse ohne SSH und ohne Scanner. Eine dynamische Analyse kann den Serverzustand per SSH erfassen und warnt, wenn der Kernel aktualisiert, aber nicht neu gestartet wurde. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei vuls ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Scan-Modi Nummer 3 sind README-Datei, Standardbranch master und veröffentlichte Tags von vuls maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob vuls den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Nicht-OS-Pakete und WordPress

Im Repository future-architect/vuls steht der Abschnitt Nicht-OS-Pakete und WordPress für eine konkrete, im README beschriebene Funktion oder Einordnung. Vuls bietet Optionen zur Erkennung von Schwachstellen in Software außerhalb des OS-Paketmanagers: Programmbibliotheken, selbst kompilierte Software und Netzwerkgeräte. Die README nennt Lockfile-basiertes Scannen, GitHub-Integration für Sicherheitsalarme, CPE-basiertes Scannen und OWASP-Dependency-Check-Integration, wobei letztere als experimentell markiert ist. WordPress-Kern, Themes und Plugins können ebenfalls gescannt werden; als Quelle wird die wpscan-API genannt. Konkrete Befehle oder Konfigurationen für diese Scans stehen nicht in der README, sie verweist auf die vuls.io-Dokumentation. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei vuls ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Nicht-OS-Pakete und WordPress Nummer 4 sind README-Datei, Standardbranch master und veröffentlichte Tags von vuls maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob vuls den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Betriebshinweise

Im Repository future-architect/vuls steht der Abschnitt Betriebshinweise für eine konkrete, im README beschriebene Funktion oder Einordnung. Die README nennt mehrere Betriebseigenschaften: Tests sind nicht destruktiv, und vor dem Scannen auf AWS ist keine Vorabgenehmigung nötig; die README sagt, dass Vuls gut mit Continuous Integration zusammenarbeitet, da Tests täglich laufen können. Konfigurationsdatei-Vorlagen können automatisch erzeugt werden, wobei Server-Sets per CIDR erkannt werden. E-Mail- und Slack-Benachrichtigungen sind möglich und unterstützen Japanisch. Scan-Ergebnisse können in einem TUI-Viewer im Terminal oder in der VulsRepo-Web-UI angezeigt werden. Vuls aktualisiert verwundbare Pakete nicht; die README stellt das ausdrücklich klar. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei vuls ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Betriebshinweise Nummer 5 sind README-Datei, Standardbranch master und veröffentlichte Tags von vuls maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob vuls den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Repository-Stand und Dokumentation

Im Repository future-architect/vuls steht der Abschnitt Repository-Stand und Dokumentation für eine konkrete, im README beschriebene Funktion oder Einordnung. Das Repository ist in Go geschrieben, mit 12.227 Sternen und 1.242 Forks in den Metadaten, 87 offenen Issues, und es ist nicht archiviert. Der Standardzweig ist master. Die Dokumentation liegt unter vuls.io, eine japanische Version unter vuls.io/ja. Die README nennt kotakanbe als Ersteller und listet Mitwirkende auf. Sponsoren sind Tines, beschrieben als No-Code-Automatisierung für Sicherheitsteams, und SAKURA internet, ein japanischer Cloud-Anbieter. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei vuls ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Repository-Stand und Dokumentation Nummer 6 sind README-Datei, Standardbranch master und veröffentlichte Tags von vuls maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob vuls den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Redaktionelles Fazit

Geeignet ist vuls für Leser, deren konkreter Anwendungsfall mit dem README übereinstimmt. Nicht geeignet ist eine Entscheidung allein nach Sternezahl oder Beschreibung. Vor dem Einsatz sollten vuls, die dokumentierte Version, Eingabe und Ausgabe in der eigenen Umgebung geprüft werden; offene Angaben zu Sicherheit, Kompatibilität und Betrieb bleiben offene Fragen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes