Skip to content

Secret detection vulnerabilities not filtering due to incorrect report type

Summary

When filtering by Tool, Secret Detection, the results are empty even though the unfiltered results contain secret detection entries.

Steps to reproduce

  1. Open https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report/
  2. There are lots of Secret Detection entries
  3. Filter Tool by Secret Detection
  4. No entries

Example Project

https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report/

What is the current bug behavior?

Filtered list is empty

What is the expected correct behavior?

Entries that show Tool as "secret detection" appear in the results when I apply the corresponding filter.

Relevant logs and/or screenshots

image

image

image

image

Output of checks

This bug happens on GitLab.com.

Analysis (internal link; expires 2022-05) from @dftian:

despite the vulnerability list showing secret detection results, the vulnerability scanners doesn't have an entry for secret detection

for the vulnerabilities showing up as SECRET_DETECTION, they have reportType SECRET_DETECTION, but looking at the actual scanner type, it's Gitleaks, which is a SAST scanner

In short, it looks like the problem is that the reportType of the vulnerability doesn't match its scanner reportType. This looks like a data consistency issue.

And from @twoodham:

How is Gitleaks identified to be a SAST scanner?

Analysis from @mallocke:

  • The vuln report does not load the list of scanner ids via graphql, they are populated on data attributes when the page is loaded calling ProjectsHelper#project_security_dashboard_config and VulnerabilityScanners::ListService.
  • The report_type is populated on each scanner by selecting the first vulnerability attributed to the scanner on the project. This is the heart of the problem we are seeing on gitlab-org/gitlab. The first vulnerability we have stored for the gitleaks scanner (scanner_id: 703) is type SAST rather than Secret Detection.
  • When filtering by Tool -> SAST, the frontend does not filter all vulnerabilities with report_type = SAST. Instead, it filters vulnerabilities by scanner_id, using all the scanners with report_type: 'SAST'. This explains why we see Secret Detection when filtering for SAST, because our Secret Detection scanner is misidentified as SAST.

image

  • When filtering by Tool -> Secret Detection, because the initial list of scanners on page load has none with report_type: 'Secret Detection', the frontend sends scanner_id: null in the graphql query for vulnerabilities. This is why the Secret Detection filter returns no results.

image

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

Edited by Malcolm Locke