Vulnerability management policies
Vulnerability policies let administrators with Organization RulesAdmin or Organization Administrator roles define a set of criteria that, when triggered, either changes the status of a vulnerability or flags it for review. The criteria that define the policy includes vulnerability rules, severity, application, and route.
Vulnerability policies result in a more accurate view of which vulnerabilities need attention and which are considered remediated and closed. You have the option of setting auto-verification policies and violation policies.
You can set in-app notifications when vulnerabilities violate these policies. Administrators are notified of violations in-app and by email.
Types of Auto-verification policies
Auto-verification policies automatically change the status of a vulnerability that meets specific criteria to Remediated - Auto-verified. These policies are useful when you want a more accurate view of vulnerabilities that need attention instead of relying on manually changing the status of vulnerabilities after they are fixed and verified.
An auto-verification policy can be session-based, route-based, or time-based:
Session-based auto-verification (recommended): A combination of metadata values that you set in the agent configuration file define a session. You control when a session ends by calling a Contrast API at the end of a test run.
You need an automated test suite for this type of auto-verification.
Route-based auto-verification: A combination of metadata values that you set in the agent configuration file define a session. Use this type of auto-verification if you cannot use session-based auto-verification.
You need an automated test suite for this type of auto-verification.
Time-based auto-verification: Use this method of auto-verification if you have high confidence that your application will exercise all routes within a specified time period.
You can use automated or manual testing with this type of auto-verification.
Auto-verification behavior
Contrast marks a vulnerability as Remediated - Auto-Verified if Contrast does not discover it on the same route across two different sessions. If two sessions report the exact same session metadata values, Contrast views the two sessions as a single session.
Depending on the defined values, each agent run could be part of a single session or every agent run could have its own session. If you are integrating Contrast into a CI/CD pipeline, ensure that you send at least one session metadata key-value pair that is unique each time you deploy a new version of the application. For example, configure the agent to send the Commit Hash, Build Number, or Version metadata because these values are likely to change for each application deployment.
When you use route-based auto-verification, Contrast evaluates vulnerabilities associated with the route immediately after the route is exercised. Alternatively, when you use session-based auto-verification, Contrast waits to evaluate all routes exercised during the session until after calling the Session End API.
Contrast closes vulnerabilities only if the vulnerable parameter that the application reads during the observation of an exercised route vulnerability is not reported again. If the route is exercised, but Contrast does not see the particular parameters that are identified in the vulnerability as being a source of tainted data, then the vulnerability remains open.
If a vulnerability that Contrast previously marked as Remediated - Auto-Verified reappears when the same route is exercised, its status changes to Reported. Contrast updates the details in the Activity tab on the vulnerability details page.
If a vulnerability that Contrast previously marked as Remediated - Auto-Verified reappears when the same route is exercised after you disable or delete an auto-verification policy, the vulnerability status changes to Reported. Contrast updates the details in the Activity tab on the vulnerability details page.
Session metadata for session-based and route-based auto-verification
For session-based or route-based vulnerability policies, add session metadata to the agent configuration files:
Providing unique session metadata allows Contrast to create a baseline of findings that lets it verify whether a vulnerability was remediated based on route comparisons.
Using the Test Run session metadata field is a good way to ensure that Contrast is tracking routes and vulnerabilities across an entire test run even if you restart the agent and the application multiple times during the run.
Contrast creates a unique session ID for every unique metadata key-value pair. Using session metadata in this manner combines multiple test runs into a single test session. This action is useful in situations where different code paths on the same route are tested.
Using the Commit Hash, Build Number, or Version metadata is useful because these values are likely to change for each application deployment.
Violation policies
Violation policies trigger a violation notice when a vulnerability matches a set of specific criteria. If triggered, you see the vulnerability in red text in the vulnerabilities list. Use the vulnerabilities filter to view only vulnerabilities with policy violations.
Policy triggers
These trigger types activate a vulnerability policy:
Session-based (recommended): Triggers an auto-verification policy when a vulnerability is seen, or not seen, on a specific route during a session. When you use this trigger, use the Contrast API to end the session. This feature lets you define when a session ends so that you can get immediate results from a test run.
Route-based:Triggers an auto-verification policy when a vulnerability is seen, or not seen, on a specific route. This trigger is available for technologies where Contrast can identify routes.
Time: Triggers a violation or auto-verification policy after a specified number of days.
Environments
For optimal results, configure the vulnerability policies to apply to the environments where you are using test automation. If you are running the same application on multiple servers, ensure that each server is configured for the Development, QA, or Production environment.
Multiple policy actions
If multiple policies affect the same vulnerability, these rules determine how Contrast applies the policies:
Auto-verification policies take precedence over violation policies. For example, if an auto-verification deadline applies first, the vulnerability is closed and never flagged.
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.