Create an automation rule

Learn how to create an automation rule for your repositories.

1. Go to Automations in the left side menu (You can also access automations for a specific repository by clicking the Automate button in the top right corner)

2. Click the +New button, then +New rule

3. Select the repository(s) you want the rule to be applied to

4. Build your if-statement:

   1. Choose criteria for the rule to trigger, e.g. CVSS is at least high (7.0-8.9). Click on AND or OR to add a new criterion. You can select multiple criteria connected by the operators. See below for more information

   2. Choose an action to be executed when the condition is true, e.g. fail pipeline. See below for more information

5. If you don’t want the rule to apply for vulnerabilities that have been marked as unaffected by you or someone on your team, leave the pre-filled checkbox in the bottom right checked

6. Click on Generate rule and review any warnings (if applicable). Make sure that the statement corresponds to what you were looking to achieve with your rule

7. Click on Save

Example of an if-statement

Rule Conditions

Rules can incorporate multiple OR and AND operators. When working with multiple criteria and operators, the following precedents are applied:

• AND conditions inherit previous IF or OR conditions

• OR conditions do not inherit the previous IF or OR condition

Rule Actions

You can select one of the following actions to be performed once a rule is triggered:

• Fail pipeline - if the rule conditions are met, your pipeline fails

• Pipeline warning:

  • GitHub - if the rule conditions are met, your pipeline passes, the pipeline check is set to neutral and a warning is printed

  • GitLab, Bitbucket and Azure DevOps - if the rule conditions are met, your pipeline passes and a warning is printed

• Notification by email - if the rule conditions are met, you receive an email notification

• Notify user groups by email - if the rule conditions are met, all users in a chosen user group receive an email notification

• Mark as unaffected - if the rule conditions are met, the affected vulnerabilities are marked as unaffected

• Flag as vulnerable - if the rule conditions are met, the affected vulnerabilities are marked as vulnerable

• Trigger webhook - if the rule conditions are met, a webhook is sent.

Missing CVSS score

Rules that use the CVSS score as one of the conditions, might not trigger for vulnerabilities that lack a CVSS score. This does not mean that the vulnerability is not severe, but that the data source lacked the CVSS score information. To account for this, you can add the statement:

OR CVSS is missing

Keep in mind that adding the OR statement does not take previous IF or AND statements into consideration.

Production Dependencies

This option is currently supported for Javascript (Yarn, NPM), Nuget, Java (Maven, Gradle), PHP (Composer), Python (requirements.txt), and Go.

You can make your policies/automations only trigger if the related dependency is used in production, to reduce the number of false positives or very low-risk triggers. To set this up, simply add another condition to the rules you want triggered only for non-dev dependencies:

Automation Rule Examples

• Prevent new dependencies with vulnerabilities

  Imagine you have a developer branch called dev where you add new exciting features. Being security-aware, you want to fail the pipeline if a new commit introduces a new vulnerability with a severity of high or more. You also want to be notified of this incident.

  This is how you would go about setting up that rule in our automation engine:

  
• Prevent unknown license families and GPL

  In this scenario, we want to fail the pipelines if we include dependencies with either an unknown license family, or if the dependencies has any of the GPL-2.0 and AGPL-3.0 licenses. We also wish to notify all the administrators for the company account.