Chapter 59 — Vulnerability management at scale

How it works

Why CVSS alone isn't enough:

   CVSS (Common Vulnerability Scoring System, G1 Ch 48) measures SEVERITY
   IF EXPLOITED -- it says nothing about the PROBABILITY that a given CVE
   is actually being exploited anywhere, by anyone, right now. A CVSS 9.8
   vulnerability with no known exploit and no realistic attack path in
   your environment is, in practice, often lower priority than a CVSS 7.0
   vulnerability under active, widespread exploitation.

EPSS — the probability layer CVSS is missing:

   The Exploit Prediction Scoring System (FIRST.org, the same body that
   maintains CVSS) publishes a DAILY-UPDATED score (0 to 1) for every CVE:
   the estimated PROBABILITY it will be exploited in the wild in the next
   30 days, trained on real-world signals (exploit-code availability,
   scanning/attack telemetry, discussion activity). It's a genuinely
   different axis from CVSS, not a replacement for it -- CVSS says "how
   bad if it happens", EPSS says "how likely is it to happen".

CISA KEV — the strongest signal of all, because it's not probabilistic:

   The Known Exploited Vulnerabilities catalog lists CVEs with CONFIRMED,
   OBSERVED exploitation in the wild -- not predicted, not theoretical.
   US federal civilian agencies are REQUIRED (Binding Operational
   Directive 22-01) to remediate KEV-listed vulnerabilities by a
   published deadline, but the catalog itself is free and useful for any
   organisation: a CVE appearing in KEV should, almost without exception,
   jump to the front of your queue regardless of its CVSS score.

Reachability analysis — cutting the noise that CVSS/EPSS can't:

   A CVE in a dependency you've pulled in TRANSITIVELY (G1 Ch 47) may sit
   in a function your code NEVER ACTUALLY CALLS. Modern SCA tooling
   (reachability-aware scanners -- several major SCA products now offer
   this, alongside open tooling like call-graph-based analysis) can
   determine whether the vulnerable CODE PATH is reachable from your
   application's own entry points. An UNREACHABLE critical CVE is a much
   lower operational priority than a REACHABLE medium one -- this single
   filter routinely eliminates a large fraction of a typical SCA
   finding backlog with no actual risk reduction lost.

The prioritisation formula, combining all four signals plus asset context:

   priority ~ CVSS (severity)
            x EPSS (likelihood of exploitation)
            x reachability (is the vulnerable path actually exercised?)
            x exposure (internet-facing vs internal-only, Part 2's
                        network architecture makes this answerable
                        precisely)
            x asset criticality (Part 7 Ch 41's classification tier --
                        a finding on a crown-jewel system outranks the
                        same finding on a low-value internal tool)
   A CVE that is KEV-listed short-circuits this formula entirely --
   treat KEV membership as an automatic top-priority regardless of the
   other factors' product, because "confirmed exploited in the wild" is
   qualitatively different information from every predictive/contextual
   signal above it.

SLAs set by risk tier, not by CVSS alone:

   Example tiering (adapt the specific windows to your risk tolerance):
     KEV-listed, OR (internet-facing AND reachable AND high EPSS)
       -> 24-48 hours
     high CVSS, reachable, internet-facing, moderate EPSS
       -> 7 days
     high CVSS but unreachable OR internal-only OR low EPSS
       -> next regular patch cycle (e.g. 30-90 days) or batched with the
          next planned dependency update
     low CVSS, unreachable, internal, low EPSS
       -> track, don't actively chase; revisit if any input signal
          changes (a KEV addition, a reachability change from new code)
   SLAs tied to a formula like this, rather than "CVSS >= 7 means 7
   days" applied uniformly, are both MORE responsive to real risk (KEV
   items move faster than a blanket policy would allow) and LESS wasteful
   (unreachable/internal/unlikely findings don't consume the same urgent
   capacity).

The risk-acceptance process, for when SLA genuinely can't be met:

   Not every finding can or should be fixed by its SLA -- a legacy
   dependency with no available patch, a fix requiring a larger
   architectural change than the timeline allows. The answer is the SAME
   documented exception process as Part 1 Ch 4's threat-modeling
   "accept" decision: written, with an OWNER, an EXPIRY/review date, and
   VISIBLE to someone accountable (not a private note in a ticket nobody
   reviews) -- an unfixed finding with a documented, expiring acceptance
   is a managed risk; an unfixed finding silently ignored is unmanaged
   risk wearing a disguise.

The "10,000 findings" problem, practically:

   [ ] AUTO-CLOSE (or de-prioritise into a low-touch backlog) findings
       that are simultaneously unreachable, low-EPSS, not KEV-listed, and
       internal-only -- reviewed periodically as a batch, not individually.
   [ ] BATCH BY ROOT CAUSE: one dependency version bump can resolve
       dozens or hundreds of individual CVE tickets at once -- track and
       communicate progress at the "upgrade X to version Y" level, not
       the individual-CVE-ticket level, wherever that's the actual fix.
   [ ] DASHBOARD BY TEAM/SERVICE/ASSET-CRITICALITY, not a single
       org-wide raw count -- a rising total count is not itself
       informative (it rises simply because you scan more surface over
       time); trend SLA-compliance percentage and KEV/high-EPSS-item
       age instead.
   [ ] Tools built for this specifically: DefectDojo and OWASP
       Dependency-Track (both open source) ingest findings from many
       scanners, support reachability and policy-based triage, and are
       designed around exactly this "manage thousands of findings by risk,
       not by raw list" workflow.