Skip to main content

Monitoring pending updates and CVEs

Every Linux host reports how many package updates are pending, how many of them are security patches and whether it is waiting for a reboot, whichever package manager it uses. On top of that, the package inventory the agent already collects is matched on the platform against the OSV vulnerability database, so known CVEs show up per host on every distribution. Nothing to configure, and the agent never installs anything.

How the package manager is recognised​

Five definitions share the service name os, one per manager, each matched on the installed package: apt, dnf, dnf5 (Fedora), zypper and apk-tools. They run once an hour, read-only, with a time budget of one to two minutes per command:

  • apt: apt-get -s -o Debug::NoLocking=true upgrade, a dry run that takes no lock, so it neither blocks a real apt run nor waits for one. Every Inst line is a pending update; the ones coming from a suite named security are security updates. The reboot flag is the file /var/run/reboot-required.
  • dnf: dnf -q check-update (its exit code 100, "updates available", is treated as a normal outcome), dnf updateinfo list security --available, dnf updateinfo list --with-cve --available and dnf updateinfo summary, plus the same reboot file.
  • dnf5: dnf -q check-update, dnf advisory list and dnf updateinfo summary, plus the reboot file.
  • zypper: zypper --non-interactive -q list-updates and zypper list-patches --category security; the reboot flag is /run/reboot-needed.
  • apk: apk list --upgradable.

What is collected​

Counts. Pending updates on every manager. Security updates on apt, dnf, dnf5 and zypper. On the RHEL family the local advisory data goes further: the number of CVE and package pairs pending, and a severity split (critical, important, moderate, low). Fedora reports the same split plus the number of security notices.

Reboot required. A 0/1 flag from the distribution's own marker file.

Known vulnerabilities. The agent already inventories installed packages from the dpkg, rpm and apk databases. The platform correlates that inventory with the OSV database and produces, per host, the CVEs that apply, their severity, the affected packages and the version that fixes them. The agent's part is only the inventory: it never calls an external feed itself. Severity prefers your distribution's own assessment over the generic CVSS score, a vulnerability known to be exploited in the wild is treated as critical regardless, and a fix that exists only behind an extended-support subscription is labelled as such. The count of actionable critical CVEs lands back on the host as a metric.

SignalMetric
Pending updatessvc.os.updates_pending
Pending security updatessvc.os.security_updates
CVE and package pairs pending (RHEL family)svc.os.cves_pending
Severity split (RHEL family, Fedora)svc.os.security_critical, svc.os.security_important, svc.os.security_moderate, svc.os.security_low
Security notices (Fedora)svc.os.security_notices
Reboot requiredsvc.os.reboot.exists
Actionable critical CVEs, matched on the platformsvc.os.cve_critical

Names, tags and units are in the metrics reference.

Alerts out of the box​

RuleFires whenSeverityShips
Host is waiting for a rebootthe reboot flag has been set for 6 hourswarningon
Security updates are piling up50 or more security updates pending for an hourwarningon
Critical CVEs in installed packagesat least one actionable critical CVE is matched to the hostwarningon

The six-hour hold separates a kernel update nobody scheduled a reboot for from the minutes between an upgrade and its planned restart. Fifty security updates held for an hour is a host that fell off its patch cadence, not the morning after a large release; the incident closes once the count is back under 20. The CVE rule fires without a hold because it is narrow by construction: it counts critical findings that are actionable, fixable in your release or actively exploited. A critical with no fix anywhere stays visible as posture in the security module and does not page anyone, because there is nothing to run. All three are warnings: patch state is never a phone call. Thresholds and hysteresis for each rule are in the rules catalog.

Going deeper​

The Security module collects these signals per fleet: pending and security updates worst first, the known vulnerabilities with their source and fixing version, and the hardening scan next to them.

Limitations​

  • Counts refresh once an hour, so a patch run shows up within the hour, not within the minute.
  • apk reports a total only: Alpine publishes no security split, and there is no reboot flag to read.
  • The severity split and the local CVE pairs exist only where the distribution ships advisory metadata (RHEL family, Fedora). On Debian, Ubuntu, SUSE and Alpine the CVE view comes from the platform-side correlation alone.
  • On apt an update counts as a security update when it comes from a suite named security; a mirror that renames the suite hides them from that count.
  • The inventory is the host's own package database. Software installed by other means (inside containers, by language package managers, from tarballs) is not matched.
  • The agent reports. It never runs the upgrade and never reboots the host.