Define a job outcome policy

Job outcome policies assign outcomes to Jenkins jobs that use the Contrast plugin through a Pipeline step or post-build step. These policies will mark jobs with outcome statuses (or build results) such as Failure, Unstable, or Success based on criteria about vulnerabilities found in applications.

Organization Administrators can define a job outcome policy in Contrast to gain greater control over policy definition and enforce standardization across Jenkins servers.

To define a job outcome policy:

  1. Under organization settings, select Integrations in the left navigation.

  2. In the Jenkins row item, click Add job outcome policy. If this is the first time to connect to Jenkins, click Connect.

  3. Select the applications to which the policy should apply. You can identify applications by their name, tag, or importance level.

  4. Under Vulnerability properties, define a limit for the total number of vulnerabilities across all rules (All Rules) that may exist for each application specified before the policy is violated and a job outcome is assigned (for example, Failure). Use "0" to trigger a policy violation if the application has at least one vulnerability.

    You can define a limit to the total number of vulnerabilities allowed for each Severity or each Rule type for each of the applications specified. For example, you can define a limit of "2" for the number of vulnerabilities from the High severity level allowed, and also define a limit of "0" for the number of XML External Entity Injection (XXE) vulnerabilities allowed.

    If no vulnerability limit is specified for a rule or severity ("-" value), then any number of vulnerabilities of that rule or severity are allowed.


    If you specify a limit X for All Rules in addition to a limit Y for a specific severity S, the number of vulnerabilities with severity S will not be counted towards X. Similarly, if you specify a limit Z for a rule type R, the number of vulnerabilities of rule type R will not count towards Y if the rule type R is of severity S.

    In this example, the number of vulnerabilities allowed for XXE (0) will not be counted toward the number of vulnerabilities allowed for severity High (2) since XXE is a High severity vulnerability.

  5. Select Vulnerability statuses to include in the policy. Statuses are determined by Contrast and include "open" statuses, such as Reported, Confirmed, Suspicious, and "closed" statuses such as Remediated, Fixed, Not a problem, Remediated - Auto Verified.


    We recommend that only "open" statuses are selected, such as Reported, Confirmed, and Suspicious, so that Jenkins jobs don't fail or turn unstable due to vulnerabilities developers have already remediated.

  6. Under Vulnerability first seen, include in the policy violation criteria only vulnerabilities that were found during a particular time range, bounded by the From and Until parameters. Available From options include Last 7 days, Last 30 days, Last 6 months, and Application onboarding. Available Until options include Last 7 days, Last 14 days, Last 30 days, and The Contrast step runs in Jenkins.


    To incentivize developers to remediate vulnerabilities within a time period (for example, a week), define the policy so that only vulnerabilities found more than 7 days ago would be considered for policy violation. To do this, set From to Application onboarding and Until to Last 7 days.

  7. Under Policy outcome, select the outcome of the policy. Contrast marks jobs that match the selected criteria as Failure, Unstable, or Success.

Later, you can disable the policy by unchecking the box at the bottom to pause Contrast from enforcing policies on Jenkins jobs without having to delete the individual policy.