Findings · 6 min read

How Noxen scores severity

Five buckets — Critical / High / Medium / Low / Info — sourced from distro triage labels first, CVSS v3 vector second, and database fallback last. Noxen never re-scores CVEs; every severity comes directly from upstream data.

The precedence chain

Per record, in order:

  1. Distro-triaged label — Ubuntu Security Notices' severity string, Debian Security Tracker's urgency tag, Red Hat security errata's severity field. These reflect the distro's own triage, accounting for backports, sandboxing, and default configurations. When present, this label wins.
  2. CVSS v3 base score — the FIRST.org canonical 0.0–10.0 score, parsed from the upstream vector string. Bucketed via the standard CVSS v3 cuts: 9.0–10.0 critical, 7.0–8.9 high, 4.0–6.9 medium, 0.1–3.9 low.
  3. OSV database_specific.severity — used when neither (1) nor (2) is present. Some records only have a per-database opinion; we surface that as a last-resort fallback.
  4. "medium" default — if every upstream field is empty, default to medium so the finding is visible but not noisy. Vanishingly rare in practice (<0.1% of feed records).

Why distro labels beat CVSS

A CVE with a CVSS v3 base of 9.8 ("RCE, network-attackable, no auth") might be triaged as medium in Ubuntu because:

The CVSS v3 score reflects "how bad is the vulnerability in isolation". The distro label reflects "how bad is the vulnerability on this distro, with this configuration." For the question Noxen is answering — "should I patch this Ubuntu host?" — the distro label is more relevant.

What about KEV and EPSS?

Noxen's CVE feed includes CISA's Known Exploited Vulnerabilities catalogue and FIRST.org's EPSS exploit-prediction scores when the upstream data ships them. They're surfaced as tags on findings, not as severity inputs:

We deliberately don't combine KEV/EPSS into the severity bucket. That'd be re-scoring upstream data, which Noxen never does. Read more in how to triage CVE findings.

Severity for non-CVE findings

Noxen flags four other finding categories besides CVEs. They have static severity assignments:

Exposed admin surface
Critical for unauth services with known exploitation history (Redis, Mongo, ElasticSearch, Docker daemon API, .git/config leak, .env leak). High for everything else (Grafana, Portainer, phpMyAdmin, Pi-hole, Jellyfin, Plex, Sonarr/Radarr, Home Assistant, etc.) — the assumption being these always have weak default credentials in the wild.
Weak TLS
High for SSLv3 or TLSv1.0 listeners. Medium for TLSv1.1, weak ciphers (RC4, 3DES, export-grade), or certs expiring within 14 days. Low for missing OCSP stapling.
Missing security header
Medium for missing HSTS on a TLS endpoint, missing CSP on a public page, missing X-Frame-Options. Low for missing Permissions-Policy or Referrer-Policy.
Open port
Info by default — surfaced for awareness but rarely actionable. SSH on 22 and HTTP on 80 are normal; we still log them so you can see what changed when something appears.

Severity is what you triage by

The Dashboard tiles default to filtering by severity (click Critical tile → see all critical findings across the fleet). Webhooks have a per-sink minimum-severity filter (a Slack channel can fire only on critical, while a Discord channel hears everything). SIEM exports include the severity bucket and the underlying CVSS score so your downstream tooling can apply its own bucketing.

For walking through real findings end-to-end, see remediation for what to actually do with each severity bucket.