Plan and Refine: Dependency Scanning jobs should not be triggered for files in DS_EXCLUDED_PATHS

Summary

The Dependency Scanning vendored template has detection logic to determine which analyzer(s) should be used to scrutinize changes on branches. Usually this is done by looking at file extensions or particular files.

While this works, there are conditions where the only matches exist in directories which are explicitly excluded by the DS_EXCLUDED_PATHS environment variable. We need to find a way to respect that choice.

See #218419 (closed) for similar issue affecting SAST_DEFAULT_ANALYZERS, in the context of SAST.

Steps to reproduce

Include dependency files for a package manager different from the rest of the repository being scrutinized, and exclude these dependency files using DS_EXCLUDED_PATHS. There should be no scanning job for the newly introduce dependency files since they are excluded, but there is.

Possible Workarounds

  • Update DS_DEFAULT_ANALYZERS to not include the analyzers which are spuriously triggered.
  • Modify detection rules to take into account DS_DEFAULT_ANALYZERS variable.

Example Project

See a branch of the ruby-bundler test project where the CI config sets DS_DEFAULT_ANALYZERS to exclude Gemfile.lock. The pipeline for this branch features all Dependency Scanning jobs even though the Security tab reports no vulnerability findings.

What is the current bug behavior?

Analyzers are invoked against files we're trying to avoid through configuration.

What is the expected correct behavior?

The DS_DEFAULT_ANALYZERS variable is respected as part of the detection logic.

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Edited by Nicole Schwartz