Skip to content
GitLab
Next

Improve extensibility of SAST, Dependency Scanning template rules

Problem to solve

NOTE: Allow Secure templates to run in Merge Request ... (#217668 - closed) was delivered in %15.5 release and support for Merge Request Pipelines has been added to all sectionsec CI .latest templates. See the release post announcement for more. This issue now focuses on a more advanced usecase if complex CI configurations

With our switch to using rules syntax for our Secure templates, there is some added complexity in how users are able to override existing jobs. We should explore methods of making this easier.

When SAST and Dependency Scanning (DS) used to run in a single job, users could easily override the job definition of sast and dependency_scanning, and change the conditions on which the scanning jobs are triggered. With the removal of the Docker-in-Docker (DinD) orchestrator and non-DinD becoming the default, users now have to override multiple scanning jobs. This is more complex, and they cannot easily predict the names of the jobs they need to override. Also, it makes for extra maintenance task if GitLab introduces new SAST or DS scanners compatible with their projects, resulting in new scanning jobs they have to override.

Intended users

User experience goal

Easier rules configuration for secure jobs

Proposals

Current state: override each job individually 

bandit-sast:
  rules:
    - when: never

node-js-scan-sast:
  rules:
    - changes:
      - app/assets

This is the recommended way via our docs but won't scale well to a large number of languages detected: https://docs.gitlab.com/ee/user/application_security/#transitioning-your-onlyexcept-syntax-to-rules

Proposal A: Base extendable rules

Users cannot easily extend rules for all jobs without naming individual ones; i.e. brakeman-sast

Individual jobs extend .sast-analyzer but the child jobs override rules, which prevents setting globals. One approach to consider

bandit-sast:
  extends: .sast-analyzer
  image:
    name: "$SAST_ANALYZER_IMAGE_PREFIX/bandit:$SAST_ANALYZER_IMAGE_TAG"
  rules:
    - <<:.sast-analyzer.rules
    - if: $SAST_DISABLED || $SAST_DISABLE_DIND == 'false'
      when: never
    - if: $CI_COMMIT_BRANCH &&
          $GITLAB_FEATURES =~ /\bsast\b/ &&
          $SAST_DEFAULT_ANALYZERS =~ /brakeman/
      exists:
        - '**/*.rb'

This way any updates to .sast-analyzer will correctly be propagated and dried

*NOTE: *can we expand a YAML anchor in this way?

Proposal B: self-referential YAML anchors

we document a way to reference the default ruleset and expand it:

# user's job override to run on triggered pipelines
bandit-sast:
  rules:
    - <<:bandit-sast.rules
    - if: $CI_COMMIT_SOURCE == 'trigger'

Proposal C: Preset configuration variables

Add ENV variables for common expectations and document well. This adds lots of template complexity:

variables:
  RUN_SAST_ON_TRIGGERS: 1

include:
  template: SAST.gitlab-ci.yml

Proposal D: Preset configuration rulesets

Add rule presets for common expectations and document well. This adds lots of template complexity:

include:
  template: SAST.gitlab-ci.yml

brakeman-sast:
  rules:
    - <<:brakeman-sast.rules
    - <<:sast-rules-run-on-triggers

eslint-sast:
  rules:
    - <<:sast-rules-run-on-tags

Proposal E: A + B

See #218444 (comment 347001480)

Proposal F: Merged yaml blocks

Based on #266173 (closed)

See #218444 (comment 495386664)

Proposal Reviewed

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Lucas Charles