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
- Clone this project: https://gitlab.com/gitlab-examples/security/security-reports
- 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.
- 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".
- 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.
- 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".
- Find the dismissed vulnerability in the vulnerability report and click on it. Confirm that it's dismissed, but
dismissed_by_id
anddismissed_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:
Example Project
- https://gitlab.com/gitlab-org/gitlab/-/security/vulnerabilities/78903978
- https://gitlab.com/gitlab-examples/security/security-reports/-/security/vulnerabilities/77086176
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.