There is a synchronized relationship between the State fields of vulnerability groups
(VG) and the State fields of 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 vulnerability
groups automatically.
Overview
State synchronization is enabled by a system property (sn_vul.cr_state_synch) by default in
your instance when you download the Vulnerability Response product from the ServiceNow Store for the Madrid v9.0, NY v9.0, and Orlando family releases.
When state synchronization is enabled, the CHG State field changes the VG State field
automatically in the following cases:
When a new CHG is created for a VG, if it is not in Awaiting
Implementation , the VG state moves forward to Awaiting
Implementation .
When an existing CHG is associated to a VG, if it is not in Awaiting
Implementation , the VG state moves forward to Awaiting
Implementation .
After the tasks on a CHG are completed (Implemented ), and the
CHG is moved to the Review state, the VG moves forward to
Resolved .
For more information and examples of state synchronization, see the following sections.
Note: You can still manually move CHGs and VGs through the states of their
life cycles on their respective records with state synchronization enabled, but when the system
registers that a CHG has changed its state, or you add a CHG or remove it from a VG, state
synchronization potentially can override your manual intervention. However, change requests
states do not automatically move the VG from the Closed or
Deferred states.
Forward state synchronization
The following image illustrates how CHG states automatically move VG states in a forward life
cycle, that is, from Open to Resolved .
You can create new change requests for any vulnerability group in a state other than
Closed . State synchronization automatically moves the VG
bi-directionally through the Open , Under
Investigation , Awaiting Implementation , and
Resolved states. This movement is based on certain values of the
state field on the change request. State synchronization between the change request and the
vulnerability group is invoked automatically unless the check box (Add CIs to
CR ) is displayed on a form and you choose to clear the check box.
The VG does not move forward to Resolved when a CHG is in its
open states. Any CHG in states prior to Review in its life cycle
such as, New , Assess ,
Authorize , Scheduled or
Implement as shown in the preceding figure are considered open
states for the CHG. Open states do not move the state field on the VG, because investigations or
tasks on the CHG are not completed. State synchronization is invoked when a CHG is created for,
or associated to, the VG, or the state of an existing relationship changes on the CHG. The
completed CHG states are Review and successfully
Closed . When a CHG is closed successfully, its closed codes are:
Successful , or Successful with
issues , in which case the VG moves forward to
Resolved .
Backward state synchronization
As a CHG is processed during its life cycle, it may be canceled at some point. In this case,
if the CHG is Cancelled , or Closed
(with a close code of Unsuccessful ), the VG automatically moves
back to Under Investigation . The VG moves back to
Under Investigation , because there is no active plan to remediate
the vulnerability.
If a VG is in a Resolved state, and you create a new CHG or
associate it to an existing CHG in one of the initial open states, the VG automatically
transitions back to Awaiting Implementation . The VG moves back to
this state, because more work is now assigned to the CHG.
VGs with more than one CHG
If a VG in
Awaiting Implementation has more than one CHG
associated with it, state synchronization is based on the status of the CHG in the earliest
state of its life cycle. For example, a VG has four CHGs associated with it, CHG1, CHG2, CHG3,
and CHG4 as shown in the following table.
CHG number
CHG state
1
Implement
2
Canceled
3
Closed (close code of Unsuccessful )
4
Closed (close code Successful )
State synchronization between the CHG and the VG in this case is based on CHG1, which is in
the earliest state of the four CHGs, (Implement ). In this case, the
VG remains in Awaiting Implementation .
In another example, if a VG is in the Resolved state and has an
existing CHG that has been implemented and is in the Review state,
and a new CHG is created, the VG moves back from Resolved to
Awaiting Implementation . State synchronization is based on the CHG
in the New state, which is the CHG in the earliest state.
CHG number
CHG state
1
Review
2
New
Additionally, when VGs have more than one CHG, the state of the VG transitions automatically
in the following cases:
When a CHG moves forward to Review , if all other CHGs
associated with the VG are in Review or
Closed states (with a successful close code), the VG
automatically transitions to Resolved . Any other related CHGs
that are canceled or closed unsuccessfully are ignored.
When a CHG moves to Cancelled or
Closed (close code of
Unsuccessful ), if all other CHGs associated with the VG are in the
same state, then the VG automatically transitions back to Under
Investigation .
For more information about vulnerability group states and what you can do in each state, see
Vulnerability Response group and vulnerable item states .
