Skip to content

CVE monitor

Source: apt list --upgradable (polled on a tunable interval — see the Hardening checklist for production cadence).

The CVE monitor is the simplest of the three periodic snapshotters. It checks how many security upgrades are pending and emits one event per change.

How it works

Every cycle, the monitor:

  1. Runs apt list --upgradable (no sudo — relies on the apt cache that unattended-upgrades keeps fresh by cron).
  2. Filters for entries from the -security pocket — i.e. updates flagged by Ubuntu/Debian as security fixes.
  3. Computes a signature = sorted list of package=version.
  4. If the signature changed since the last cycle, emits a security_updates_pending event.
  5. If the signature is the same, stays quiet (no duplicate alerts).

This dedupe-by-signature behavior means you don't get spammed with the same "N packages pending" alert on every cycle. You only hear about it when the list changes.

Severity logic

Condition Severity
0 security updates pending (no event emitted)
1-4 pending MEDIUM
≥ 5 pending HIGH

Going forward, severity will also weight by package criticality (openssl, openssh-server, sudo, glibc, kernel-* deserve HIGH even at count=1) — see the playbook which already implements this in the analyst's reasoning.

Sample event

{
  "source": "cve",
  "category": "security_updates_pending",
  "severity": "HIGH",
  "description": "8 aggiornamenti di sicurezza pendenti: openssl, libssl3, openssh-server, openssh-client, sudo, +3 altri",
  "raw_line": "security_updates_pending count=8 sample=openssl, libssl3, openssh-server, ..."
}

What the AI investigation does with this

When a HIGH security_updates_pending event fires, the dispatcher loads playbooks/security_updates.md and the analyst:

  1. Reads the package list.
  2. Runs apt changelog <pkg> for the most critical ones to extract CVE IDs.
  3. Checks if unattended-upgrades is active (and if so, how recently it last ran — if it's stuck, that's a separate alert).
  4. Checks /var/run/reboot-required to see if the patches will need a reboot.
  5. Writes a report with: list of CVEs, criticality assessment, recommended action (typically "patch now in maintenance window"), no auto-actions (patching is an operational decision Fenrir doesn't take autonomously).

Tuning

The 6-hour cadence is conservative for a SOC — most operators check security updates daily anyway. If your business needs faster turnaround:

  • Lower the interval in app.py (e.g. CVEMonitor("cve", self.event_queue, interval=3600) for hourly).
  • Pair with unattended-upgrades so the patches get installed automatically — Fenrir then becomes the audit trail of "we knew at T0, system installed at T1, business resumed at T2".

What this does NOT do

  • It does NOT install updates. That's unattended-upgrades' or your operator's job. Fenrir tells you about them; you decide when.
  • It does NOT verify CVE applicability beyond Ubuntu/Debian's -security flag. Some CVEs in the security pocket may not affect your specific configuration; the analyst's job in step 2 above is to filter for the ones that actually matter.
  • It does NOT cover pip/npm/gem/cargo ecosystems. Application-level vulnerabilities require Trivy, Snyk, or pip-audit — out of scope for Fenrir today.