3.5 KiB
id, title, sidebar_label
| id | title | sidebar_label |
|---|---|---|
| vulnerabilities | Vulnerabilities | Vulnerabilities |
Each Linux server reports the packages it has installed. Vantage matches them against the security advisories published by that server's own distribution and raises a finding for anything not yet patched.
Requires the vulnerability scanning feature on your licence. Without it, nothing is collected and there is no findings page. See Licensing and entitlements.
What gets scanned
Linux servers running apt, dnf/yum, apk, zypper or pacman. Agents
report their package list hourly, and only when it has changed since the last
report.
Windows servers are not scanned.
Some distributions publish no security advisories Vantage can read. Those servers are shown as unsupported, rather than as having no vulnerabilities. Those are very different answers, and only one of them is good news.
Why versions look "wrong"
A finding names the version your distribution ships, not the upstream release.
Ubuntu's openssl 3.0.2-0ubuntu1.15 carries security fixes backported into
what still calls itself 3.0.2, so public CVE databases listing "3.0.2" as
vulnerable are describing upstream, not your machine.
Vantage matches against your distribution's own advisories, which is why a server can be running a version some scanners flag while Vantage correctly reports it as patched.
For the same reason a severity here may be lower than the one you find on a CVE website. Debian and Red Hat routinely downgrade a rating when the vulnerable code path is not reachable in the way they build the package. Their rating is the accurate one for the package you are actually running.
The board
The Vulnerabilities page groups findings by CVE, one row each, with the number of servers affected. Expand a row to see them. The same CVE across forty machines is usually one decision, not forty.
Severity counts at the top filter the list when clicked. The state tabs switch between open, accepted and fixed.
The vulnerability database's age is shown above the board. If a pull has failed for long enough for the data to be stale, that becomes a warning: a low count against three-week-old data is not the same as a low count.
Fixing something
A finding with a known fixed version gets an Apply updates button. It installs every pending update on that server now and opens the patch run so you can see the result.
To keep servers patched without clicking, create a patch policy with Security updates only.
Accepting a finding
Some findings cannot be fixed today: a kernel CVE waiting on a reboot window, or one with no vendor fix published at all.
Accept hides a finding from counts and alerts until a date you choose, with a reason that is recorded in the audit log along with your name. On that date it reopens by itself.
An expiry date is required, so nothing is dismissed permanently by accident.
Alerts
Alert rules live with your notification channels. A rule has a minimum severity, an optional server tag filter, and the channels to notify.
A rule sends one summary per scan covering everything newly found, rather than one message per finding. A single update to the security data can raise hundreds at once.
Findings that were already open do not re-alert.
Fleet-wide package search
Search your whole fleet for a package by name to see which servers have it and at what version. Useful during an incident, before there is a finding for it.