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 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
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.
User experience goal
Easier rules configuration for secure jobs
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.
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
Proposal F: Merged yaml blocks
Based on #266173 (closed)
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.