12.3k stars · GPL-3.0 · v0.42.0 (2026-10-15) · Track this in Scout
Scans Linux machines over SSH for installed software with publicly reported security holes.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You list the machines to scan in a configuration file with their SSH details. Vuls connects, reads the package list from the system's own package manager, and compares each version against vulnerability records it has downloaded in advance. Those records come from the public vulnerability database and from each Linux distribution's own security advisories, which is what lets it tell a real problem from one the distribution has already patched. It covers Red Hat, Ubuntu, Debian, Amazon Linux, SUSE, Alpine and FreeBSD, and it also reads programming-language dependency files and WordPress installations. Results are a report you can read in the terminal, with a severity score and a link for each finding, and it can post them to chat or email. Because it works over SSH and reads only the package list, there is no agent to install and no process left running on the scanned machine. The databases must be fetched first by separate companion tools, and that is the part of the setup people underestimate. It does not patch anything, it does not scan container registries, and it is Linux and FreeBSD only.
Why it matters
Who it suits. Anyone responsible for a handful of Linux machines who currently finds out about a security hole by reading the news. It is the right shape for a small team with no security budget: one scheduled job, one report, no agent on every box. Skip it if everything you run is in containers rebuilt from a fresh base image on every deploy, because then the image scanners are the better fit and the running machine barely matters.
Verdict. Worth an afternoon, with the honest warning that the afternoon is mostly spent on the vulnerability databases rather than on the scanner. Once past that it is genuinely low-effort: a scheduled run and a report. Version 0.42.0 landed on 15 October 2026, so it is in active maintenance. Where it sits against what the radar has already covered is the useful part. Edition 42 covered aquasecurity/trivy and Edition 39 covered anchore/grype, and both are aimed primarily at container images and filesystems; Edition 52 covered pypa/pip-audit for Python dependencies alone. Vuls answers a question those do not: what is installed on this long-running machine right now. If you run containers, start with Trivy. If you run servers that stay up for months, start here.
- No agent. It reads the package list over SSH and leaves nothing behind.
- Uses each distribution's own advisories, so it does not shout about holes already patched.
- Covers language dependency files and WordPress as well as system packages.
- The vulnerability databases must be fetched and kept fresh by separate tools first. This is the real setup cost.
- The configuration file is fiddly, and getting SSH access right across several machines takes care.
- Linux and FreeBSD only, and it reports rather than fixes.
aquasecurity/trivyScans container images, filesystems and code repositories for vulnerabilities, misconfigurations and secrets; broader, and aimed at the build rather than the running machine. Covered in Edition 42.
Track this in Scout
anchore/grypeA focused vulnerability scanner for container images and filesystems, quick to run in a build step. Covered in Edition 39.
Track this in Scout- quay/clair
Runs as a service that analyses container images as they arrive in a registry, rather than as a command you call.
Track this in Scout
The quickest honest path is the project's own container images, which avoid building the Go programs yourself.
