A vulnerability remediation SLA your engineers can keep

If you lead an engineering team, this post is written for your Security team. You can send it to them with your next triage report.

Your vulnerability remediation SLA starts a clock on every alert. On Redash, an open-source dashboarding tool we'll use as an example, that is 272 clocks. But only about 10% of them need action.

To determine which alerts needed action, a coding agent traced each alert through the code and k9 scored the result. Of those alerts, 26 had a traced path from untrusted input to the vulnerable function. Three had an open question for a person to settle. The other 243 came back safe to defer, with the evidence written down.

Holding engineering to your SLA on the alerts that carry reachable risk gets your team:

• Safer software for your customers: Engineering fixes the vulnerabilities with a path to real risk first, instead of working through the queue by severity.
• More risk reduced per engineering hour: Remediation effort goes to the alerts that need action, about 10% of the queue, instead of being spread across all of it.
• An SLA your engineers meet: the list is short, and every item on it has a traced path to real risk or a named question to resolve.
• A written basis for every deferral: the evidence behind it and the conditions that reopen it, ready for an auditor.
• Confirmed exploitation that overrides deferral: A KEV listing moves an alert back onto the schedule on the next triage run, whatever the reachability analysis said.

Your policy already asks for exactly this: a risk assessment of every alert. The rest of this post shows what that looks like, alert by alert.

The problem you already have

You own a policy that puts a remediation deadline on every alert. Engineering owns a queue that grows faster than any team can clear it. Scanners open an alert for every vulnerability in every manifest they read, and new advisories arrive every day.

A queue that size, sorted by severity or by arrival, guarantees priority inversion. The alert with a live path to production waits behind the alert in a test library that never ships, because nothing in front of the engineer says which one is reachable. Both carry a severity. Both carry a deadline.

Then the SLA reports come in, and they are missed across the board. A missed SLA carries no signal when it is missed on everything. When engineering asks for an exception, the request arrives without per-alert evidence, so you have no defensible basis to approve it. Saying no is the only safe answer, and the queue grows again.

Nobody in this picture is doing their job badly. The per-alert evidence that would let both teams do their jobs well did not exist.

Your policy already says assess risk

Most vulnerability management policies are built on a risk standard. NIST SP 800-30 defines risk as "a function of the likelihood of a threat event's occurrence and potential adverse impact should the event occur," and it produces risks that "can be prioritized by risk level and used to inform risk response decisions." NIST SP 800-40 Rev. 4 applies the same idea to patching. It tells you to "prioritize the vulnerabilities that are causing the most risk to the organization," and it lists accepting the risk as a legitimate response when "the potential impact is low enough that no additional action is needed."

CISA made the same move for federal agencies in June 2026. BOD 26-04 replaced the KEV directive, BOD 22-01, with deadlines set by four facts about each vulnerable asset: whether the asset is publicly exposed, whether the vulnerability is in KEV, whether exploitation can be automated, and how much control an attacker gains. Its stated aim is "prioritizing high-risk vulnerabilities for timely action, while deferring action against low-risk vulnerabilities." The directive binds federal civilian agencies only. It still puts deferral of low-risk vulnerabilities in writing as federal policy.

The policy says assess risk. The implementation usually keys the deadline on severity, because severity was the rating every scanner put on every alert. Severity describes how bad the vulnerability could be, given the advisory publisher's assumptions. It says nothing about whether your code calls the vulnerable function, whether an untrusted actor can reach it, or whether anyone is exploiting it.

Picture the same broken lock on three doors: the front door of an office, an interior supply closet, and a door in a building nobody enters. The lock is equally broken on all three. The risk is not equal.

The Redash alerts show it. We looked up each alert's severity in the GitHub Advisory Database, the rating Dependabot shows engineers.

None of the 11 Critical alerts needed action. Of the 112 rated Critical or High, 8 did: 7%. Across all 272 alerts, about 10% did. Most of the alerts that needed action were rated Medium.

While these statistics are for one project, they match what we see across the other projects in our published sample reports. What we don't see is severity providing a useful prioritization signal.

Your policy may not rely on NIST SP 800-30. It may set deadlines from CVSS tiers, as GitLab's published SLAs do, route decisions through CISA's SSVC decision tree, or compute its own composite score. Each weighs some version of the same factors: whether the vulnerability is being exploited, whether an attacker can reach it here, and how much the system matters.

Reachable Risk puts that assessment into practice. Each alert is analyzed for reachability where it is deployed, weighed against current exploitation data, and reported as residual risk on the NIST SP 800-30 scale. Use that residual risk as your score, or feed its evidence into the scorer you already have.

What the evidence looks like, per alert

Reachable Risk splits the work. The engineering team's coding agent traces each alert through their code, and k9 scores the result against its risk rubric. The trace starts from every entry point the code exposes, not only the public one, and it counts input as attacker-controlled unless it comes from the project's own code or an actor the team has declared trusted.

The exploitation evidence comes from two sources. KEV catalogs list vulnerabilities with confirmed exploitation, and EPSS is a daily forecast of how likely exploitation is.

