Remediation tasks and vulnerable item states
Summarize
Summary of Remediation Tasks and Vulnerable Item States
This guide outlines how remediation tasks interact with vulnerable item states within ServiceNow, detailing the precedence of states and the effects on vulnerable items. Understanding these interactions is crucial for effective vulnerability management and task tracking.
Show less
Key Features
- State Precedence: The state precedence for remediation tasks is defined as: Closed > Deferred > Resolved > In Review > Awaiting Implementation > Under Investigation > Open.
- Group State Synchronization: When multiple vulnerable items are linked to a remediation task without individual alterations, they share the task's state.
- Deferral Tracking: Starting with version 16.5, you can track how often vulnerable items or remediation tasks are deferred using the scheduled job 'set deferral counts'.
- Closed/Fixed State Handling: Vulnerable items in Closed/Fixed state retain their status regardless of changes to the remediation task state.
- Assignment Management: If both assignment fields in a remediation task are empty, the task remains in the Resolved state even if the state of vulnerable items changes.
Key Outcomes
By understanding the relationship between remediation tasks and vulnerable item states, customers can effectively manage vulnerability remediation, ensure accurate tracking of task statuses, and maintain clarity on item assignments. This leads to better prioritization and resolution of vulnerabilities, enhancing overall security management processes.
Remediation tasks and vulnerable items states can affect each other. Most of the time, a remediation task state updates the vulnerable item state, with the highest precedence task state used to update the vulnerable items in the group.
The state precedence is as follows.
- When a group of vulnerable items are in one remediation task and aren't altered at an individual level, they have the same state as their remediation task.
- When the remediation task goes from the Open state to Awaiting Implementation, all the VIs in the remediation task move to the Awaiting Implementation state.
- When the remediation task is deferred, the VI is likewise deferred. Starting with version 16.5, you can track the number of times that a vulnerable item, application vulnerable item, container vulnerable item, or a remediation task is deferred. The scheduled job, set deferral counts, runs daily to post counts for the records that are deferred more than once in the Deferral count column in the Multiple deferrals modules for VR, AVR, and CVR. All counts for VIs that are associated with a remediation task are collected and posted if a remediation task is deferred more than one time.
- Vulnerable items updated only by remediation tasks
- Items match the state of the remediation task, if they haven't been updated individually,
with these exceptions:
- If the remediation task state changes to Closed, and its resolution to Canceled or Fixed with Exception, the item is not affected and takes on the state of any other remediation task that contains it. If the vulnerable item is in no other remediation task, it reverts to the Open state.
- If the vulnerable item state is Closed/Fixed (updated by a scan or import), then when the remediation task changes its state, the vulnerable item remains in the Closed/Fixed state. This condition is true no matter what state the remediation task is in.
- Vulnerable items in states set individually
- Vulnerable items, in a state updated on the item, such as those items closed or deferred
individually, don't match the state of the remediation task automatically. Instead, it
compares its state to all associated groups to find the state with the highest precedence to
apply.Note:The Closed/Fixed state is a special case. For the vulnerable items that are set to the Closed/Fixed state, if all vulnerable items within a remediation task are set to Closed/Fixed — such as when a scanner finds that all the vulnerabilities have been remediated — the remediation task is automatically marked as Closed/Fixed.
- Remediation tasks contain empty assignment fields
- If the state of the VIs in a remediation task changes from Resolved to Open, the state of
the remediation task is also updated from Resolved to Under Investigation.
However, if both the Assigned to and Assignment group fields in the remediation task are empty, the remediation task remains in the Resolved state and does not move to Under Investigation.
- Assignment group for vulnerable items is not always updated when their remediation task is updated
- If the assignment group for a VI in Open state is updated manually, it is not updated again when the assignment group for its remediation task is updated. This information is not overwritten because the assignment group for the VI has been updated intentionally, and might be a part of another remediation task.