Exploited vulnerabilities: verify exposure and remediation
A vulnerability’s inclusion in a known-exploited catalog is evidence about that vulnerability, not proof that every company using the named vendor has been compromised. Research must first match the affected product and conditions to actual deployed assets, then determine what remediation evidence exists for those assets.
The deliverable is a vulnerability-to-asset matrix and a dated remediation ledger. It uses defensive operating evidence supplied by an authorised owner; it does not perform scans, demonstrate exploitation or direct access to a company’s systems. The illustrative vulnerability and all asset counts below are fictional, not a claim about an issuer or an actual CVE.
Locate the official data and its limits
CISA’s official kev-data repository explains its canonical source, file formats and update relationship in the README. It supplies an official mirror and revision history. Preserve the retrieved file version and date rather than treating a changing repository page as an immutable snapshot.
The repository’s official JSON schema defines fields including catalogVersion, dateReleased, cveID, dateAdded, requiredAction and dueDate. Those fields describe the public catalog. Their existence does not establish an enterprise’s inventory completeness, patch installation or successful verification.
The README read on October 25, 2026 refers to a newer directive framework. This worksheet does not reproduce an older directive’s deadlines as current requirements or interpret directive text that was not obtained. A public dueDate should not be imposed on every private company without the applicable directive, contract or other obligation establishing its scope.
Build the applicability matrix first
For a real case, connect the CVE identifier to the vendor’s affected-product and version information, relevant configuration conditions and the company’s actual deployment records. A product name match alone is insufficient. Preserve the advisory version and its date because applicability information can change.
The asset record should identify the relevant component, deployed build, configuration evidence, active location or service, owner and last observation date. Procurement records show something was purchased, not necessarily that it is still deployed. A public technology-stack reference may support a lead for research but does not establish a complete affected population.
Keep applicability, exposure, remediation and evidence of intrusion as separate columns. An affected version can exist without evidence of exploitation at that company. Conversely, a catalog entry absent from a search does not prove the company’s systems are free of other vulnerabilities.
Rebuild the baseline cohort
Assume one hundred inventoried nodes have actually been checked for a fictional vulnerability X using the stated affected conditions. At the baseline date, forty are confirmed affected. The other sixty are confirmed not affected by X on the recorded evidence; that says nothing about their overall security.
At a later cutoff, twenty of the original forty have been upgraded and independently rechecked against the defined condition. Ten remain on the affected version but have a documented isolation control. Ten remain unresolved, with the next action or its evidence pending. The forty is a fixed baseline cohort, not a claim that the twenty repaired nodes still run the old version.
| Baseline affected cohort at later cutoff | Nodes | Treatment |
|---|---|---|
| Upgrade and verification complete | 20 | Verified repaired for X within scope |
| Isolation control documented | 10 | Mitigated separately, not called patched |
| Unresolved | 10 | Remediation not established |
| Original affected cohort | 40 | Fixed denominator for progress |
Verified repair is 20 ÷ 40 = 50%. Documented isolation represents another 25%, and unresolved another 25%. Calling 75% patched would combine two different outcomes. Dividing twenty by one hundred gives 20% of the inventoried population, a different question from repair progress among confirmed affected assets.
Verify the transition rather than the purchase order
For each repaired node, obtain the approved change record, actual installed build and a subsequent observation establishing the relevant condition no longer applies. A downloaded package, scheduled maintenance window or closed ticket without deployment evidence does not independently establish repair.
Verification must match the component and time. A host operating-system version may not establish the version of an embedded application library. A scan result from before the change cannot verify the change. Record the method and scope without publishing sensitive system details or claiming the observation proves every other security control effective.
For the ten isolated nodes, preserve what control was implemented, what exposure it addresses, who verified it and when it expires or needs review. This worksheet does not assume isolation eliminates every path or removes the vulnerable code. The mitigation state should remain distinct until the applicable remediation and its verification are established.
Test a different denominator: incomplete inventory
Suppose the initial one hundred nodes are later found to be only the well-documented portion of a 120-node estate. The extra twenty have unknown applicability. They do not become safe simply because the reported affected count remains forty.
Preserve the baseline progress of twenty repaired out of forty, and separately show inventory coverage of one hundred out of 120 with twenty unresolved applicability records. Combining them into a single green percentage hides the information gap. If later review finds five more affected nodes, open a new cohort or explicitly reconcile the expanded denominator rather than silently revise the historical 50%.
The same asset can appear in several vulnerability rows. Summing affected-node counts across CVEs can count it repeatedly. For an estate-wide total, use unique asset identities and state the deduplication rule. Keep vulnerability-instance counts separate where that is the intended workload measure.
Separate catalog evidence from breach evidence
Known exploitation in the wider environment supports prioritisation, not a statement that this company suffered an incident. A vendor-product match and a KEV date cannot establish intrusion date, data theft, outage or financial loss at an issuer. Those require separate, appropriately sourced incident evidence.
Likewise, the schema’s public flags are descriptions of catalog information, not findings from the company’s own systems. Do not convert a field name into a claim that the company completed forensic work or that ransomware was present there. The record must identify whose observation a field represents.
This distinction also limits a negative claim: no disclosed breach is not proof of no compromise. State the scope of reviewed public records and leave unobserved outcomes unknown. The matrix is useful because it names the missing evidence instead of creating certainty from a catalog lookup.
Apply the remediation verification sheet
| Field | Obtain | Check |
|---|---|---|
| Catalog | Official snapshot and entry | CVE, revision and dateAdded preserved |
| Applicability | Vendor advisory and deployment evidence | Version, configuration and component match |
| Inventory | Owner-supplied asset register | Coverage and unique identities |
| Action | Approved change or mitigation record | Planned, deployed and temporary states separate |
| Verification | Dated post-change observation | Same node and condition, method recorded |
| Incident evidence | Relevant company or authoritative record | Catalog status not relabelled a company breach |
When inventory, vendor and public records disagree, first compare observation dates, builds, embedded components and scope. Do not choose whichever version makes the remediation rate highest. Preserve the unresolved applicability or verification state until a matching record resolves it.
If internal records are unavailable, a public-equity researcher may be able to establish only a vendor dependency and a question for follow-up. Do not invent node counts or infer a precise repair rate from broad corporate language. The fictional forty-node example illustrates a required evidence structure, not a substitute for private records.
Update after catalog revisions, vendor applicability changes, new inventory, verified changes or evidence of an actual incident. Keep baseline and current cohorts connected so progress remains reproducible. The conclusion should say which known affected assets were verified repaired, which are temporarily mitigated and which coverage or outcomes remain unknown.
Reconcile an expanded affected population
Continue the inventory boundary case: of twenty additional nodes, five are confirmed affected and fifteen remain unassessed. The expanded affected cohort is forty-five, comprising twenty verified repaired, ten mitigated and fifteen unresolved. The whole estate closes at forty-five affected-cohort identities, sixty confirmed not affected by X and fifteen unknown, totalling 120.
Verified repair is now 20 ÷ 45, approximately 44.44%, for the expanded cohort. The earlier 50% remains correct for the original forty-node cohort at its stated cutoff. Neither percentage should overwrite the other without the population bridge.
Verification also has an observation date. A later rollback or redeployment can change the current state even after a prior repair was validly observed. Preserve the old verification and the new evidence rather than claim the original record was necessarily false or that the asset stays repaired forever.
FAQ
Does a KEV listing prove a company was breached?
No. It concerns exploitation of the vulnerability, while company-specific applicability and incident evidence are separate.
Can isolated nodes be included in the patched percentage?
Not in this worksheet. Mitigation and verified repair are separate states.