How to Work with Build Rules in Your Code Repository

Within your application's repository, you can include a configuration file named shiftleft.yml that contains build rules. ShiftLeft can compare the results of its analyses against your build rules to determine if the build should fail or not.

With this file, you can:

  • Specify different build rules for each of your applications/repositories

  • Keep your build rules under version control

  • Edit your build rules without needing a separate tool that's outside your development workflow

The shiftleft.yml File

By default, the location of your configuration file in your repository should be ./shiftleft.yml. The file should be formatted as follows:

build_rules:
- id: build-rule-identifier
severity:
- SEVERITY_MEDIUM_IMPACT
- SEVERITY_HIGH_IMPACT
type:
- SQL Injection
- Sensitive Data Leak
owasp_category:
- a1-injection
threshold: 10
- id: another-build-rule
severity:
- SEVERITY_LOW_IMPACT
threshold: 100

You can include multiple build rules in the file.

The following is a list of parameters you can include in your build rules. All build rule parameters are optional.

Parameters

Description

id

A string identifier for your rule

severity

The severity levels for which you want to filter. Accepted values: SEVERITY_LOW_IMPACT, SEVERITY_MEDIUM_IMPACT, SEVERITY_HIGH_IMPACT

type

The types of vulnerabilities for which you want to filter

owasp_category

The OWASP categories of vulnerabilities for which you want to filter

threshold

The number of vulnerabilities found that would lead to a failed build. Default is 0, so any vulnerability identified would lead to a build failure