Considering the complexity around Vulnerability Management process and its impact on the security posture, there is an ongoing debate about how best to leverage a SOAR platform to track and report on the status of specific vulnerabilities.

This would enable organisations to utilize SOAR platform across both of their Security and VM organizations which would provide long term benefits in term of reduced overhead for management and also improved opportunities for integration.


The primary use case for SOAR remains the management of cybersecurity incidents which are usually correlated within the corresponding SIEM technology and selectively escalated to the SOAR platform. The aim of this lesson is to outline, at a high level, the set of functionalities that could allow a SOAR platform to accommodate the Vulnerability Management requirements.

Scenarios / Use Cases

  1. Create Incidents with a particular group of Vulnerability Findings.

Functional Requirements

  1. SOAR should allow ingestion of Vulnerability Scan Reports, such as from Qualys, with corresponding Findings.
  2. SOAR should be able to classify all Findings by common resolution and group them under one incident per resolution.
  3. Relevant Business Group, responsible for the resolution of the vulnerability, should be attached to the incident.
  4. All such Incidents created within the SOAR platform should support multiple, up to 1000s of, associated Findings to an Incident.
  5. Each Finding will have its own lifecycle including:
    • addition of Finding to an incident
    • reflect status updates against each Finding
    • move Findings between incidents persistently and
    • close Finding upon successful completion of resolution
  6. If a Finding has not been resolved before the next Vulnerability Scan Report is ingested within the SOAR platform, the same Finding should be identified to already exist and not logged again as a new Finding. In which case, the count of that Finding is incremented by 1.
  7. The lifecycle of the SOAR Incident will be governed by the lifecycle of the Findings associated to it. This means an incident cannot be closed unless all Findings within that incident have been successfully marked as resolved.
  8. Findings should be able to be transferred between incidents. This may be required due to the initially misassociation of Findings and/or to support better management of resolution.
  9. All Findings will have additional information associated to them which can be displayed in an overlay.
  10. A Finding can be muted, which means it would not be marked as resolved but can allow the incident to be closed. An unmute Function should also exist.
  11. All incident and corresponding Findings data should be available for Dashboards and Metrics within the SOAR platform.

Non-Functional Requirements

  1. Platform should support up to a Million Findings per month. Average size of each Finding is usually estimated to be 2kB.
  2. Retain historical Incident data for up to a defined period of time to allow for reporting on metrics.