# Getting started with the Policy Engine

Now that you have gotten acquainted with the UI of the tool it’s time to start looking into creating rules.

In order to efficiently prevent vulnerabilities from entering your codebase you need to set up rules in our Policy Engine. The rules can be enforced in your pipelines, failing them or showing warnings, or set to notify relevant people, minimizing the amount of vulnerabilities brought into your codebase.

# Short demo

For a brief overview of the tool, check out out demo video.

# Accessing the Policy Engine

You can access the Policy Engine under "Manage" select "Repositories & Commits". This brings you to the Data Management View - an overview of all repositories and commits. In this view you can also see how many rules are currently configured for the different repositories.

Data Management View

Select a repository which you want to create a rule for, in this case we choose antlr4 as an example. We have not previously configured any policy rules for this repository, hence it will be quite empty. To add a new policy rule, click the plus icon on the right.

Add new policy rule

# Creating your first rule

You now find yourself inside the Policy Engine where you will be creating the rules.

New rule

To get started, add an if-statement. Here, you get multiple options to chose from, based on what you want to be a trigger. In this case, we want to create a rule that triggers if the CVSS score of a vulnerability is ranked as high:

Add if statement Add equality Add comparison

You can modify the condition by using and/or operators like this.

Add and operator

If this example, we have created a rule that triggers if dependency is new AND CVSS is high. Next, we want to add the action to execute when the condition is true. There are multiple options including

  • Failing pipeline -- Fails your pipeline if the rule conditions are met.
  • Pipeline warning
    • GitHub -- Pipeline check is set to neutral if the rule conditions are met and a warning is printed. The pipeline passes.
    • GitLab, Bitbucket and Azure Devops -- Pipeline passes but a warning is printed.
  • Notification by email
  • Mark as unaffected -- Vulnerabilities that meet the conditions are marked as unaffected in the Debricked tool.
  • Flag as vulnerable -- Vulnerabilities that meet the conditions are flagged as vulnerable in the Debricked tool.

In this example, we want to fail the pipeline if the condition is true.

Add trigger

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 checkbox in the bottom right checked:

Ignore unaffected vulnerabilities

Once you have configured your rule it’s time to generate it. Clicking the button (see above) will create a written statement below the rule maker:

Generated rule

Make sure that the statement corresponds to what you were looking to achieve with your rule. There might be changes that need to be made to fulfill the purpose. For example, when creating a rule such as above, where any vulnerabilities with CVSS high will fail your pipeline, but vulnerabilities that lack a cvss score. Once you are happy with the statement it’s time to hit the save button. Please note that saving your rule will make it apply immediately. Once you have saved your rule, it will appear in the "Data Management" view for the selected repository.

Congratulations, you have created your first rule 😃

# CVSS score is missing

The rule we just created will 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. In this example we therefore also want to add the statement:

AND dependency is new

to keep the rule from applying to existing dependencies when CVSS is missing. See condition precedents for more on this.

# Condition precedents

Rules can incorporate multiple OR and AND conditions. When using multiple conditions, the following precedents are applied:

  • AND conditions inherit previous if or OR condition
  • OR conditions do not inherit the previous if or OR condition

This means that creating a rule where a new dependency contains a vulnerability where:

  • CVSS is at least high AND
  • DebAI is at least 70

can be done with 3 rows, compared to a rule where a new dependency contains:

  • a vulnerability where CVSS is at least high OR
  • DebAI is at least 70 requires 4 rows.

Precedence example 1

If we try to construct the second rule using only 3 rows the rule will check for vulnerabilities where DebAI is at least low amongst existing dependencies.

Precedence example 2

# Editing a rule

If you wish to edit a rule, click the three dots on the right hand side of the rule and select "edit rule".

Edit rule

You’ll now be able to add or remove one or multiple conditions and actions. To enable the changes, press "Generate rule" and "Save".

# Disabling a rule

To disable a rule, simply drag the button to the left.

Disabling rule

# Deleting a rule

To permanently delete a rule, click the three dots on the right hand side of the rule and select "delete rule".

Delete rule