Vulnerability scanners are famous for one failure mode: they find too much. A static scan of a workload's disk can turn up hundreds of flagged issues, most of which are real in the catalog sense and irrelevant in practice — the vulnerable package is never loaded, the affected path is never reached, the workload isn't exposed to anything that could trigger it. Alert fatigue isn't a discipline problem; it's a math problem created by tools that report potential issues without confirming actual ones.

The grant US12095806B1, "Cybersecurity vulnerability validation techniques utilizing runtime data, static analysis and dynamic inspection" (assigned to Wiz), is aimed squarely at that math problem. It pairs static analysis with runtime evidence and network reachability to validate findings before treating them as urgent — and then orders its response by whether the issue was actually confirmed.

"A system and method for validating cybersecurity issues utilizing runtime data is disclosed."— U.S. Patent No. 12,095,806 source

The method braids three sources of evidence. According to the independent claim, the system first inspects a workload deployed in a computing environment "for a cybersecurity issue using at least a static analysis technique" — the conventional catalog-style scan. Then it "deploy[s] a sensor on the workload, the sensor configured to collect runtime data from the workload." Static analysis says a problem could exist; the sensor's runtime data is what tells you whether it actually manifests in the running system. The two together are the difference between "this package has a known CVE" and "this vulnerable code is loaded and active right now."

The third source is exposure. The claim continues: the system "determin[es] reachability properties of the workload," "generat[es] a network path between an external network and the workload," and "initiat[es] active inspection of the network path to determine if the workload is a reachable workload." This is the question that most changes a vulnerability's real severity — can anything outside actually get to it? A critical flaw on a workload with no path from the outside is a very different risk from the same flaw on an internet-reachable one, and the patent makes reachability an actively tested property rather than an assumption.

Where the design becomes a triage engine is in how it branches on the result. The claim specifies "initiating a first mitigation action with a first priority... in response to validating the cybersecurity issue from the collected runtime data," and "initiating a second mitigation action with a second priority, which is lower than the first priority, in response to failing to validate the cybersecurity issue from the collected runtime data and determining that the workload is not a reachable workload." Confirmed-and-reachable gets the high-priority response; could-not-be-confirmed-and-not-reachable gets a deliberately lower one. The priority isn't a static CVSS number copied from a database — it's assigned from this workload's own runtime and reachability evidence. A dependent claim adds a third tier: the first mitigation action can be initiated "with a third priority, higher than the first priority, in response to determining that the workload is a reachable workload," so a validated issue on a reachable workload is escalated above a validated issue on one that isn't.

The patent is concrete about both the evidence the sensor gathers and the actions available. The sensor can be configured to collect "an artifact, an event, a datalink layer communication, a permission, a list of applications loaded in memory, a list of libraries loaded in memory, and a combination thereof" — note the loaded-in-memory lists, which directly answer whether vulnerable code is actually in use rather than merely present on disk. The mitigation actions span "generating an alert, revoking a permission, revoking access to a workload, revoking access from a workload, sandboxing a workload, installing a software patch, uninstalling a software application, updating a priority of an alert, and any combination thereof." That last one — "updating a priority of an alert" — is the validation loop made explicit: the system's response to a finding can simply be to re-rank it, which is exactly what alert-fatigue relief requires. Another claim adds a disk-based inspection path: the system can "generat[e] an inspectable disk based on a disk of the workload" and inspect it "for a cybersecurity object" that indicates the issue, a side-channel way to examine a workload's state without disturbing the running workload.

The defensive value is prioritization grounded in reality. Static analysis is the wide net that finds everything; runtime data is the filter that tells you what's real; reachability is the multiplier that tells you what's urgent. By requiring runtime validation and active reachability testing before assigning the highest priority — and by tiering the response across reachable, validated, and unconfirmed cases — the system is built to push the genuinely exploitable issues to the top and let the theoretical ones settle. The goal is not to scan more; it's to turn a flat list of catalog findings into a ranked list of confirmed, reachable risks.

The dependency to respect is the sensor and the inspection plumbing themselves: the validation is only as trustworthy as the runtime data the sensor collects and the reachability the active inspection actually exercises, and a workload that hides its true behavior from the sensor could be mis-ranked downward. But that is the right place to spend trust. The alternative — treating every static finding as equally urgent — is the status quo that produces the alert fatigue this approach is designed to end.