Skip to content

Vulnerability findings dismissed without any attribution

Summary

Some Secret Detection and Dependency Scanning findings have been dismissed without any information on this action.
We need to know when a finding has been dismissed and by who.

Steps to reproduce

  1. Clone this project: https://gitlab.com/gitlab-examples/security/security-reports
  2. Run a pipeline against any branch. Verify that the vulnerability report shows the "Monitor vulnerabilities in your project" message. This confirms that there are no vulnerabilities for the project.
  3. Go to the pipeline details page, click on the security tab, then dismiss any finding. Behind the scenes, this will create a vulnerability for the finding and mark it as "not on master".
  4. Verify that the vulnerability report now shows the table, but with the "your filters produced no results" message. This confirms that the vulnerability was created, but isn't shown because it's not on master.
  5. Run a pipeline against the master branch. This will now populate the vulnerability report, and mark the vulnerability created in step 3 as "on master".
  6. Find the dismissed vulnerability in the vulnerability report and click on it. Confirm that it's dismissed, but dismissed_by_id and dismissed_at are null.

You can follow this video up to when it mentions the fix MR branch. On the current master, dismissed_by_id and dismissed_at will be null, unlike in the video:

Repro steps

Example Project

API output of above first vuln:

{
  "id": 78903978,
  "title": "AWS Access Token detected; please remove and revoke it if this is a leak.",
  "description": null,
  "state": "dismissed",
  "severity": "critical",
  "confidence": "unknown",
  "report_type": "secret_detection",
  "project": {
    "id": 278964,
    "description": "GitLab is an open source end-to-end software development platform with built-in version control, issue tracking, code review, CI/CD, and more. Self-host GitLab on your own servers, in a container, or on a cloud provider.",
    "name": "GitLab",
    "name_with_namespace": "GitLab.org / GitLab",
    "path": "gitlab",
    "path_with_namespace": "gitlab-org/gitlab",
    "created_at": "2015-05-20T10:47:11.949Z"
  },
  "finding": {
    "id": 1399337762,
    "created_at": "2023-03-27T18:01:00.646Z",
    "updated_at": "2023-04-03T12:19:22.771Z",
    "severity": "critical",
    "confidence": "unknown",
    "report_type": "secret_detection",
    "project_id": 278964,
    "scanner_id": 703,
    "primary_identifier_id": 2910,
    "project_fingerprint": "12464f804d5feafe40a7213dd377ec37be897ec8",
    "location_fingerprint": "f07ab14161b4b42c6b2c926e9e9f0fc0f328c119",
    "uuid": "c66c1634-34c0-5d19-9ff6-f5843cecca61",
    "name": "AWS Access Token detected; please remove and revoke it if this is a leak.",
    "metadata_version": "14.0.4",
    "raw_metadata": "{\"id\":\"c76d4a897e74a793b1da4e2a422d1bc1380c5809fdac43f942a6e26123bf57ed\",\"category\":\"secret_detection\",\"name\":\"AWS Access Token\",\"message\":\"AWS Access Token detected; please remove and revoke it if this is a leak.\",\"description\":\"AWS Access Token\",\"cve\":\"ee/spec/work
ers/scan_security_report_secrets_worker_spec.rb:1a5d44a2dca19669d72edf4c4f1c27c4c1ca4b4408fbb17f6ce4ad452d78ddb3:AWS\",\"severity\":\"Critical\",\"confidence\":\"Unknown\",\"raw_source_code_extract\":\"AKIAIOSFODNN7EXAMPLE\",\"scanner\":{\"id\":\"gitleaks\",\"name\":\"Gitleaks\"},\"location\":{\"file\":\"ee/sp
ec/workers/scan_security_report_secrets_worker_spec.rb\",\"commit\":{\"sha\":\"0000000\"},\"start_line\":15},\"identifiers\":[{\"type\":\"gitleaks_rule_id\",\"name\":\"Gitleaks rule ID AWS\",\"value\":\"AWS\"}]}",
    "vulnerability_id": 78903978,
    "details": {},
    "description": "AWS Access Token",
    "message": "AWS Access Token detected; please remove and revoke it if this is a leak.",
    "solution": null,
    "cve": "ee/spec/workers/scan_security_report_secrets_worker_spec.rb:1a5d44a2dca19669d72edf4c4f1c27c4c1ca4b4408fbb17f6ce4ad452d78ddb3:AWS",
    "location": {
      "file": "ee/spec/workers/scan_security_report_secrets_worker_spec.rb",
      "commit": {
        "sha": "0000000"
      },
      "start_line": 15
    },
    "detection_method": "gitlab_security_report",
    "config_options": null
  },
  "resolved_on_default_branch": false,
  "project_default_branch": "master",
  "author_id": 10034774,
  "updated_by_id": null,
  "last_edited_by_id": null,
  "resolved_by_id": null,
  "dismissed_by_id": null,
  "confirmed_by_id": null,
  "start_date": null,
  "due_date": null,
  "created_at": "2023-03-27T18:01:00.704Z",
  "updated_at": "2023-04-03T12:19:22.849Z",
  "last_edited_at": null,
  "resolved_at": null,
  "dismissed_at": null,
  "confirmed_at": null
}

Another example here: https://gitlab.com/gitlab-examples/security/security-reports/-/security/vulnerabilities/77086176

What is the current bug behavior?

dismissed_at is null, dismissed_by_id is null, state is dismissed.

What is the expected correct behavior?

If state is dismissed, dismissed_at and dismissed_by_id can't be null.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com /label reproduced 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

I wonder if it can be linked to the recent auto-revocation service.

Edited by Daniel Tian