Know What to Patch, and Why the Rest Has No Fix

A CVE with no fix version is not the same as a CVE nobody has looked at. Fivenines pulls fix-state statements daily from three vendor sources - Canonical (Ubuntu, OpenVEX), the Debian security tracker, and Red Hat CSAF - and attributes each finding to the vendor that made the call.

Instead of an unexplained red row you get Canonical: under investigation, Debian: will not fix, or Red Hat: fix deferred, with the vendor's own note quoted verbatim. Red Hat verdicts are inherited by AlmaLinux and Rocky Linux, which rebuild RHEL but publish no triage of their own.

Only a vendor can quiet a finding. A verdict of not affected or will not fix is stored with its attribution or not at all, and if a vendor feed goes stale for more than seven days its verdicts stop applying and the page tells you so. Silence is never read as good news.

Every finding lands in one of four buckets, and the split is the point. Patchable is work: a fix exists in a channel you already have. Requires subscription is a real fix published only behind a paid channel such as Ubuntu Pro or ESM - actionable, but not by running apt. No fix available is exposure that needs compensating controls rather than patching. Vendor cleared is what a vendor has explicitly ruled out.

Folding those together produces a number that only ever grows, no matter how well you maintain a fleet, because unfixed CVEs accumulate and no patch removes them. Fivenines counts the work queue in the headline and states the rest on its own line - including how many of the unfixable findings are high or critical, so a quiet grey number can never hide a serious exposure.

If you already pay for the channel, the fix is work, not a purchase. The agent reports whether an Ubuntu host is attached to Ubuntu Pro and which services are enabled, and a fix published in a pocket one of those services opens moves into the patchable queue instead of sitting in the subscription bucket. It is decided per pocket rather than per machine, so esm-infra does not unlock a FIPS-only fix. A host that has not reported its attachment keeps the cautious answer - the fix stays listed as needing a subscription, which is what it is until we know otherwise.

A patched host running a two-year-old base image is not a patched system. Once Docker monitoring is on, Fivenines discovers every image your containers reference and scans the OS packages inside it - Debian, Ubuntu and Alpine layers today.

Images are scanned per image digest, per organization, so fifty hosts running one image is one scan and one row, and the affected hosts fall out of the container data you are already sending. Stopped containers count: the image is still on disk and still ships whatever it shipped.

An image we could not read is never rendered as clean. Images without a completed scan get their own list, labelled as exactly that, because an absent result is not a zero.

Every plan sees its own severity summary and counts. Pro and above unlocks the per-package view, fix versions, vendor verdicts and container image scanning.

Debian and Ubuntu publish advisories against the source package - openssl - while your server has binary packages installed - libssl3t64. A scanner that matches on name alone silently misses those, with no error and no gap indicator.

Fivenines maintains a binary-to-source map rebuilt nightly from the Debian and Ubuntu archives, so an installed binary resolves to the source package its advisories are filed under. On current Debian and Ubuntu releases the majority of installed packages carry a binary name that differs from their source, which is coverage a name-only match does not have.