Vulnerability management stopped being a quarterly scan-and-patch exercise years ago, and CISA's latest directive makes the shift official. Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," replaces the older BOD 22-01 — which gave federal civilian agencies 15 days to fix internet-facing Known Exploited Vulnerabilities and 25 days for everything else — with a tiered model that can compress the highest-risk flaws down to a 3-day remediation window, backed by mandatory forensic triage, once agencies begin operating under it by December 7, 2026. That's not an isolated government mandate; it's a signal of where every engineering org is headed — and a forcing function to revisit vulnerability management best practices before regulators or customers do. Meanwhile the data feeding these decisions has its own problems: VulnCheck's analysis of the National Vulnerability Database found that as of September 2024, 72.4% of the roughly 25,357 CVEs published since February 2024 were still awaiting NVD analysis, and 46.7% of CISA KEV-listed vulnerabilities had no NVD enrichment at all. A vulnerability management program that only reacts to scan results and waits on NVD for scoring is already behind. What actually works is a closed loop — discovery, triage, SLA-bound remediation, and verification — running continuously rather than on a calendar. Here's how each stage should function and where most programs break down.
What does a continuous lifecycle actually replace?
It replaces the periodic scan-triage-ticket cycle that treats vulnerability management as a project instead of a running process. NIST SP 800-40 describes patch and vulnerability management as a repeating cycle of inventory, monitoring for new threats, risk assessment, remediation, and validation — not a series of discrete audits. In practice, most organizations still run that cycle on a monthly or quarterly cadence tied to a compliance scan, which means a dependency that becomes vulnerable on a Tuesday might not surface until the next scheduled scan weeks later. A continuous model instead re-evaluates every asset the moment new information arrives: a new CVE publication, a CISA KEV addition, an EPSS score change, or a new commit to a repository. The lifecycle stages don't change — discovery, triage, remediation, verification — but the trigger changes from "it's the first of the month" to "something in the world just changed that affects you." That distinction is what separates a program that closes a KEV-listed flaw within a 3-day window from one still working through last quarter's backlog when the deadline hits.
Why can't CVSS alone drive remediation SLAs?
Because CVSS measures theoretical severity, not the likelihood anyone will actually exploit a given flaw in the near term, and those are different questions with different answers. FIRST.org's Exploit Prediction Scoring System (EPSS) was built specifically to fill that gap: it's a machine-learning model that outputs a 0-to-1 probability that a specific CVE will see exploitation attempts in the next 30 days, using signals like exploit code availability, mentions in security advisories, and observed scanning activity. FIRST is explicit that EPSS is meant to complement CVSS, not replace it — CVSS tells you how bad it would be, EPSS tells you how likely it is to happen soon. A CVE with a CVSS score of 9.8 but an EPSS score near zero and no CISA KEV listing is a very different remediation priority than a CVSS 7.5 finding that is both KEV-listed and has a public proof-of-concept. BOD 26-04's own tiering logic reflects this directly: its 3-day and 14-day windows are triggered by a combination of KEV status, exploit automation potential, and asset exposure — not CVSS score in isolation.
Why is discovery the stage most programs get wrong?
Because discovery is usually scoped to "what we scan," and most organizations don't have a complete inventory of what should be scanned in the first place. A component can enter your environment through a source repository, a container registry, a vendor SBOM, a Kubernetes admission event, or a runtime process that was never declared in any manifest — and a program that only ingests SBOMs from its build pipeline misses the last two entirely. The 2021 dependency-confusion research by Alex Birsan, which affected internal packages at more than 30 companies, demonstrated the same underlying problem from a different angle: attackers exploit the gap between what a team thinks is in its supply chain and what's actually resolved at build or runtime. Continuous discovery closes that gap by treating every new commit, image push, and vendor SBOM upload as a discovery event rather than waiting for the next full inventory sweep — which is also the only way triage and SLA timers can start on time instead of days after exposure actually began.
What SLA benchmarks should engineering orgs actually use?
The most defensible starting point is the same structure CISA has now used twice: differentiated deadlines by both severity and exploitation status, not a single blanket "fix criticals in 30 days" policy. BOD 22-01 set 15 days for internet-facing KEV entries and 25 days for the rest; BOD 26-04 replaces that with tiers as tight as 3 days for flaws that combine KEV status, exploit automation, and high exposure, down to "next scheduled update" for genuinely low-risk findings. Engineering orgs don't need to copy federal timelines exactly, but as vulnerability management best practices go, the shape is worth adopting: shorten SLAs specifically for KEV-listed and high-EPSS findings on internet-facing assets, and allow longer, batched windows for findings that are unreachable or isolated from untrusted input. A flat SLA that ignores exploitation status either burns engineering time patching low-risk findings on the same clock as active threats, or — more dangerously — gives a KEV-listed flaw the same 90-day grace period as a theoretical one.
Why does verification get skipped, and why does that matter?
Verification gets skipped because remediation and closure are usually treated as the same event — a ticket moves to "done" when a PR merges, not when a rescan confirms the finding is actually gone. That assumption fails more often than teams expect: a dependency bump can land in the wrong branch, a container rebuild can pull a cached vulnerable layer, or a fix can be reverted in a later merge without anyone reopening the original ticket. A continuous program closes this by triggering an automatic rescan tied to the same event stream that triggered discovery — every merge, every new image tag — and comparing the diff against the previous scan rather than trusting the ticket status. Without that loop, "time to remediate" metrics measure how fast tickets get closed, not how fast vulnerabilities actually leave the environment, which is the number that matters when the next audit or incident review asks what was actually fixed and when.
How Safeguard Helps
Safeguard runs this exact lifecycle as one connected pipeline rather than four disconnected tools stitched together with tickets. Continuous scanning re-evaluates affected assets the moment a trigger fires — a CISA KEV addition scores in under 60 seconds, a new CVE in NVD in under 2 minutes, and an EPSS delta above 0.1 in under 5 minutes — instead of waiting for the next scheduled sweep. Triage combines EPSS, CISA KEV status, reachability analysis, and business context so a finding's priority reflects exploitability, not CVSS alone. Policy gates enforce SLA, CVSS, and EPSS-based thresholds directly in CI/CD, blocking deployment on violations while routing legitimate exceptions through an approval workflow with a full audit trail instead of a silently ignored ticket. And because every rescan is tied to the same asset timeline, verification isn't a manual follow-up — it's the diff Safeguard shows you the moment a finding is introduced, reachable, or resolved.