Improve extensibility of SAST, Dependency Scanning template rules

Problem to solve

With our switch to using rules syntax for our Secure template, and the removal of the Docker-in-Docker orchestrator for SAST and Dependency Scanning, 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
#   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