Vulnerability Response remediation task states

  • Release version: Xanadu
  • Updated August 1, 2024
  • 7 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Vulnerability Response remediation task states

    Vulnerability Response (VR) manages vulnerability remediation through remediation tasks that track vulnerable items (VITs). These tasks evolve through defined states, reflecting progress and integration with change management processes. Third-party integrations import vulnerability detection data, creating or updating VITs, with detection states influencing VIT states.

    Show full answer Show less

    Change requests (CHG) and remediation tasks have synchronized states; as a change request progresses, related remediation tasks update automatically, resolving upon implementation. The remediation task closure is now managed by scanners, with the previous manual approval workflow deprecated since version 23.0.

    Remediation Task States and Actions

    Each remediation task state defines specific actions a ServiceNow user can perform:

    • Open: Initial state. Actions include identifying duplicates, starting investigations, marking false positives, requesting exceptions, resolving, creating or associating change requests, splitting tasks, deferring, or deleting tasks.
    • Under Investigation: Triggered by starting investigation. Users can create security incidents, change requests, or split tasks.
    • Awaiting Implementation: Indicates tasks referred outside VR. Supports creating security incidents, change requests, splitting tasks, deferring, and deletion.
    • Deferred: Initiated by exception requests and under review before approval. Similar actions as Awaiting Implementation with the ability to reopen the task after deferment expires.
    • Resolved: Set when remediation is completed; users can create security incidents, change requests, reopen, or delete tasks. Resolution details are recorded.
    • Closed: Automatically set by the scanner. Users may create security incidents, reopen, or delete tasks. Closure details are documented.

    Important Functional Details

    • Remediation owners can only mark tasks or items as resolved; scanners confirm closure.
    • Administrators can delete multiple manually created VITs to clean up low-risk or obsolete entries.
    • Deferring remediation tasks allows users to postpone remediation with reasons, exceptions, and reopen dates.
    • When VITs reopen, they become open again and are reassessed to link to appropriate remediation tasks without losing history.
    • State, reason, and until fields of remediation tasks and VITs are automatically evaluated and synchronized, including handling of splits and updates.
    • A scheduled job runs every 15 minutes to roll up VIT states and update remediation tasks accordingly, ensuring consistent task state management.

    Practical Benefits for ServiceNow Customers

    This structured approach to remediation task states enables ServiceNow customers to efficiently track and manage vulnerability remediation activities, synchronize them with change management workflows, and automate state transitions to reduce manual effort. The ability to defer tasks, request exceptions, split remediation efforts, and integrate with security incidents supports comprehensive vulnerability management aligned with organizational risk policies.

    Third-party integrations import vulnerable item detection data that create new vulnerability items (VITs) or update existing VITs. Detection states update VIT states in so far as they’re Open or Closed.

    For more information on how a detection's state affects a VIT's state, see the Detections, remediation tasks, and vulnerable item states.

    With Change management for Vulnerability Response, there’s a synchronized relationship between the state fields of the remediation tasks and the state fields of the change requests (CHG) in the Vulnerability Response product. As a change request moves through its life cycle, it also moves the state of any related remediation tasks automatically. After a change request is implemented, the remediation task is automatically resolved. See State synchronization between change requests and remediation tasks for more information.
    Note:
    Starting with v23.0 of Vulnerability Response:
    • the Remediation Task State Approval workflow is deprecated and replaced by flow Remediation Task State Approval in the flow designer.
    • the Close button has been removed for a remediation task and the closure of a remediation task is driven by the scanner.

    The following table lists the remediation task states and the actions that you can perform on a remediation task at the respective state:

    Table 1. Remediation task states
    State Description
    Open State upon creation. From this state you can:
    Show Duplicate VIs
    Identify duplicate VIs reported by multiple scanners in the system. You can mark the duplicate VI as Resolved or Closed. Duplicate entries are only shown when the combination of vulnerabilities is created using Common Vulnerabilities and Exposures (CVE). For more information, see Vulnerability Response remediation task and vulnerable item states.
    Start Investigation
    Assign this remediation task to a person or group to start investigating.
    Mark as false positive
    Mark an item or group as false positive if the scanner reports that a vulnerability exists in the system, but in reality there’s no vulnerability.
    Request exception
    Request an exception, a reopen (Until) date, a reason, and optionally, provide additional information. Defers the remediation of the item or group until the date that an exception is requested.
    Resolve
    Mark as Resolved to move the item or group to a resolved state.
    Create Change
    Create a change request or associate a remediation task to an existing change request. For more information, see Create a change request from a remediation task and Associate a remediation task to an existing change request.
    Split Remediation task
    For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a remediation task. The items that you select are automatically moved to a new remediation task. For more information, see Split a remediation task in the IT Remediation Workspace.
    Defer
    Select the Deferred state, a reopen date, a reason and, optionally, provide addition information. Defers the remediation task state until the reopen date.
    Delete
    Confirm the deletion. Removes the group.
    Under Investigation Triggered by the Start Investigation button. From this state, you can:
    Create a Security Incident
    For more information, see Create a security incident.
    Create Change
    Create a change request or associate a remediation task to an existing change request. For more information, see Create a change request from a remediation task and Associate a remediation task to an existing change request.
    Split Task
    For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a remediation task. The items that you select are automatically moved to a new remediation task. For more information, see Split a remediation task.
    Create a Change Request
    For more information, see Create a change request from a remediation task.
    Awaiting Implementation
    Changes state to Awaiting Implementation. This state indicates that remediation tasks have been referred outside a Vulnerability Response.
    Defer
    Select the Deferred state, a reopen date, a reason and, optionally, provide additional information. Defers the remediation task state until the reopen date.
    Delete
    Confirm the deletion. Removes the remediation task.
    Deferred Triggered by the Request Exception button. As part of the approval workflow, the Deferred state is In Review and can't be closed until approved.

    From this state, you can:

    Create Change
    Create a change request or associate a remediation task to an existing change request. For more information, see Create a change request from a remediation task and Associate a remediation task to an existing change request.
    Split Task
    For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a vulnerability group. The items that you select are automatically moved to a new VG. See Split a remediation task.
    Create a Security Incident
    For more information, see Create a security incident.
    Reopen
    Transition back to an Open state.
    Delete
    Confirm the deletion. Removes the remediation task.

    Deferment information appears under the Close/Defer tab. On the defer date, the group reopens for remediation.
    Awaiting Implementation Triggered by the Awaiting Implementation button. From this state, you can:
    Create a Security Incident
    For more information, see Create a security incident.
    Create Change
    Create a change request or associate a remediation task to an existing change request. For more information, see Create a change request from a remediation task and Associate a remediation task to an existing change request.
    Split Task
    For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a vulnerability group. The items that you select are automatically moved to a new remediation task. For more information, see Split a remediation task.
    Create a Change Request
    For more information, see Create a change request from a remediation task.
    Defer
    Select the Deferred state, a reopen date, a reason and, optionally, provide addition information. Defers the remediation task state until the reopen date.
    Resolve
    Add notes. The state becomes Resolved. Notes appear under the Resolution tab.
    Delete
    Confirm the deletion. Removes the remediation task.
    Resolved Triggered from the Resolve button. From this state you can:
    Create a Security Incident
    For more information, see Create a security incident.
    Create Change
    Create a change request or associate a vulnerability group to an existing change request. For more information, see Create a change request from a remediation task and Associate a remediation task to an existing change request.
    Reopen
    Transition back to an Open state.
    Delete
    Confirm the deletion. Removes the remediation task.

    Notes appear under the Notes tab. Resolution information appears under the Resolution tab.
    Closed Triggered by the scanner. From this state, you can:
    Create a Security Incident
    For more information, see Create a security incident.
    Reopen
    Transition back to an Open state.
    Delete
    Confirm the deletion. Removes the remediation task.

    Closure information appears under the Close/Defer tab.
    • The remediation owner can only mark a vulnerable item or remediation task as resolved. Based on the confirmation from the scanner, this resolved item or remediation task can be marked as Closed or reopened.
    • The Delete button is available for the administrator when there are multiple vulnerable items created manually, and these need to be closed or deleted.
    • If you determine that the items are a low risk, waiting for a change window, or a patch, you can change their remediation task to the Deferred state for a defined amount of time. You can request an exception using the Request Exception option.
      Note:
      When remediation tasks are deferred or closed, you can specify resolutions to further define the reasons for doing so.
    • When a VIT is reopened, either manually or automatically, the following happens:
      • The VIT state changes to Open. The original remediation task state doesn't update.
      • The VIT is reevaluated and put into a new or existing remediation task that is based on the active Remediation Task Rules.

      This preserves its history while enabling further remediation.

    • When a remediation task is created (automatically or manually), or split, then its State, Reason, and Until fields are evaluated. In case of the split action, these fields are evaluated for both the old and new remediation tasks. When a VIT is updated, then the State, Reason, and Until fields of all its associated remediation tasks are evaluated.
      • If all the VITs in a remediation task are deferred and have the same reason, then the remediation task's state changes to Deferred and the VITs' reason is assigned to the remediation task. If the VITs differ in reason, then the remediation task's reason changes to None.
      • The closest Until date of all the VITs is updated in the Until field of the remediation task.
      • If you reopen any VIT, then the state of the remediation task changes to Open.

      This evaluation is done by the Rollup vulnerability item values to vulnerability and group scheduled job, which runs every 15 minutes.