Why Kev Compliance Breaks in the Answer, Not the Deadline

Under BOD 26-04, the shortest KEV compliance window is three days. Finding out what the rules require costs nothing, CISA publishes each entry the day it joins the Known Exploited Vulnerabilities (KEV) catalog, and the directive spells out how the clock is set. The expensive part is your own answer. Is this vulnerability in the images you ship, is it running, and is it exposed? If that answer takes two days, you have one day left to fix it.

This article covers where KEV programs lose that time, why container findings keep coming back, how to count findings that have no fix, and five moves to make as the directive's full remediation timelines take effect in December 2026. It builds on our explainer on how BOD 26-04 tiers and clocks work, which covers the tiers themselves.

BOD 26-04 binds federal civilian agencies. If you sell software or services to them, expect the same timelines in your contracts and authorization reviews. Read the directive for the full text.

Where KEV compliance loses time

The four-step answer chain

Every KEV addition starts the same chain of questions, and each step is less certain than the one before:

1. A CVE joins the KEV catalog. This is public and takes no effort to learn.
2. Is it present in the images you ship? You need a current inventory of every package and library in every layer, including base image components and transitive dependencies, resolved to versions. Build files describe what you intended to ship. Layers record what you shipped, and the scan reads the layers, so your SLA scope follows the layers.
3. Is it in something running? An image in a registry is not a production workload, and long-lived workloads drift from the images they were built from.
4. Is that workload publicly exposed? CISA can't supply this. The same image can face the internet in one cluster and stay internal in another.

Accuracy drops at each step, and nothing announces the drop. An inventory that is 80% complete returns an answer that looks exactly like a correct one. Step two is where most teams lose confidence, because it is the step most often assumed rather than checked.

Four patterns behind most of the delay

All four show up in well-resourced, well-run programs:

• Spreadsheet tracking. It works until new entries arrive faster than anyone updates the sheet. After that, a stale record keeps circulating, including in executive reviews, with nothing to show it stopped being true.
• Blanket exposure assumptions. One exposure flag per image gets applied to every environment the image runs in. Exposure drives every deadline, so the deadline becomes a guess, usually an optimistic one.
• Point-in-time scanning. With a weekly scan, every tier assignment can be up to a week old. Against a three-day window, the clock can run out before the next scan starts.
• No line from finding to owner. The finding is detected and the deadline is known, but no name is attached, so it waits in a queue. In the programs RapidFort has seen, this costs the most time.

Three of the four are data-freshness and routing problems. Another scanner won't fix them, because detection was never the bottleneck.

Why container KEV findings keep coming back

Containers add a fifth pattern: recurrence. You close a KEV finding one quarter, and the next quarter it comes back as a new ticket, with the same CVE in the same component of the same image.

The cause is base image composition. Base images ship shells, package managers, build tooling, and transitive libraries that nobody on your team chose. Most of them never execute in production, but they are still in the image, so they are in the scan, your SLA scope, and your attack surface. Every rebuild brings them back, along with any known exploited vulnerabilities they carry. Your team does the work and produces evidence of the work, while exposure stays flat.

You have two options. You can track upstream patches for components your application never uses, at whatever pace their maintainers release them. Or you can remove those components, which eliminates their CVEs from the image. Only removal stops the recurrence; a CVE in a component that isn't present needs no ticket, deferral, or explanation to an auditor.

Removal needs evidence that a component never runs. A Runtime Bill of Materials (RBOM®) records which packages and libraries a workload loads while it runs, so you can see which components are safe to drop. Profile under realistic traffic: a code path that runs once a quarter still counts as used. For the broader practice, see container image optimization article from the Best Practices webinar.

How to count KEV findings with no available fix

Some KEV-listed CVEs on the clock have no upstream patch. The maintainer isn't shipping one, the component is end of life, or the fix exists only in a major version you can't adopt inside the window. These findings still get a tier and a deadline, and vendor silence doesn't pause the clock.

Teams usually account for them in one of two ways, and both distort the result:

