Vulnerability findings dismissed without any attribution
<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> 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 1. 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. 1. 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". 1. 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. 1. 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". 1. 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](/uploads/2797221cfd2ad7e3d129a7902fad2e01/2023-04-04_02-56-34.mp4) ### Example Project <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> - 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: ```json { "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? <!-- Describe what actually happens. --> `dismissed_at` is null, `dismissed_by_id` is null, `state` is `dismissed`. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> If `state` is `dismissed`, `dismissed_at` and `dismissed_by_id` can't be null. ### 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, uncomment below --> This bug happens on GitLab.com /label ~"reproduced on GitLab.com" #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (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`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (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) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> I wonder if it can be linked to the recent [auto-revocation service](https://gitlab.com/groups/gitlab-org/-/epics/8624).
issue