Set auto-verification vulnerability policies

Auto-verification policies for vulnerabilities automatically change the status of a vulnerability that meets specific criteria to Remediated - Auto-verified. These policies can be session-based, route-based or time-based.

When you add a policy, it is turned on, by default. You can turn a policy off or on in the Enabled column in the Auto-verification tab.

Before you begin

Use Contrast version: 3.7.2 and later.
Verify you are using the minimum version of supported agents:
- .NET Framework 20.4.1
- .NET Core 1.0
- Java 3.7.3.14895
- Node.js 2.11.0
- Python 3.4.0
- Ruby 3.8.4
Verify that you are using a supported framework.
If you plan to use session-based or route-based auto-verification, configure unique session metadata (for example, Commit Hash, Build Number, or Version) in the agent configuration files.

Set an auto-verification policy

From the user menu, select Policy management.
Select Vulnerability management.
In Vulnerability policy, select the Auto-verification tab.
Select Add policy.
In Name, enter a name for the policy.
In Vulnerability rules, select one or more severity levels or Assess rules that you want to associate with the policy.
In Applications, select one or more importance levels or applications that you want to associate with the policy.
To find specific levels or applications, select the Applications box and start typing.
In Environments, select one or more server environment where the policy is applied: All environments, Development, QA, or Production.
Under Trigger, select the type of trigger you want to use for the policy (select one or both types of triggers):
- To set a time-based trigger, select Mark any vulnerability as “Verified – Auto-Remediated” after and select the number of days after which the vulnerability policy is marked as auto-verified.
  This trigger is useful if you are confident that vulnerabilities will be fixed and routes will be exercised within the selected time frame. If Contrast finds the vulnerabilities again, it reopens them.
  Tip
  Use time-based auto-verification along with session-based or route-based auto-verification to find situations where routes change drastically from build to build. For example:
  Major code refactoring where you add new routes and remove old routes.
  A route is no longer exercised because it is no longer valid.
- To set a trigger for session-based or route-based auto-verification:
  1. Select Auto-verify based on session or route.
    Session or route-based auto-verification take precedence over a time-based trigger.
  2. Select ONE of these options (you can't use both options at the sane time):
    Session-based auto-verification (recommended): This type of auto-verification policy lets you define when a session ends so that you can get immediate results from a test run, including making pass/fail decisions for your builds. Session-based auto-verification is the preferred method for auto-verification. When you select this option, you end sessions by adding calling the Contrast API at the end of a test run.
    Route-based auto-verification: If you can't use session-based auto-verification, consider using route-based auto-verification. In this case, the session metadata that you configure for your agent define the session.
    Route-based triggers only work for certain technologies with identifiable routes.
Select Save.

Configure a test run for session-based auto-verification

Session-based auto-verification, the recommended auto-verification method, requires you to make calls to the Contrast SBAVRouteSession API at the end of a test run. The following examples show different approaches for closing sessions.

To find your authorization header and API key, log in to the Contrast web interface and under the user menu, select User settings.

End the session defined by a session ID and application ID. Use commands similar to the following example:

curl --location --request POST 'https://<HOST>/Contrast/api/ng/organizations/<ORG-UUID>/agent-sessions/sbav' \
--header 'Authorization: <Your-Auth-Header-Value>' \
--header 'API-Key: <API-KEY>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "sessionId":"0",
    "appId":"5b4960b3-a111-4f2a-bf24-7367be7c8302"
}'

End the session defined by a session ID, the application name, and the application language. Use commands similar to the following example:

curl --location --request POST 'https://<HOST>/Contrast/api/ng/organizations/<ORG-UUID>/agent-sessions/sbav' \
--header 'Authorization: <Your-Auth-Header-Value>' \
--header 'API-Key: <API-KEY>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "sessionId":"0",
    "appName":"FakeRubyApp",
    "appLanguage":"JAVA"
}'

End the session defined by metadata key-value pairs configured for the application and the application ID. Use commands similar to the following example:

curl --location --request POST 'https://<HOST>/Contrast/api/ng/organizations/<ORG-UUID>/agent-sessions/sbav' \
--header 'Authorization: <Your-Auth-Header-Value>' \
--header 'API-Key: <API-KEY>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "appId":"abc",
    "metadata":[
        {"label":"developer", "value":"carlos"},
        {"label":"repo", "value":"ts"}
    ]
}'

End the session defined by these metadata key-value pairs configured for the application with application name and language. Use commands similar to the following example:

curl --location --request POST 'https://<HOST>/Contrast/api/ng/organizations/<ORG-UUID>/agent-sessions/sbav' \
--header 'Authorization: <Your-Auth-Header-Value>' \
--header 'API-Key: <API-KEY>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "appName":"FakeJavaApp",
    "appLanguage":"JAVA",
    "metadata":[
        {"label":"developer", "value":"carlos"},
        {"label":"repo", "value":"ts"}
    ]
}'

Update a vulnerability policy

From the user menu, select Policy management.
Select Vulnerability management.
In Vulnerability policy, select the Auto-verification tab.
Select the policy.
Update the values, as needed.
Select Update.

In this section: