Track number of security findings, per scanner, in MR
Tracking objective
To better understand the average versus edge cases when it comes to number of vulnerability findings in MRs, we need to start collecting this data. The MR security widget is the only place where the difference between findings in a specific MR and its target branch are exposed. For this reason, we want to instrument the MR security widget to send for capture:
- Number of New findings, by scanner (report) type
- Number of Fixed vulnerabilities, by scanner (report) type
- Number of Dismissed findings/vulnerabilities, by scanner (report) type
Structured Snowplow events to track
- Category: The page or backend area of the application. Unless infeasible, please use the Rails page attribute by default in the frontend, and namespace + classname on the backend. If you're not sure what it is, work with your engineering manager to figure it out.
- Action: A string that is used to define the user action. The first word should always describe the action or aspect: clicks should be
click
, activations should beactivate
, creations should becreate
, etc. Use underscores to describe what was acted on; for example, activating a form field would beactivate_form_input
. An interface action like clicking on a dropdown would beclick_dropdown
, while a behavior like creating a project record from the backend would becreate_project
- Label: Optional. The specific element, or object that's being acted on. This is either the label of the element (e.g. a tab labeled 'Create from template' may be
create_from_template
) or a unique identifier if no text is available (e.g. closing the Groups dropdown in the top navbar might begroups_dropdown_close
), or it could be the name or title attribute of a record being created. - Property: Optional. Any additional property of the element, or object being acted on.
- Value: Optional, numeric. Describes a numeric value or something directly related to the event. This could be the value of an input (e.g.
10
when clickinginternal
visibility)
Category | Action | Label | Property | Feature Issue | Additional Information |
---|---|---|---|---|---|
cell | cell | cell | cell | cell | cell |
cell | cell | cell | cell | cell | cell |
Snowplow event tracking checklist
-
Engineering complete work and deploy changes to GitLab SaaS -
Verify the new Snowplow events are listed in the Snowplow Event Exploration dashboard -
Create chart(s) to track your event(s) in the relevant dashboard -
Use the Chart Snowplow Actions SQL snippet to quickly visualize usage. See example
-
Implementation plan
-
frontend https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/vue_shared/security_reports/grouped_security_reports_app.vue is responsible for fetching the reports. Once we fetch the reports we should use ~/tracking
to send an event to Snowplow. We can use the following function call to generate this data:
Tracking.event("Vulnerability_Management", trackEvent, {
value: numberOfFindings
})
Where trackEvent
is:
mr_widget_findings_counts_${TOOL_TYPE}_${STATE}
// and
TOOL_TYPE is one of "SAST", "DAST", "CONTAINER_SCANNING" etc...
STATE is "fixed" or "new"
// and
numberOfFindings is the number of findings which is returned by the backend.
Here's an example of where we use this data:
Edited by Savas Vedova