• Counting them as breaches penalizes the team for an action nobody could take. Once a metric does that, people start managing the metric instead of the risk.
• Dropping them out of scope is the more serious error. It moves your compliance figure in the flattering direction, and every decision made from that number, including investment decisions, inherits the distortion.

A defensible report answers two separate questions: what is the maximum compliance you can achieve given findings with no fix, and which findings are blocked rather than breached? That figure holds up in front of an auditor or authorizing official. It also leaves two options, and neither depends on the maintainer: replace the component with a maintained equivalent, or remove it where it never executes.

How to run KEV work as a pipeline

Programs that keep pace and programs that fall behind differ in structure more than budget, which is why added headcount rarely closes the gap.

In a checklist model, someone works each KEV addition by hand: reads the update, maps it to assets, files tickets, chases owners, and assembles status for a monthly report. Throughput is capped by attention. That model made sense with one flat clock and a catalog of around 300 entries. It doesn't hold up when tiers re-rank as data changes and the shortest tier comes with forensic triage attached.

In a pipeline model, the catalog is a feed. Findings are scored as soon as the data changes, tiers re-rank when CISA updates a variable, and work arrives routed to an owner with a deadline.

Timing shows the difference most clearly. Scan frequency tells you how quickly you learn that a component is present. Recomputation frequency tells you how quickly you learn that a component you already knew about has moved to a shorter tier. Most of the lost time sits in recomputation, and it needs no new scan. For example, if a CVE you already track is added to KEV on a Monday and your tiers only recalculate with Friday's scan, four days have passed and the three-day window has closed. Keep weekly scans if that's your cadence, and recalculate tiers whenever the data changes.

Systems should handle the mechanical work: computing tiers from the four variables (public exposure, whether exploitation is "automatable," technical impact, and evidence of active exploitation), running the clock, flagging overdue items, rescoring when CISA changes a variable, routing findings, and assembling audit evidence. Done by hand, all of it slips, because people don't sustain that consistency month after month. Four decisions should stay with people:

• Exposure is an assertion about your architecture. A system can propose it, and a person has to own it.
• Forensic triage is an investigation. Deciding whether a system may already be compromised takes context the finding doesn't contain.
• Risk acceptance needs a signature to count as a decision.
• Sequencing 20 findings in one window with capacity for eight is a business call about systems, customers, and consequences.

Use this list when you evaluate tools; ask which of these four decisions the tool claims to make for you.

Five moves for KEV compliance in the next 30 days

The directive's full remediation timelines apply from early December 2026. If you haven't started, put moves one and two first; they set the inputs everything else depends on. None of the five depends on a specific vendor, and each produces something an auditor can check.

Failing closed on exposure will make your urgent queue longer on day one, and that is the right direction for the error to run. Expect move two to take longer than the technical work suggests, because it is a negotiation between security, platform, and application teams.

What audit-ready KEV evidence looks like

An audit rarely asks for a summary figure. It asks about one finding on one date: what tier was it in, what were the four values at the time, when was it due, was the deadline met, and if not, what happened? Audit-ready evidence has four properties:

• Per-finding accountability: every CVE occurrence carries its tier, deadline, status, and the four values that produced the tier, so anyone can reproduce the determination.
• Rescoring history: every tier change is timestamped, so a move from 60 days to three leaves a consistent record.
• Triage records in shared workflows: evidence lives in the systems other teams already use, as well as in the security console.
• Portability: you can export findings, tiers, and status, so your proof doesn't depend on one interface being available on the day someone asks.

A dashboard shows where you stand today. An audit asks where you stood in March, and you need a timestamped record to answer that.

If you change one thing first, measure the time between a KEV addition and a confident answer about your own exposure. It is cheap to measure, few teams track it, and it can use up most of a three-day window no matter how fast you patch. Every other move on this list depends on knowing that number.

Give recurring KEV findings nowhere to live. Start from RapidFort Images, profile your running workloads, and generate an RBOM® to find the components that never execute.