Skip to main content

How to work with build rules in your repo

Build rules v1 has been deprecated. Please use build rules v2; see migrations for additional information.

You can include a configuration file named shiftleft.yml within your application's repository that contains build rules. Qwiet preZero 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:
      - medium
      - 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, Qwiet 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

Qwiet also accepts the following tags for OWASP 2021 categories:

  • a01-2021-broken-access-control
  • a02-2021-cryptographic-failures
  • a03-2021-injection
  • a04-2021-insecure-design
  • a05-2021-security-misconfiguration
  • a06-2021-vulnerable-and-outdated-components
  • a07-2021-identification-and-authentication-failures
  • a08-2021-software-and-data-integrity-failures
  • a09-2021-security-logging-and-monitoring-failures
  • a10-2021-server-side-request-forgery-(ssrf)