Distributions
The Linux distributions people actually run
CveDeck connects over SSH, reads the package inventory, and matches it against advisories for that distribution and release. Nothing is installed on the host.
Inventory parsing and advisory matching
- Debian
- Ubuntu
- Raspbian
- RHEL
- CentOS
- AlmaLinux
- Rocky Linux
- Oracle Linux
- Amazon Linux
- Fedora
- Alpine
- Arch
- openSUSE
- SLES
- Wolfi
- Chainguard
A distribution without its own OSV.dev tracker is matched against the upstream it derives from. An unrecognised Linux system is queried against every Linux ecosystem CveDeck knows, rather than guessing at a single answer.
Windows hosts can't be scanned. They can be discovered and enrolled, but scans are refused, because Windows inventory can't be matched against vulnerability data yet. Why it refuses rather than guesses.
Matched against the right advisories
- Release-specific. The distribution and release come from the host's
/etc/os-release. An Ubuntu host is checked against Ubuntu's tracker for its release, so a Debian fix version never shows up on an Ubuntu machine just because both use.deb. - Judged against the host's own release. OSV lists a Linux vulnerability once per
release, each with its own fix, so asking about a distribution as a whole compares a package against
every release's fix at once. A fully patched Debian 13
curlcame back vulnerable to anything Debian 14 fixed at a higher version number: 49 advisories asked one way, 25 asked the other. Each package is now asked about both its distribution and its own release, and advisories that don't affect that release are dropped. Nothing is dropped when CveDeck can't be sure, such as a release query that failed or a release OSV doesn't track. - Binary and source package names. Libraries often install under a different name
from their source package, such as
libssl3fromopenssl. Both names are checked, so those findings aren't missed. - No borrowed fixes. When one advisory covers several related packages, a fix version published for one package is never assigned to another.
- Epoch-aware versions. Debian and RPM version epochs (the
2:in2:1.2.3-1) are handled, so advisories match whether or not they include one. - One record per CVE. An advisory that resolves several CVEs at once becomes a separate finding for each, so every CVE can be traced.
What you can actually fix
Flagging a CVE that has no patch in the host's repository just produces an upgrade that upgrades nothing. So a finding carries what is actually known about fixing it, which is not always the same thing as a fix.
-
Patch available
The host's own release ships a fixed build. CveDeck shows the fixed version and generates the upgrade command for that host's package manager (
apt,dnf,apk,pacmanorzypper), plus one script covering every fixable package on the host. A fix published only for some other release never becomes a command. -
Pending vendor patch
The vendor has acknowledged the CVE but hasn't released a fixed build yet. No upgrade command is offered.
-
Fixed only in Debian 14
The fix exists, but in a release the host isn't running, or behind Ubuntu Pro. The finding is labelled with the release that has it, and the fix plan lists it in a comment rather than in the upgrade command, because upgrading packages can't clear it. Upgrading the distribution does, or the host's own release publishing the fix.
-
Upstream fix
Fedora, Amazon Linux and SUSE have no per-release data in OSV, so a fix found for them can't be confirmed against the host. It's shown as the upstream it came from — "Upstream fix in RHEL 9" — and never offered as a command.
-
Fix status unknown
The advisory names no package at all — kernel and OS-level advisories are the usual case — so there's nothing to compare a version against. It says the fix status is unknown rather than "no fix is published", which would be a claim about a question nobody asked.
-
Cleared
The installed version is at or above the fixed version. The finding clears on the next scan.
Commands are generated for you to review and run. CveDeck never executes anything on a target. A dependency explorer shows which installed applications rely on a package, so a removal doesn't take a service down with it.
Read-only, over SSH
- Authenticates with a password or an Ed25519, ECDSA or RSA key. Keys sent with a request are parsed in memory and never written to disk.
- Pins each host's SSH key the first time a connection to it succeeds, and refuses a host that later presents a different key before sending it any credential. How a changed key is reported.
- Runs read-only commands only, so a dedicated unprivileged account works, with no sudo and no write access.
- Also reads the running kernel and pending-reboot state, so a patched host still running an old kernel isn't reported as clean.
- Subnet discovery sweeps (ICMP, TCP connect and unauthenticated SSH, HTTP and SMB banner reads) find hosts to enrol, and send no credentials.