Vulnerability Response
One defect, three records
Vulnerability Response converts scanner output into remediation work. Third-party scanners (Qualys, Tenable, Rapid7) are pulled on a schedule by integrations that write test results; the platform then maintains three distinct records, and questions test whether you know which is which.
- Vulnerability - the defect definition (CVE-style), imported from the scanner or a vulnerability source.
- Vulnerable Item - one vulnerability paired with one configuration item, i.e. "this host has this flaw". De-duplication matters: the same finding imported twice should not create two vulnerable items.
- Remediation Task - the assigned unit of work IT actually closes, created manually or by group rules.
Group rules bundle vulnerable items into vulnerability groups (by CI, by vulnerability, by assignment group, by business service) and can auto-generate remediation tasks. Exceptions handle findings you will not fix now - false positive, risk accepted, remediation deferred - normally requiring approval and an expiry date, after which the item returns to normal tracking.
Traps
- Closing a remediation task does not by itself remediate the vulnerable item; confirmation comes from a later scan or an explicit state change.
- Deleting records to "clean up" is always wrong; use states, exceptions, or decommissioning.
- Confusing Configuration Compliance (policy/benchmark checks) with Vulnerability Response (scanner findings).
- Forgetting that assignment rules and CI ownership - not the scanner - determine who receives the task.
Worked example
A critical CVE appears on 400 servers. Group by vulnerability and business service, create a small set of remediation tasks per service owner, and raise time-boxed exceptions for the few hosts that cannot be patched this quarter.
Rule of thumb: vulnerability = what, vulnerable item = where, remediation task = who and when.