Before
Analysts likely exported scanner findings, translated vulnerability identifiers into CVE context, and repeatedly checked the asset database to identify the responsible team. They then reconciled existing findings, calculated deadlines, grouped work manually, and copied the resulting details into remediation incidents.
How it works
- Read confirmed scanner detections, map them to vulnerability context, and enrich them with asset, exposure, service, and ownership records.
- Apply fixed rules to determine lifecycle state, remediation priority, deadline, and responsible team, then create or update the finding register.
- Group eligible findings by team and CVE and request one remediation incident per group, reusing matching open work where applicable.
Workflow details
- Detection intake: The workflow reads confirmed scanner detections at severity 3 or higher, maps vulnerability identifiers to CVEs and corrective guidance, and excludes lower-severity or unconfirmed findings.
- Risk and ownership context: It enriches findings with EPSS likelihood, CVSS and exploitation status, then matches each scanned host to the asset database by name, FQDN, or IP address. It also evaluates service dependencies, exposure, support groups, and group managers; assets that cannot be matched are routed to the security operations team.
- Deterministic planning: Fixed rules calculate priority from exposure, exploitation status, severity, likelihood, and service criticality. The workflow assigns remediation deadlines of 7, 15, 30, or 90 days and routes system, firmware, and application findings to the appropriate responsible team.
- Register maintenance: New findings are added to the vulnerability register while known findings are updated with their latest state, priority, deadline, ownership, and detection timestamps. Fixed findings can close, returned findings can reopen, and active exceptions remain excluded while valid.
- Grouped remediation: Eligible findings are grouped by remediation team and CVE, with affected configuration items, services, evidence, and corrective guidance included in one incident per group. Existing open work is reused where the same correlation key already exists, and the run returns a summary with finding counts and created ticket totals.
What changed
Each scan now produces an updated, ownership-aware vulnerability register and grouped remediation work automatically. Priority, deadlines, lifecycle changes, unmatched assets, affected services, and duplicate-ticket checks are handled before the remediation handoff, while teams receive consolidated incidents instead of one ticket per host.
Work removed
Reviewing scanner findings one by one, mapping identifiers to CVEs, matching hosts to assets, checking service dependencies and ownership, calculating priorities and deadlines, updating register entries, grouping findings by team and CVE, and copying evidence into remediation incidents.
Expected outcome
The documented demonstration consolidated 29 vulnerability findings into 10 team-by-CVE tickets; actual volumes will vary with each scan.
