Before
Analysts searched vulnerability sources, translated product names into inventory terminology, compared versions, and identified affected configuration items by hand. They then traced exposure and service dependencies, grouped remediation work, checked for duplicate SOC incidents, and assembled separate change requests for review.
How it works
- Select recent or requested exploited vulnerabilities and match their products and version ranges against the software inventory.
- Evaluate affected assets, exposure, protections, dependencies, and maintenance context to determine emergency mitigations, virtual patches, or ordered patch waves.
- Submit scoped change requests, associate affected configuration items and services, check for an existing incident, and create a SOC summary when necessary.
Workflow details
- Trigger and selection: The workflow runs daily or on demand for up to three requested CVEs, retrieves vulnerability details and KEV metadata, and distinguishes new findings, unavailable source data, and CVEs that were not found.
- Inventory matching: It compares vulnerable CPE products with the software catalogue, using AI only to match product names and deterministic rules to validate installed versions. Safe versions are separated from installations that fall within the vulnerable range.
- Exposure analysis: For each affected configuration item, the workflow evaluates exposure, device type, upstream firewall protection, SSL-VPN status, maintenance windows, support groups, environments, and dependent services.
- Remediation planning: It creates virtual-patch actions for exposed assets behind IPS-enabled firewalls, SSL-VPN mitigation changes for vulnerable border devices, and patch waves grouped by support group, environment, and maintenance window. Test or development waves can precede production, while directly exposed systems may receive emergency treatment.
- Action and oversight: Each planned change is passed to the change-request process with configuration items and impacted services, without duplicates. The workflow checks for an existing CVE incident, creates one for the SOC when needed, and returns an executive summary showing affected assets, safe versions, changes, and incident status.
What changed
A vulnerability listing is converted into an inventory-backed remediation plan without separate analyst handoffs for product matching, exposure review, dependency gathering, or change assembly. Automated rules determine the proposed remediation path and timing, while change approval remains with the responsible review process.
Work removed
Repeatedly searching CVE and KEV records, mapping CPE names to catalogue aliases, comparing installed versions, identifying affected assets, tracing firewalls and service dependencies, grouping patch work, checking for duplicate incidents, and manually assembling change requests and summaries.
Expected outcome
One traceable action plan is produced per affected CVE, with a conservative estimate of roughly five or more recurring lookup and assembly actions removed for each CVE that affects inventory.
