Exception rule example for Application Vulnerability Response
- UpdatedJul 31, 2025
- 1 minute read
- Zurich
- Application Vulnerability Response
An example rule based on a known vulnerability for an exception rule.
| Field | Description |
|---|---|
| Name | A unique name to help you identify its purpose and locate the rule easily, for example, Veracode-1 cwe-22 exception. |
| State | Read-only: Draft |
| Valid from | Date this rule is active to defer AVIs. |
| Execution order | Unique order for each exception rule. A lower value precedes a higher one. |
| Valid to | Date on which the remediation task stops accepting new VIs. |
| Deferred until | Date until when the remediation tasks and AVIs are deferred. On this date, the AVUL is closed, all the AVIs move out of the task and are reopened. Group rules are reapplied to these AVIs. |
| Reason | Reason to create this exception rule. Select one from the list, for example, Fix Unavailable. |
| Assignment group | Group assigned for tracking the deferred VIs, for example, APP Sec Manager. |
| Additional information | Additional information that the requester wants to provide to the approver. This information is populated in the description field of the remediation task. In this example, Defer AVIs with the vulnerability – Veracode-1-22. |
| Condition | Filter conditions to specify which AVIs match this rule. For this example, Vulnerability is Veracode-1-22. |
| Execute on existing data | Option that enables you to run this rule on existing data the first time that this rule is run. If you leave this option deactivated, your rule runs daily by the scheduled job Associate existing AVIs with Auto Exception Rule starting with new data. If you enable the Execute on existing data option, a scheduled job runs one time on the existing data on the Valid from date. |