Security finding statuses in the Pipeline page > Security tab

Problems to solve

The status filter on the Security tab doesn't appear to be doing anything: If you dismiss a finding, it shows up in the list, even though the list is default filtered to only showing the Needs triage status:

Proposal

Refresh page after a status action is taken on the finding (Dismissed or re-opened via Undo dismiss button back to Needs triage))

Issue history

Prior problems (addressed in comment thread below)

1. CONFIRMED problem

In https://gitlab.com/gitlab-org/gitlab/-/issues/548643/designs/Pipeline_5.png?version=2791106#note_2600650002, it came up that there's a status filter for security findings in the Security tab of the Pipeline page (screenshot (a)), and it shows all 4 statuses, even though the only options for statuses at this point are Needs triage and Dismissed (screenshot (b)). There is no way to Confirm a vulnerability (mark it as Confirmed) Update from Neil: Findings can have a status of Confirmed . This would occur if the associated vulnerability record status was updated to Confirmed on the default branch. Any findings that are resolved would disappear entirely (and we haven't heard user feedback that viewing resolved/ Resolved vulns is needed.) This is misleading because it looks like findings can be in 1 of these 4 states, but really only 2 3 are used in this context.

(a)

(b)

[Problem 2 moved up to main section]

3. Questionable problem (needs problem validation):

Is it a problem that we don't offer a way to mark a security finding as Confirmed or Resolved? I'm not sure why the decision was made NOT to offer "Resolved" or "Confirmed" as options here (and in the MR). For "Confirmed", I could see an appsec engineer wanting to mark something as confirmed which tells the MR author it's been reviewed and was determined to be a verified threat. Say there's 10 total vulns, and 3 are blocking the MR from merging, and the AppSec person comes in and reviews the 3 and determines them to be valid/ true positive/ high risk, the only option they have have is to leave it as-is and either discuss in a comment in the MR or open an issue. But there's no quick way to tell if a finding that's blocking the MR has been reviewed or not. It would help the MR author to be able to see, at a glance, that a finding blocking the MR has been reviewed by AppSec because they added a Confirmed badge.

From Thiago:

I think you raise a good point. I'm not sure we have a reason for not allowing Confirmed.

If you mark something as Confirmed on a finding, this status should carry to the vulnerability report once it appears on the default branch.

As for Resolved, I don't think it ever makes sense to use in the pipeline report.

If someone were to set a finding to Resolved without actually fixing it, the status would revert to Needs triage once it appears on the default branch. On the other hand, if someone did fix it, then it wouldn't show in the report at all.

If we're not keeping track of Resolved findings in the MR/ Pipeline page, these won't be reflected in the Resolution velocity dashboard panel, correct? And therefore any "closed" findings there would be either coming from manually applied status changes of Dismissed and Resolved?

Proposal

To address problems (1) and (3), either:

• Remove Resolved from the Security tab filter.

OR

• Add the ability to change the status of a security finding to Confirmed in the MR and Security tab, and add ability to view Resolved findings. (In this case, we could leave the filter as-is.)

To address problem (2):

• Dismissed vulnerability should not show in list when status filter is set only to Needs triage (the default).

Verification

1. Go to https://gitlab.com/gitlab-org/govern/threat-insights-demos/verification-projects/verification-554078/-/pipelines/2014675059/security
2. Open a finding by clicking the description
3. Dismiss the finding and verify after the modal closes, the finding you clicked open is not visible in the list (since it's dismissed now, it does not fit Need triage / confirmed filter)