Exception management in Container Vulnerability Response
Summarize
Summary of Exception management in Container Vulnerability Response
Exception management in Container Vulnerability Response enables organizations to formally request, review, approve, or reject exceptions when container vulnerable items (CVITs) cannot be remediated according to security policies due to unavailable patches or fixes. By approving an exception, organizations acknowledge the associated risks of deferring remediation for a specified period.
Show less
Exception Lifecycle and Process
- Definition: An exception is a request to delay remediation of a CVIT or remediation task (RT) temporarily.
- Requesting an Exception: Remediation owners can submit exception requests when immediate remediation is not possible.
- Approval: Vulnerability analysts review and risk-assess requests, which can require one or two levels of approval depending on configuration. Without a first-level approver, exceptions cannot be requested.
- Post-Approval Actions: Approved exceptions move CVITs or RTs to a Deferred state, with options to reopen, delete, or update assignments.
- Tracking: Exception request status can be monitored via the State Change Approvals tab on the CVIT or RT record.
- Expiry: When an exception expires, the CVIT or RT reverts to Open status, unless subsequent scans show the vulnerability is fixed, leading to a Closed state with the Fixed substate.
Configuration and Automation
- Approval rules for exceptions and false positives are configurable under All > Container Vulnerability Response > Administration > Approval rules.
- Default approval rules include two levels for exceptions and one level for false positives, with ability to customize levels and approver groups.
- System properties allow specifying approval groups for exception workflows, enabling automated routing of requests.
- Starting with version 2.5, time frames for approvals and email notifications for pending requests can be configured, with automatic state reversion if no response is received in time.
- Automated exception rules can defer remediation of matching CVITs detected by the system, streamlining exception handling.
Additional Capabilities
- Users with appropriate permissions can request and approve exceptions and false positive markings on CVITs and remediation tasks.
- Exception management workflows are enabled by default in Vulnerability Response v15.0 and later; upgrading users can migrate from workflow-based to flow designer-based approval processes.
Practical Benefits for ServiceNow Customers
This capability helps organizations maintain compliance with vulnerability management policies by formally managing unavoidable exceptions while accepting associated risks. It provides a structured and auditable process for deferral approvals, automated tracking, and timely notifications, improving risk governance and operational efficiency in managing container vulnerabilities.
When your organization can't comply with a published vulnerability management or security policy, standard, or guideline, you can request an exception. Exception management entails requesting, reviewing, approving, or rejecting exceptions to an container vulnerable item (CVIT) that cannot be remediated according to the policy.
Some container vulnerabilities (CVIT) might not have an existing patch, fix, or solution. When an exception is approved, it also means that you're accepting a risk because you're acknowledging and agreeing to the consequences of not remediating the vulnerability.
Life cycle of an exception
- Definition of an exception
- An exception is a request to defer the remediation of a CVIT or RT for a specified period. For example, as a remediation owner, you can request an exception if a patch is not available for a machine.
- Requesting an exception
- As the remediation owner, you can ask for an exemption for a CVIT or RT using the exception management process. After the exception approver approves this request, the CVIT or RT moves to a Deferred state.
- Approving an exception request
- CVIT or RTs that can't be remediated immediately are reviewed by vulnerability analysts, assessed for risk, and approved for deferral until they can be remediated. Approving an exception request can be a two-level workflow. If only the first-level approver is present, the exception can be requested and approved. However, if there's no first-level approver, an exception can't be requested. See Add an exception approver for more information.
Starting from Vulnerability Response v15.0, if you are deploying the VR application for the first time, the flow designer for exception management is enabled by default. If you are already using the workflow, you can update to the flow designer. In both cases, you cannot change it back to workflow. To configure approval rules for exception management and false positive, see Configure approval rules for Exception Management.
- Reopen
- Delete
- Update the Assignment to or Assignment groups fields
- Tracking an exception request
- After raising the exception, you can track its status by using the State Change Approvals tab of the CVIT or RT. If an action is taken on an RT, you can't track the status of the individual CVITs in that RT.
- Expiry of an exception request
- When an exception request for a particular CVIT or RT expires, the impacted CVIT or RT reverts to its Open state.
If a single CVIT or all the CVITs in a RT pass in the next scan, then the CVITs and, where applicable, the RT State field changes to Closed with the substate Fixed.
Configure approval rules
View and configure approval rules by navigating to . Request an exception for the CVITs that cannot be remediated or deferred immediately, by identifying the impacted vulnerabilities, configuration items (CIs), or CVITs. Automate the CVIT deferral process. Defer the matching CVITs based on these rules when the system identifies these CVITs.- Approval for Exception Requests: A default configuration with two approval levels is provided in the base system. Whenever there is an exception request on a vulnerable item, the approval request is sent to the users or groups
present in level 1. Once approved by level 1 approvers, it is sent to the level 2 approvers.Note:You can change the default levels and edit as required. Starting from Container Vulnerability Response v2.0.6, you can use the system properties provided in the base system for exception approvals via workflow in the System Properties [sys_properties] table. So, when an exception or false positive request is raised via workflow, it’s sent for approval to the group IDs defined in the system property. Navigate to and select sn_vul_container.container_exception_approver_L1, sn_vul_container.container_exception_approver_L2, or sn_vul_container.container_false_positive_approver_group to change the property value.
- Approval for Exception Rules: It does not have configuration but two approval levels.
- Approval for False Positives: It has one configuration with one approval level.