Vulnerabilities and updates

Where the CVE data comes from, how it is compared, where the limits are.

Where the data comes from #

NODE64 uses OSV.dev as its source – an open vulnerability database that aggregates the security advisories of the distributions: Debian, Ubuntu, Alpine, Rocky, SUSE and others. For a Debian system the Debian security advisories are used, not some generic CVE list.

That matters because distributions backport fixes: Debian often ships an old version number with the patch applied. A tool that merely compares version numbers against a CVE list produces false alarms all day long.

How the comparison works #

The server takes every installed package, looks up the advisories for your operating system and compares versions by the rules of the respective package manager – for Debian that means dpkg semantics, including epoch, tilde and backport suffixes. If your version is below the fixed one, a finding appears.

The rating follows the severity from the advisory; where available, the CVSS value is shown.

Python packages too (pip) #

Besides operating-system packages, NODE64 also checks Python packages installed via pip – against the same source (OSV.dev, ecosystem PyPI). This closes a common gap: a Django, Flask or requests pulled in with pip install does not show up in the system package manager at all, yet can carry a known vulnerability just the same. Comparison follows the Python version rules (PEP 440), not dpkg.

Recorded are the pip install locations (system-wide pip, pip install --user), not the distribution's Python packages – those already run through the operating-system ecosystem and would otherwise be counted twice. The agent only reads the package metadata on disk for this; it does not run pip. Such a finding is fixed via pip, usually within the affected project or its virtual environment:

pip install --upgrade requests

What the result is not #

• Not proof of exploitability. A hole in a library nothing on your system calls is real, but perhaps not urgent.
• Not complete for third-party software. Anything installed outside the package manager – a tarball under /opt, a self-built binary – is unknown to the package manager and therefore to NODE64. Other language ecosystems such as npm (Node.js) are not covered yet either – Python packages from pip, however, are (see above).
• Not real time. The data is refreshed daily. Hours pass between publication of a vulnerability and its arrival here.

Urgency: what to do first #

The severity of a finding says how bad it would be. It says nothing about whether it will happen. A system that has not been updated for a while easily shows 191 CVE findings, thirty of them "critical" — at which point none of them is.

So a second dimension sits next to severity: urgency. It rests on two sources.

Exploitation catalogues (KEV). Lists of vulnerabilities for which exploitation in the wild is documented — not suspected, documented. NODE64 uses two:

• the EUVD of ENISA (European Union Agency for Cybersecurity), the European vulnerability database. It is the primary source: it contains the US list in full and adds entries of its own.
• the CISA KEV catalog (US agency). It has run longer and is the only source that records whether a vulnerability has been used in ransomware campaigns.

EPSS (Exploit Prediction Scoring System, FIRST.org). A daily estimate of how likely exploitation is within the next 30 days.

That yields four levels:

The findings list is sorted by urgency. To get the old order, append ?sort=severity to the URL.

The limits of this ranking #

This is the most important section on this page, and it deliberately does not sit in the small print.

• EPSS estimates exploitation somewhere, not exposure here. A value of 60 % does not mean this system has a 60 % chance of being attacked. FIRST states that EPSS accounts neither for "whether it affects your environment" nor for compensating controls — it is a statement about the world, not about your server.
• A missing EPSS value is not an all-clear. EPSS covers very many identifiers, but not all. Where nothing is listed, the source says nothing — the finding stays regular and does not disappear.
• KEV is shaped by a US agency and therefore incomplete. The CISA catalog was created for US federal agencies; what is absent from it is not thereby harmless. The EU list compensates in part, but it too is a selection, not a complete picture.
• Neither replaces updating. Urgency orders the queue. It does not shorten it.
• Effort figures are estimates. Under "What first" each step carries an effort class — low, medium, high. How long it actually takes depends on your maintenance window, your reboot rules and your dependencies. That is why there is a class and not a number of minutes.

You get an email in one case only #

A new finding does not automatically become a message — otherwise the first evaluation run on a neglected system would be a flood. Normally NODE64 collects everything into one digest.

The only exception is a finding at level Immediate: a vulnerability present on your system for which exploitation is documented. That one goes out at once, and the mail says why it did.

Sources #

• EUVD — European Vulnerability Database, ENISA: <https://euvd.enisa.europa.eu/>
• CISA Known Exploited Vulnerabilities Catalog (published under CC0 1.0): <https://www.cisa.gov/known-exploited-vulnerabilities-catalog>
• EPSS — Exploit Prediction Scoring System, FIRST.org: <https://www.first.org/epss/>

All three are fetched once a day, not on every page view.

Containers #

For running containers NODE64 records image, tag and digest. A finding appears when an image is behind the published state – either because the same tag has been rebuilt since (often a security patch) or because a newer version exists.

What you can do #

The usual path is on the finding:

apt update
apt install --only-upgrade openssl

With many affected packages, the upgrade plan as a script in the device view is worth a look – it bundles everything.

After updating, check whether a reboot is needed. An updated library only takes effect once processes load it again. NODE64 reports pending reboots as a separate finding.

Which systems are matched #

Each of these ecosystems brings its own version rule. Debian compares with dpkg semantics, Rocky and AlmaLinux with rpmvercmp, FreeBSD with the ports rules (_revision, ,epoch, pre-release stages such as rc1), PyPI according to PEP 440. Treating them alike means reporting either long-fixed holes or – worse – failing to report real ones.

One detail that is not obvious: Rocky Linux and AlmaLinux name the same packages differently. Rocky lists its advisories under the source package (openssl), AlmaLinux under the individual binary packages (openssl-libs). NODE64 matches both names for both.

When no matching is possible #

For some systems there is no evaluable catalogue. Until this stage they simply received zero findings – and zero findings look like a clean system. That is the most dangerous kind of non-report, because it reassures.

The device view and the report therefore now state explicitly why no matching happens:

• Debian derivative without base version. Systems such as Parrot or Kali report their own version number, not the underlying Debian release. The real base is in /etc/debian_version; older agents do not transmit it. After an agent update, matching starts by itself.
• No feed available. Arch, OpenWrt, Gentoo and NixOS do not publish their advisories in a machine-readable form.
• Feed split by product. With SUSE, Red Hat and CentOS the correct identifier depends not only on the version but also on the enabled modules. A simplified mapping would silently skip some packages – better no matching than half of it looking like the whole.

The hardening checks continue to run in all these cases. Only the package matching is unavailable.