NIST's National Vulnerability Database published 40,009 CVEs in 2024 — a 38.83% increase over 2023, an average of 108 new records a day, and the seventh consecutive record-breaking year, with a single-day peak of 824 new entries on May 3, 2024. The strain was severe enough that NIST itself announced changes to NVD's processing model in April 2026, acknowledging that even the canonical vulnerability database can't keep pace unassisted. For a security team of five people supporting fifty engineering teams, that volume makes one thing obvious: manual triage does not scale, and neither does a single central queue that every finding funnels through before a developer ever sees it. What scales is a framework that assigns risk automatically at the moment a finding is created, routes it to the team that owns the code, and holds that team to a remediation clock calibrated to how dangerous the finding actually is — not a flat "fix all criticals in 30 days" policy that treats a theoretical CVSS 9.8 in a dead code path the same as an actively exploited one sitting in a production login flow. This post lays out that framework: the triage signals, the SLA tiers, and the organizational mechanics that make it hold up past the first ten teams.
Why does severity alone fail as a triage signal at scale?
Severity alone fails because CVSS score measures theoretical impact, not the probability that anyone is actually exploiting a given flaw right now, and at 40,000+ new CVEs a year that gap becomes the whole game. A CVSS 9.8 base score reflects worst-case impact and ease of exploitation in the abstract — it says nothing about whether a working exploit exists in the wild, whether your specific deployment is reachable from the internet, or whether an attacker has ever bothered. Treating every CVSS-critical finding as equally urgent creates a queue where a team can be drowning in hundreds of "critical" tickets, most of which will never be exploited, while a genuinely live threat sits buried at position 340. Practitioner literature from vendors including CrowdStrike, Orca, and Picus Security converges on the same fix: layer probability-of-exploitation signals on top of severity rather than relying on CVSS in isolation. That's the core move a risk-based program has to make before it can scale past a handful of teams — severity tells you how bad it could be; you still need a second signal for how likely it is to actually happen.
What signals should an automated triage engine actually combine?
Three public, machine-readable signals combine well: CVSS for potential impact, EPSS for exploitation probability, and CISA's KEV catalog for confirmed real-world exploitation. EPSS (Exploit Prediction Scoring System, maintained by FIRST.org) publishes a daily probability score from 0 to 1 for every known CVE, typically scoring newly published CVEs within about 24 hours of their appearing in the NVD; the current model, EPSS v4, shipped in March 2025. CISA's KEV catalog is updated multiple times a week — as an example, three vulnerabilities were added on July 7, 2026 alone, following four in late June and eight on April 20, 2026 — and it exists specifically to flag CVEs with confirmed active exploitation rather than modeled probability. A triage engine that scores every incoming finding against all three — impact (CVSS), predicted likelihood (EPSS), and confirmed exploitation (KEV) — produces a risk tier automatically, with no human review needed for the 90%+ of findings that clearly fall into "low, patch on the normal cadence" or "critical, KEV-listed, page someone now."
How should severity-based SLAs actually be structured?
SLAs should scale remediation deadlines to the combined risk tier, not to CVSS alone, and they should be enforced automatically rather than tracked manually in a spreadsheet. A workable structure looks like: KEV-listed findings in internet-facing or production services get a same-day or 24-hour SLA regardless of CVSS, because active exploitation is already confirmed; CVSS-critical findings with high EPSS scores (roughly above 0.5, indicating a meaningfully elevated chance of exploitation within 30 days) get a 3-7 day SLA; CVSS-critical findings with low EPSS and no KEV listing get folded into the normal sprint cadence, often 30 days; and everything below CVSS-high with low exploitation probability rides the standard patch cycle, commonly 90 days. The SLA tier should be attached to the finding automatically the moment it's created, based on the live CVSS/EPSS/KEV values at that moment — and re-evaluated if a CVE later gets added to KEV, since exploitation status changes after initial disclosure far more often than teams expect.
How do you route findings to the right team without a security bottleneck?
Routing has to be automatic and code-owner-based, because a central security team manually assigning tickets to fifty engineering teams is itself the bottleneck a risk-based program is supposed to eliminate. The practical mechanism is tying every repository, service, or SBOM component to an owning team at ingestion time — via CODEOWNERS files, a service catalog, or manifest metadata — so a finding lands directly in that team's backlog or CI pipeline the moment it's triaged, with the SLA clock already attached. This is also where reachability matters at scale: a dependency scan that reports every CVE in every transitive package overwhelms the exact teams you're trying to unblock, while a scan that confirms the vulnerable function is actually called from a reachable code path cuts the routed volume dramatically, similar to the 70-85% reduction reported across multiple vendor studies of SCA-only findings. Routing without that filter just relocates the noise problem from one central queue to fifty distributed ones.
What does enforcement look like once triage and routing are automated?
Enforcement means blocking, warning, or auto-fixing at defined points in the pipeline instead of relying on teams to check a dashboard and remember their SLA. A mature guardrail model applies policy at multiple lifecycle points — commit, CI, registry push, deployment admission, and runtime — evaluating conditions like "block any deploy where a KEV-listed critical CVE is present" as a hard gate rather than an advisory ticket. Blocking policies still need an exception path: a time-boxed, approver-gated override for cases where a fix genuinely can't land before the SLA, logged for audit rather than silently bypassed. The operational payoff of wiring severity tiers directly into pipeline gates is that the SLA stops being a policy document nobody reads and becomes a build that literally won't ship until the clock is honored or an exception is on record — which is the only way "risk-based SLA" survives contact with fifty teams shipping on their own schedules.
How Safeguard helps
Safeguard's policy-as-code guardrails implement this exact model without a team having to build the enforcement plumbing themselves. Policies evaluate against a live document combining SBOM, vulnerability, CVSS, KEV, and reachability data, with a built-in "KEV in production" guardrail that blocks deployment the moment a component both appears on CISA's exploited-vulnerability list and ships to a production-labeled target — the same KEV-driven escalation tier described above, enforced automatically rather than tracked by hand. Guardrails run at commit, CI, registry, and admission, each decision produces a signed audit record, and every blocking rule supports a time-boxed exception with approver sign-off, so a team that can't hit a tight SLA has a documented path rather than a silent miss. The Enforcement dashboard then tracks allow/warn/block trends by team and policy, which is what turns "we have an SLA" into a number a CISO can actually report: which teams are inside their tier, which policies fire too often to be sustainable, and where reachability-filtered risk is actually concentrated across the organization.