Patch by CVE: Automating Vulnerability Remediation Across Enterprise Fleets

Why patch by CVE

Vulnerability management and patch management speak different languages by default. A scanner (Tenable, Qualys, Rapid7, Defender for Endpoint) reports exposure as CVE identifiers; a patch tool traditionally organizes work by product and KB. The gap between them is manual translation — an engineer mapping “CVE-2026-XXXXX, CVSS 9.8, exploited in the wild” to “which patch, which devices, deploy when.”

CVE-driven automation removes that translation step: the CVE identifier from the scanner’s report is directly usable as a filter condition in Hexnode’s patch automation, and the remediation status reports back in CVE terms.

Where CVE data appears in Hexnode

• Patch views: Patches carry their associated CVE identifier(s) and severity as columns alongside KB number, product, and release date.
• Automation conditions: Auto Patch automation exposes the CVE and KB columns as filterable conditions, with comparators (equals, contains, greater/less than for severity values) usable in automation rules.
• Reports: patch reports include CVE and severity fields, exportable for reconciliation against scanner output.

One boundary stated plainly: Hexnode maps CVEs to the patches that remediate them — it is not a vulnerability scanner. Detection of exposure comes from your scanner or from Hexnode’s patch-applicability scan; the CVE filter governs remediation, not discovery.

Recipe 1 — Auto-remediate a named CVE fleet-wide

Situation: security has flagged one specific CVE (from a scanner report, a vendor advisory, or a KEV entry) and wants it closed everywhere, now.

1. Create a new Auto Patch automation by navigating to Automate > New Automation > select the platform (macOS, or Windows) > Patches and Updates > Auto Patch.
2. Add a condition on the CVE column: CVEs Is CVE-2026-XXXXX.
3. Set the deployment action to install immediately, or attach the emergency maintenance window if business hours must still be protected.
4. Scope the target to all devices (or all devices of the affected platform).
5. Enable the automation.

Result: Every device where a catalog patch remediating that CVE is applicable receives the patch on its next evaluation cycle. Devices already patched are untouched; devices where no patch is applicable (unaffected OS build, product not installed) are skipped. Track closure in the patch report filtered by the same CVE.

Verification loop: Re-run the vulnerability scan after the automation completes, or filter the patch report by the CVE identifier — the remediated device count should reconcile with the scanner’s affected-asset count. Where they diverge, see Troubleshooting below.

Recipe 2 — Severity-threshold auto-approval

Situation: the team’s standing policy is “critical vulnerabilities patch automatically; everything else waits for review.”

1. Create an Auto Patch automation.
2. Add a condition on the severity field: severity Is Critical.
3. Optionally add a soak delay — e.g., approve N days after release — so vendor-pulled patches don’t auto-deploy on day zero. This can usually be configured using the Release Date condition, with options like All, Today, Yesterday, Last 7 days, Last 30 days, or Custom.

Result: Every future patch entering the catalog above the threshold is approved and deployed without per-patch review; everything below the threshold accumulates in the normal approval queue. This converts patch review from “evaluate everything” to “evaluate only what the policy doesn’t already answer.”

Pair with staged rollout: A severity-threshold automation can target a pilot group first, with fleet-wide expansion following the phased pattern in the deployment guides — automation decides what qualifies; rings/groups decide who gets it first.

Recipe 3 — KEV-list workflow (CISA Known Exploited Vulnerabilities)

Situation: The organization tracks CISA’s KEV catalog — vulnerabilities confirmed exploited in the wild, with remediation deadlines mandated for U.S. federal agencies under BOD 22-01 and widely adopted as a prioritization baseline elsewhere.

Hexnode does not ingest the KEV feed directly.

1. Pull the current KEV entries relevant to your estate (filter the KEV CSV/JSON by your deployed products).
2. Create an Auto Patch automation with CVE conditions matching those identifiers — CVE Is conditions for each, or CVE contains batches where the automation supports multiple values.
3. Set the deployment timeline to meet the KEV due date, overriding routine maintenance windows if the deadline demands it, under Configure automation rules option. (deadline-class deployment, per Maintenance windows and patch scheduling).
4. On each KEV catalog update (CISA adds entries continually), append the new CVEs to the automation’s conditions.

Result: a standing, auditable automation whose condition list is your KEV remediation policy — the patch report filtered by those CVEs is the evidence artifact for compliance review.

What CVE-driven automation does NOT do

• It does not scan for vulnerability exposure; it maps and remediates. Pair it with a scanner for detection.
• It does not remediate CVEs that have no patch — configuration-mitigated or unpatched vulnerabilities need policy or script remediation outside patch automation.
• It does not act on CVEs affecting products absent from the patch catalog; for missing titles, use the catalog title-request path (see The Hexnode patch catalog).
• A CVE fixed only by a superseded patch resolves through the superseding update — the automation targets the latest applicable patch in the chain (see How Hexnode handles superseded updates).

Troubleshooting

1. The automation ran but the scanner still reports the CVE on some devices.

   Common causes in order: the device hasn’t rescanned since patching (stale scanner data); the patch requires a reboot that hasn’t happened yet (check pending-restart state); the CVE affects multiple products and only some are patched; or the device’s OS build isn’t served by the applicable patch. Reconcile per device against Action History.

2. A severity-threshold rule approved a patch the team wanted held.

   Threshold automations are policy-by-severity, deliberately blind to product. Add an exclusion condition for the product/KB (Editorial note: confirm exclusion support), or run sensitive products under a separate, manual-approval scope.

3. CVE column is empty for some patches.

   Not every patch remediates a CVE — feature updates and non-security fixes carry no CVE. If a known security patch lacks its CVE, the mapping may not have propagated; verify after the next catalog sync and report persistent gaps to support.

4. Multiple CVE conditions aren’t matching as expected.

   Check the automation’s condition logic (AND vs. OR) — CVE lists need OR semantics; AND semantics match only patches remediating every listed CVE simultaneously, which is almost never intended.

Related documentation

• The Hexnode patch catalog: curation and validation pipeline
• Patch delivery architecture
• Maintenance windows and patch scheduling
• Auto Patch automation – Windows, and macOS (general reference)