Secret Detection findings should not all be Critical-severity ## Problem Currently, Secret Detection [sets every finding to Critical severity](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/7e1e03209495a209308f3e9e96c5a4a0d32e1d55/convert.go#L49), presumably on the theory that all leaked secrets are very urgent. This makes sense, but it makes usability worse because: - It contributes to alert- and triage-fatigue. - Users can't prioritize the findings if they all have the same severity. (This is particularly true given the current state of sorting/filtering/grouping in the result display.) - It makes it harder for customers to use a [Scan Result Policy](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) for Secret Detection, since the severity-based policy constraint will always catch all findings. (For example, if a customer definitely wants to know about super-high-impact leaks like cloud credentials being leaked in a public repo, they can't easily write a policy that handles that finding more strictly than a potential password in a URL.) ## Proposal Secret Detection findings should no longer be all Critical. Instead, we should add new logic to determine a severity level based on context, such as the expected impact of the leak, the likelihood that the leak is a true positive, or whether we've already sent the credential to a partner who we know applies automatic mitigations to protect accounts. Issues in this epic will propose specific approaches and develop ideas about how to handle them. (Let's keep the epic focused on the overall idea if we can.) ## Related discussions Secret Detection has a different security model compared to SAST, but we've recently had relevant discussions about changing the severity levels for SAST: - [How to methodically assess SAST rule severity](https://gitlab.com/gitlab-org/gitlab/-/issues/403591#note_1337334647 "Review and update all GitLab-maintained SAST rule severity levels (used in the Semgrep-based analyzer)") - [Possible challenges in rolling out changes to the severity ratings for existing SAST rules](https://gitlab.com/gitlab-org/gitlab/-/issues/403591#note_1337343846 "Review and update all GitLab-maintained SAST rule severity levels (used in the Semgrep-based analyzer)") - [Handling confidence and severity separately](https://gitlab.com/gitlab-org/gitlab/-/issues/403591#note_1337346033 "Review and update all GitLab-maintained SAST rule severity levels (used in the Semgrep-based analyzer)")