{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":43798,"path":"security-management/container-vulnerability-response/cvr-exception-management.md","title":"Exception management in Container Vulnerability Response","bundle":null,"doc_type":null,"release":"australia","body":"\n# Exception management in Container Vulnerability Response\n\nWhen 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.\n\nSome 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.\n\n## Life cycle of an exception\n\n-   **Definition of an exception**\n\n    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.\n\n-   **Requesting an exception**\n\n    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.\n\n-   **Approving an exception request**\n\n    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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/add-exception-approver.md) for more information.\n\n\n**Note:**\n\nStarting 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/exception-mgt-approval-rules.md).\n\nOnce an exception request for a CVIT or RT is approved, you can perform the following actions:\n\n-   Reopen\n-   Delete\n-   Update the **Assignment to** or **Assignment groups** fields\n\n-   **Tracking an exception request**\n\n    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.\n\n-   **Expiry of an exception request**\n\n    When an exception request for a particular CVIT or RT expires, the impacted CVIT or RT reverts to its **Open** state.\n\n\nIf 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**.\n\n## Configure approval rules\n\nView and configure approval rules by navigating to **All** > **Container Vulnerability Response** > **Administration** > **Approval rules**. 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.\n\nThe following approval rules are shipped by default:\n\n-   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.\n\n    **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 **All** > **System Properties** 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.\n\n-   Approval for Exception Rules: It does not have configuration but two approval levels.\n-   Approval for False Positives: It has one configuration with one approval level.\n\n**Note:** Starting from v2.5 of Container Vulnerability Response, you can configure the time frames for approving false positives and exceptions, along with email notifications for both the approver and requester after a set number of days. When a request is raised, the container vulnerable item changes to In-Review status and a state change record is created. If the approver doesn't respond within the configured time frame, the container vulnerable item or remediation task reverts to Open status. The previous state is stored in the **backup\\_state** field. For more information, see [Configure approval rules for Exception Management](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/cvr-exception-mgt-approval-rules.md).\n\n-   **[Requesting and approving an exception in Container Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/cvr-request-approve-exception.md)**  \nYou can request to defer the remediation of a container vulnerable item \\(CVIT\\) for a specified period. For example, as a developer, you can request an exception if a patch is not available for a machine. Approvers who have access can approve requests from other users.\n-   **[Working with an exception rule in Container Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/working-with-exception-rule-cvr.md)**  \nYou can request an exception for container vulnerable items \\(CVITs\\) that can't be remediated or deferred immediately. By automating the VI deferral process, you can defer the matching CVITs based on the rule when the system identifies them.\n-   **[Marking and approving a false positive container vulnerability item](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/request-approve-fp-cvr.md)**  \nContainer Vulnerable items \\(CVITs\\) and remediation tasks \\(VULs\\) can be marked as false positives. Approvers with write access can approve such requests from other users.\n\n**Parent Topic:**[Remediating container vulnerabilities](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/remediate-cvr.md)\n\n"}}