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 CORE's NG SAST can compare the results of its analyses against your build rules to determine if the build should fail.

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:

source:
branch: master
scan: 274 # provide either branch or scan, not both
build_rules:
- id: build-rule-identifier
finding_types:
- vuln
- secret
severity:
- moderate
- critical
type:
- SQL Injection
- Sensitive Data Leak
owasp_category:
- a1-injection
threshold: 10
- id: another-build-rule
severity:
- info
threshold: 100

You can include multiple build rules in the file.

Parameters

The following sections describe the parameters accepted by the different parts of the shiftleft.yml file.

All build rule parameters are optional.

By default, build rules check all findings in the latest scan of an application. Use the following parameters to specify other scans:

  • --branch to check all findings in the latest scan in a specific branch, or
  • source in your shiftleft.yml config file (or --source) and --target when using sl check-analysis to check only new findings in the target scan compared to the source scan. You can also use the value previous to compare the latest scan in a branch with the previous scan in the same branch. For example:
source:
scan: previous

source

ParametersDescription
branchName of the branch to use as the source
scanID of the scan to use as the source

Please provide either the branch name or the scan ID; do not submit both.

build_rules

The following are the parameters accepted under the build_rules section.

ParametersDescription
idA string identifier of your choice for the rule
finding_typesThe specific type of finding for which the specific build rule should be applied. Accepted values: vuln, secret, insight. If you omit this parameter, ShiftLeft defaults to returning only vulnerabilities.
severityThe severity levels for which you want to filter. Accepted values: critical, moderate, info
typeThe types of vulnerabilities for which you want to filter (e.g., SQL Injection or Sensitive Data Leak)
owasp_categoryThe OWASP categories of vulnerabilities for which you want to filter (e.g., a1-injection)
thresholdThe number of vulnerabilities found that would lead to a failed build. Default is 0, so any vulnerability identified would lead to a build failure

Vulnerability Types

The following is a list of accepted values for the type parameter:

  • Cookie Injection
  • Deserialization
  • Directory Traversal
  • File Write
  • Insecure Cookie
  • LDAP Injection
  • Mail Injection
  • Mass Assignment
  • NoSQL Injection
  • Open Redirect
  • Remote Code Execution
  • Sensitive Data Leak
  • Session Injection
  • SQL Injection
  • TLS checks are disabled
  • Usage of insecure API
  • Weak Hash
  • Weak Random
  • XML Injection
  • XPath Injection
  • XSS
  • XXE

OWASP Categories

The following is a list of possible values that you provide for the owasp_category parameter:

  • a1-injection
  • a2-broken-authentication
  • a3-sensitive-data-exposure
  • a4-xxe
  • a5-broken-access-control
  • a6-misconfiguration
  • a6-security-misconfiguration
  • a7-cross-site-scripting
  • a7-xss
  • a8-deserialization