Vulnerability management policy
Either policy can be set to be triggered based on time or route.
For Assess users, an Organization Administrator can set vulnerability policy to require status change approval based on vulnerability severity, or set the policy so that vulnerabilities are closed automatically.
You can set in-app notifications when vulnerabilities violate these policies. Administrators are notified of violations in-app and by email.
Note
You can set vulnerability policies and review pending changes, if you are an Organization RulesAdmin with RulesAdmin permissions for the target application. You must be an Organization Administrator to require vulnerability approval.
There are two types of vulnerability policy:
Auto-verification policies automatically change the status of a vulnerability to Remediated - Auto-verified. Hover over the status, or select the vulnerability name, then select the Activity tab for more information.
Violation policies mark a vulnerability as being in violation of a policy. When this is triggered, you will see a Policy violation notice on the thermometer on the vulnerabilities section of the dashboard.
Set vulnerability policy
Administrators can define requirements for vulnerability policy based on any vulnerability rule, severity, application(s) and route which should comply.
To create a new policy:
Under policy management, select Vulnerability management.
In the grid, select the Auto-verification or Violation tab, and then Add policy.
In the panel that opens, enter:
Name (required)
Vulnerability rules: Select individual rules, all rules, or rules for vulnerabilities of a particular severity.
Applications: Select individual applications, all applications, or applications affected by vulnerabilities of a particular severity.
Environment: Select all environments, or just development, test or production.
To add a time-based trigger, select the box next to Auto-verify any existing vulnerability after: and enter a time limit, to ad a time based trigger.
Route-based triggers only work for certain technologies with identifiable routes. If this is available, you can also select a route-based trigger.
Note
When using a policy with a route-based trigger, it is recommended to also use define a time-based trigger to account for those vulnerabilities which have been remediated in such a way that cannot be associated back to the original finding in Contrast. Typically, these cases only arise when the code was deleted, and therefore cannot be re-exercised, or redefined such that it occurs on a different route.
Select Save.
Important
If multiple policies affect the same vulnerability, the following rules determine Contrast's course of action:
Between two time-based triggers, the action with the closest deadline applies first. For example, if a violation deadline applies first, the vulnerability is flagged and then auto-verified when the later deadline applies.
Auto-verification policies take precedence over violation policies. For example, if an auto-verification deadline applies first, the vulnerability is closed and never flagged.
Note
If Contrast rediscovers a legitimate vulnerability that was auto-verified, Contrast will reopen the vulnerability as usual.