Migrate from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS

Problem to solve

Right now, if you want to avoid running one particular DS analyzer, you need to remove it from the long string of analyzers and use that to set the DS_DEFAULT_ANALYZERS somewhere in your project's CI template. And, if you do this, it excludes you from future new analyzers. This gotcha is not obvious.

User experience goal

It should be easier for a user to avoid running a particular analyzer without the risk of losing out on getting to use newly added analyzers.

Proposal

We could add a DS_EXCLUDED_ANALYZERS variable which would define the analyzers that the user wants to avoid running.

Proposed Removal in %14.0

Implementation plan

Step 1: add DS_EXCLUDED_ANALYZERS variable

• update Dependency Scanning template to add DS_EXCLUDED_ANALYZERS: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml ¹
• update documentation of DS_EXCLUDED_ANALYZERS variable, indicate DS_DEFAULT_ANALYZERS is deprecated: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-variables

Step 2: to be done after official deprecation (not in this issue):

• update development templates to use DS_EXCLUDED_ANALYZERS: #333582 (closed)
• Remove DS_DEFAULT_ANALYZERS: See #333299 (closed)

Notes:

1. This must be added alongside DS_DEFAULT_ANALYZERS (i.e. not replacing the old variable) so as to not break existing user configurations.

Further details

Only the DS analyzers that are relevant for a project are ran, so this variable can be left blank and only the appropriate analyzers will run.

Limitations

The current proposal would only work with Docker in Docker disabled, which is currently the default and will be the only way to run DS in the near future.

Docker in Docker is no longer supported, so the above is no longer a problem.

Risks

Removing/renaming DS_DEFAULT_ANALYZERS could have unintended consequences. Removing it would break QA is it works right now.

Documentation

Timing

The work should occur in 13.10 but not be default until as close to 14.0 as possible - if these both can coexist at the same time, great!

We'll also probably want to make a backlog item specific to 15.0 for full removal

Release Post

this MUST be announced in 13.9-14.0 per policy

• 13.9
• 13.10
• 13.11 MR
• 13.12 MR
• 14.0 MR

Changelog

• This MUST be announced in 14.0 changelog

Blog post

• unfiltered blog post

Testing

SET could add an end to end test such that the pipeline is checked before and after setting this in CI.

          expect(pipeline).to have_job('dependency_scanning')
# Set EXCLUDED
          expect(pipeline).not_to have_job('dependency_scanning')