Track count of suppressed secret detections

Overview

This is a placeholder for the issue.

The aim is to track count of how many times secret detection was suppressed when the feature is enabled in a GitLab instance.

Proposal

Use internal event tracking to count the number of times a secret detection was suppressed using commit messages or push options.

Considerations

• Implementation will be very similar to the other track count issues, so working them together could provide efficiency gains: Track types of secrets blocked and their cardin... (#443354 - closed) • Ethan Urie • 17.2 and Track count of detected secrets (#443352 - closed) • Ethan Urie • 17.2
• Where the logic for this, and the other track count issues take place, will be similar to Add audit events for pre-receive secret detection (#441185 - closed) • Serena Fang • 16.11 • On track
• I think we're adding the additional way to suppress secret detection Revamp secrets check bypass mechanism (#435315 - closed) • Serena Fang • 17.0 • On track, or maybe changing it completely. We should make sure those issues are coordinated so as to possibly avoid rework, if it makes sense to do so.
• We may want to add a type that indicates if it is being suppressed through a commit message or push options in order to further break down the data. Note: both options may not be available when we start tracking this.
• This data will be fed into another system, and the "how" of querying of that data is not within the scope of this issue.

Implementation

Most likely, this tracking will be added to https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/gitlab/checks/secrets_check.rb.

The documentation in internal event tracking provides a good start for doing so.

Refinement Progress

If a checkbox is not relevant for the issue, please remove it.

• This issue describes a problem to solve, or a task to complete, and it's confirmed.
• This issue describes a proposal or an implementation plan that outlines a way to solve the problem or complete the task.
• This issue is the smallest iteration possible and doesn't require further break down.
• This issue has weight set - based on how many tasks or merge requests are required - and needs weight label is removed.
• This issue is labeled correctly.
• This issue is reviewed by another team member to confirm strategy and estimate.
• Finally, add workflowready for development label to this issue.