Vulnerability Response remediation task states
Summarize
Summary of Vulnerability Response remediation task states
Vulnerability Response uses remediation tasks (RTs) to manage the lifecycle of vulnerability items (VITs) detected by third-party integrations. These tasks track the investigation, remediation, and closure of vulnerabilities, with states that reflect the current status of the remediation effort. The state of remediation tasks is synchronized with change requests (CHGs) when integrated with Change Management, enabling automatic updates as changes progress through their lifecycle.
Show less
Starting with version 23.0 of Vulnerability Response, the traditional Remediation Task State Approval workflow is replaced by a flow designer flow, and the Close button is removed. Instead, task closure is controlled by the vulnerability scanner.
Remediation Task States and Actions
Remediation tasks move through various states, each allowing specific actions to facilitate vulnerability management:
- Open: Initial state upon creation. Actions include marking duplicates, starting investigation, marking false positives, requesting exceptions (deferrals), resolving, creating or associating change requests, splitting tasks by filtering vulnerable items, deferring remediation, or deleting the task.
- Under Investigation: Triggered by starting investigation. Allows creation of security incidents, change requests, splitting tasks, and related actions.
- Deferred: Set when remediation is postponed via exception requests or deferment. Tasks remain in review until approved. Actions include creating changes, splitting tasks, creating security incidents, reopening, or deletion. Deferral details appear on the Close/Defer tab, and tasks reopen automatically on the deferment expiry date.
- Awaiting Implementation: Indicates remediation tasks referred outside Vulnerability Response, allowing creation of incidents, changes, splitting tasks, deferral, resolution, or deletion.
- Resolved: Manually marked when remediation is complete but awaiting closure. Allows creation of incidents, changes, reopening, or deletion. Resolution notes are recorded.
- Closed: Automatically set by the scanner to mark tasks as completed. Allows creation of incidents, reopening, or deletion. Closure information is recorded.
Key Functional Details
- Only remediation owners can mark tasks or individual vulnerable items as Resolved. The scanner confirms closure or can trigger reopening.
- Administrators can delete tasks when multiple vulnerable items are manually created and need removal.
- Deferring remediation is useful for handling low-risk items or waiting for change windows or patches, with reasons recorded.
- When a VIT reopens, it changes to Open state and is reassigned to a new or existing remediation task based on active remediation rules while preserving history.
- When tasks are created, updated, or split, their State, Reason, and Until (reopen date) fields are evaluated and updated accordingly.
- If all VITs in a task are deferred with the same reason, the task inherits that deferred state and reason; differing reasons reset the task’s reason to None. The earliest deferment date among VITs sets the task’s Until date.
- Reopening any VIT triggers the parent remediation task to return to Open state.
- State synchronization and evaluation are managed by a scheduled job running every 15 minutes, ensuring remediation tasks and their vulnerable items stay current.
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.
- 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:
| State | Description |
|---|---|
| Open | State upon creation. From this state you can:
|
| Under Investigation | Triggered by the Start Investigation button. From this state, you can:
|
| 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:
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:
|
| Resolved | Triggered from the Resolve button. From this state you can:
Notes appear under the Notes tab. Resolution information appears under the Resolution tab. |
| Closed | Triggered by the scanner. From this state, you can:
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.