The score should know when a control actually works
Two things go wrong every day inside a vulnerability queue, in opposite directions. First, a finding is scored as if nothing stands in front of it, and the team spends a shift patching a bug that a segmentation rule and a WAF signature have already been silently blocking for months. Second, a finding is quietly deprioritized because a control exists on paper, and nobody has ever run the technique against it to see whether the control does the job. The second is the more dangerous, and it is the more common. Both come from the same missing input. The score does not know whether the defenses in front of the vulnerability actually stop the technique it enables.
That input has a name. Defense efficacy is the difference between a control existing and a control demonstrably stopping the class of attack a finding enables, measured against the real environment, at a timestamped moment. The rest of this piece argues for treating efficacy as a first-class scoring input, with an expiry date and a governance rule.
What the prior art already covers
The word efficacy is not new to security. PCI DSS has defined compensating controls for two decades as a control that meets the intent of a requirement when the specified one is not feasible, which is efficacy as a policy artifact. CVSS environmental metrics permit a modified score that takes local mitigations into account, and almost nobody populates them at scale, which is the honest version of "the standard already supports it". MITRE ATT&CK coverage mapping is the established way to express which techniques a given control set is supposed to stop, and open source tooling like Atomic Red Team and MITRE Caldera has let teams exercise those techniques against their own environment for years.
That practice now has a market category. On March 24, 2026 Gartner published the Adversarial Exposure Validation Market Guide, which consolidated breach and attack simulation, automated pentesting, and red-team automation under a single label. The vendors named include SafeBreach, AttackIQ, Cymulate, Picus, Pentera, and Horizon3, and their job is to produce evidence that a given control blocks a given technique in a given environment on a given day. Separately, NIST LEV in CSWP 41 (May 2025) added a probability that a vulnerability has already been exploited in the wild, computed from the EPSS time series. LEV is a property of the CVE, not of the defense standing in front of the finding, and it does not substitute for efficacy.
Where the seam actually is
The seam is the wiring. Validation runs happen; a Picus or AttackIQ campaign fires an ATT&CK technique against a segment of the environment and reports a pass or a fail, and the result almost never reaches the prioritization queue as an input. The queue keeps sorting by CVSS, or by CVSS with an EPSS multiplier, and a finding sitting behind a validated block scores identically to one with nothing in front of it. The Gartner guide itself concedes the gap, predicting that only 30 percent of organizations will link AEV results to automated remediation or orchestration workflows by 2029.
The inverse error is worse. Teams downgrade findings because a control exists on paper, without ever running the technique against it. Picus's 2026 comparison of scoring versus validation found CVSS flagged 63 percent of findings as critical while validation showed only 9 to 10 percent were reproducibly exploitable in the environment. The distance between those two numbers is where the queue is either burning effort or hiding real exposure.
What counts as efficacy evidence
If efficacy is going in as a score input, the class of thing that counts as evidence has to be narrow enough to keep out wishful thinking. Every item on the list is a produced artifact with a timestamp:
- A BAS or AEV campaign result that fires the ATT&CK technique the finding enables against the segment the vulnerable asset lives in, and reports blocked.
- The SIEM record for a detection that fired against a payload from the same class the finding enables, in a test run whose timestamp the SIEM will testify to.
- A segmentation probe from an emulated attacker origin that is dropped at the network layer for the vulnerable port on the vulnerable host.
- The layer-7 block record for a WAF rule exercised against the actual payload shape the finding accepts, not merely a log entry saying the rule exists.
The pattern across all four is the same. Efficacy is proven by an artifact, produced by running the exercise, recorded with a timestamp, and tied to an owning system. A ticket saying the team has a WAF does not count, and neither does a cell in a spreadsheet naming a control, or an answer during a compliance interview.
Freshness, and the case for a half-life
The single hardest problem with efficacy as a scoring input is that it decays. Firewall rules change on a Wednesday afternoon, and a control that blocked a technique yesterday allows it today. Detection rules get retired for producing too many false positives, and the ATT&CK coverage the SOC believes it has drifts silently from the coverage it actually has. Segmentation topologies pick up a temporary demo rule and nobody remembers to remove it.
Efficacy needs an expiry. A workable default is a fourteen-day half-life for network and identity-layer evidence, seven days for a WAF rule tied to a payload class under active attacker iteration, and thirty days for a mature detection rule stable for a quarter. The specific numbers matter less than the shape. Evidence weight decays smoothly toward zero as time passes and stops counting at all when it falls below a floor; when it does, the finding pops back up in the queue as if the evidence had never existed.
The SANS State of Detection Engineering 2026 reports that across 307 practitioners, only 18 percent of organizations said they stay ahead of or keep pace with the threat landscape, and more than 70 percent of teams sit at detection maturity level 0 or 1. Efficacy evidence that decays is not a hypothetical failure mode; most teams cannot currently produce it fresh at all.
How efficacy interacts with the SLA clock
Efficacy is not a license to close a finding. Closure invites the next audit and the next reviewer to ask why the vulnerable component is still installed. Efficacy is a license to move the finding across SLA bands, one step, with a receipt.
In practice the rule holds this shape. A validated block moves a finding from ACT to ATTEND, or from ATTEND to WATCH, and never to CLOSED. Closure still requires the vulnerable component to be actually patched or removed. What efficacy buys is a slower SLA clock and a smaller working queue. The finding stays visible at its lower band, and the moment the evidence ages past its half-life floor, it returns to its original band and starts consuming clock again.
Verizon's 2026 DBIR reported that only 26 percent of KEV entries were fully remediated across 13,000 organizations. Some of the other 74 percent is genuinely unfixed, and some is mitigated by controls nobody can prove work. The band rule gives that second group a place to sit that is neither a fake close nor a permanent red row.
The rule that keeps downgrades honest
Every efficacy-based downgrade carries three fields, and the queue refuses to accept the downgrade without them. First, a pointer to the artifact that proves the control worked (a BAS run ID, a SIEM alert ID, a scan job ID). Second, a timestamp on that artifact, from which the half-life clock runs. Third, an owning identity from the IAM system for the control being credited, so that when the evidence ages out or the control changes hands there is a human to notify.
The mechanism is old. It is architecture decision record discipline applied to a place it has not usually lived, where every downgrade is a decision, every decision has an author, a date, and evidence, and the queue is the place the record lives.
A worked example
Consider a CVSS 9.8 remote code execution finding on an internally hosted web application, present in three environments in the fleet. The first environment places the application behind a WAF whose signature was tested this morning against the exact payload class the finding accepts, and the request was blocked at layer 7. In the second, the same WAF is in place, but its signature was last exercised nine months ago against a synthetic payload, and the release notes since then rewrote the request parser. The third has no WAF at all, and the remediation ticket carries a note about adding rate limiting eventually.
Under CVSS-only scoring, all three sort identically at the top of the queue. Under CVSS with efficacy as an input, only the first is downgraded, and only to ATTEND, with the fourteen-day half-life clock running from this morning. The other two stay at ACT. When the fourteenth day passes and no new evidence has arrived for the first instance, it returns to ACT, and the queue prints the reason next to it.
Where CVEasy fits
The rules above are portable, and the point of writing them out is that your team can adopt them against your own environment without buying another vendor. CVEasy AI's local-first CTEM reads exactly this kind of validation evidence from a BAS run into the same working queue that carries the CVE list, and TRIS is the score that composes efficacy, environmental context, and exploitation probability into one ordering. The rest is discipline.