Every alert ends in one of four verdicts: FIX_TODAY, REVIEW, SCHEDULE, or DEFER. REVIEW means the evidence is incomplete and a person decides.

Here are two records from the Redash report, published in full as a sample report.

A scheduled fix. CVE-2026-45409 in idna, the library that encodes international domain names. A crafted domain name makes the encoder burn CPU.

Why SCHEDULE: a traced call path in redash-worker carries an attacker-controlled hostname into the vulnerable encoder. Threat absent, Exposure present, Impact present on a tier_2 production asset. [...] the same alert is DEFER in redash-server, where no query-runner HTTP call is made, and SCHEDULE in redash-worker, where it is.

Residual risk: moderate, 50/100 (inherent high 80; 30 points retired).

Evidence: not in KEV. EPSS percentile p0.340 [...]

The same alert gets two verdicts because it runs in two places. In the worker, a user-supplied hostname reaches the vulnerable function. In the web server, it never does.

A severity-keyed policy puts one deadline on both copies. This record lets you hold engineering to the deadline where the path exists.

The scores read on the NIST SP 800-30 scale. Inherent risk assumes the worst: the flaw is exploited and the code path runs. Residual risk is what remains after checking both. The retired points are the difference: the risk the analysis ruled out.

A deferral. CVE-2024-34069 in werkzeug, a flaw in the interactive debugger. The report defers it because the application server runs with no debug flag, so the debugger is never installed. It is not in KEV, and its EPSS percentile is p0.878. It belongs to a group of 64 alerts whose vulnerable functions are not reachable from any entry point, and the report captures what would change the answer for the whole group:

What would change these: a code change that introduces a call to one of these functions, or a KEV listing, which would activate the kev_emergency floor regardless of reachability.

That line is usually missing from exception requests. The deferral is not permanent. It specifies its own reopen conditions, and one of them is outside engineering's control: if the vulnerability shows up in a KEV catalog, a policy floor forces it to at least SCHEDULE whatever the reachability analysis said.

Every alert gets a verdict, a reason, and its inherent, residual, and retired risk. The reachability basis and the KEV and EPSS evidence come with each alert or its group, and the report names the rubric version that produced it.

The trade

For Redash, the report sorted the 272 alerts into 0 FIX_TODAY, 3 REVIEW, 26 SCHEDULE, and 243 DEFER. Every one of the 243 deferrals is listed with its scores, and the report groups them into seven evidence patterns, each with its reasoning and its reopen conditions.

Engineering commits firmly to your SLA on the 29 alerts above DEFER. That commitment is credible for the first time because it covers only the alerts with either a traced path to real risk or a named question to resolve, about 10% of the total. The sample report's fictional policy gives those 26 scheduled alerts a 60-day window and the 3 under review 30 days to resolve the open question.

In exchange, the 243 deferrals come to you as evidence rather than as an ungrounded exception request. Each alert has its scores, and each group states why its members are safe to defer and what would reopen them. You decide whether to accept them. You are deciding on evidence.

The report also tells you where to look hardest. Of the Redash deferrals, 26 rest on the trust model engineering declared, such as which administrators and identity providers count as trusted, and the report calls that group the most sensitive to the model changing. Six more were deferred because reachability could not be determined and there is no sign of exploitation, and they are disclosed as their own group. The trust model lives in a file in the repository, so you can review it like any other control.

What you get

• Safer software: The 26 Redash alerts with a traced path to the vulnerable function get fixed on schedule instead of waiting behind 243 that were safe to defer. The priority inversion described at the top of this post goes away.
• A better return on your vulnerability management program: On Redash, engineering's remediation work covers 29 alerts instead of 272, about a ninth of the queue. Every hour of that work goes to an alert with a traced path to real risk or an open question to settle.
• An SLA that means something again: A missed deadline on a scheduled alert is a real signal, because the list is short and every item on it matters.
• One measure both teams track: How many alerts are both reachable and showing evidence of exploitation now, and how much of the scanner queue the analysis ruled out. On Redash, the answers were zero and 89%. It is also how you show the program's return: real risk reduced, and scanner noise ruled out.
• Audit-ready records: Every deferral has a written basis, the evidence behind it, and the rubric version that scored it. When an auditor asks why an alert stayed open, the answer already exists.
• Confirmed exploitation overrides everything: A KEV listing forces at least SCHEDULE regardless of reachability, and a KEV listing tied to ransomware forces FIX_TODAY. The reports re-score every run, so a deferral does not outlive the evidence that justified it.
• A shared language: Both teams discuss the same facts: where the vulnerable code runs, who can reach it, and whether anyone is exploiting it.

None of this requires you to change your policy. It requires your engineering team to bring you the evidence your policy already asks for.

How to start

1. Ask your engineering team for their triage report: Read the deferral groups first. They are where the evidence standard shows.
2. Map the verdicts to your policy's priorities: Your policy's deadlines stay yours. When your policy is supplied, the report computes each alert's window from it. The sample reports use one fictional policy so they compare with one another.
3. Agree how often the reports run: Each run re-checks every deferral against current KEV and EPSS data. k9 runs its own weekly.

The published sample reports show the full records across several open-source projects, including every deferral.