7 minute read
Every vulnerability decision rests on facts: the EPSS score, KEV status, exposure, and who owns the system. If nobody watches those facts, a deferred finding stays deferred after the risk has changed.
Key takeaways
A team defers a vulnerability for a reason: the server is internal, no one has exploited the CVE, and the code never calls the vulnerable function. Each part of that reason can stop being true without anyone touching the finding:
Under CISA's BOD 26-04 deadline table, the same CVE on the same server can move from "fix on the next upgrade" to three days, without any change to the vulnerability itself:
| When | What changed | BOD 26-04 deadline |
|---|---|---|
| January | Internal only, not in KEV, not automatable, total control | Deferred to the next system upgrade |
| March | A firewall change exposes the server to the internet | 14 days |
| April | CISA adds the CVE to the KEV catalog | 3 days and forensic triage |
If the team checked the CVE in January and never again, the finding still says "deferred" in April.
Scanners and vulnerability management tools refresh what they know about the CVE: the CVSS score, the EPSS score, the KEV flag. The decision about the finding sits somewhere else, in a ticket comment, a risk acceptance form, or a spreadsheet of exceptions. The tool can show a new KEV flag on a finding the team closed as accepted, and nobody looks at the closed finding again.
Many tools re-check a risk acceptance only when its expiry date passes. The reason behind the acceptance can stop holding months before that date.
"Deferred" is not enough. Write down why: not exposed, not in KEV, EPSS below your threshold, vulnerable function not called, owned by the payments team.
"Not exposed" becomes a check against your external asset inventory. "Not in KEV" becomes a check against the KEV feed. "EPSS below 0.1" becomes a check against the daily EPSS file.
CISA aims to update the KEV catalog within 24 hours of confirming exploitation, and FIRST publishes EPSS scores daily. Exposure and code change whenever your engineers ship.
Send the finding back with what changed and when. The person who picks it up should not have to investigate it again from the start.
An expiry date is a backstop. The acceptance should come back as soon as the reason stops holding.
Bugs in code your team writes never get a CVE, so there is no EPSS score or KEV entry to watch. The facts that change are all in your environment: whether the code is exposed, whether a new feature made the bug reachable, what data the system holds, and which team owns it.
For how to rank these findings in the first place, read vulnerability prioritization beyond CVSS.
aisy keeps each decision your team makes, with the reasons behind it, and checks those reasons as your company changes. Until a reason stops holding, nobody has to look at the finding again. When one does, the finding comes back with what changed.
Whenever a fact behind a decision changes, not on a fixed calendar. EPSS scores update every day, CISA aims to add new KEV entries within 24 hours, and exposure changes whenever someone changes a firewall rule or a load balancer. Check those sources daily and re-open only the decisions they affect.
Re-open the decision. A KEV listing means attackers have exploited the vulnerability or tried to, and under BOD 26-04 it shortens the federal deadline, in the worst cases to three days with a forensic triage.
No. Re-scoring every finding makes the team look again at decisions whose facts did not change. Record the facts each decision rests on, and re-open only the decisions where one of those facts changed.
A risk acceptance rests on reasons, such as "not reachable from the internet" or "a compensating control blocks it." If a reason stops holding before the expiry date, the acceptance no longer covers the risk and someone should review it.
Yes. Pick the EPSS threshold your team acts on, and re-open a deferred CVE when its score crosses it. Scores can jump when exploit code becomes public.
Bugs in your own code have no EPSS score or KEV entry, so the facts to watch are in your environment: whether the code is exposed, whether a code change made the bug reachable, what data the system holds, and who owns it.
Bring a recurring problem from your security backlog. We’ll look at what your team already knows, what it keeps re-checking, and how to get ahead of it.
Shlomie Liberow · Founder, aisy · shlomie@aisy.ai
