Add audit events for pre-receive secret detection

Audit need

With the introduction of pre-receive secret detection, we now block git pushes that contain a secret from reaching the remote repository. We want to log details of the blocked push as they may be useful for metrics (more on this below). In some cases, it may be necessary to skip pre-receive secret detection. In these cases, we want to log that secret detection was skipped.

Proposal

Create audit logs for:

1. Any time a user bypasses pre-receive secret detection and successfully pushes a secret to the repo, including:
   • how they did it (commit message, push option)
   • who did it (user details)
   • the repo the secret was pushed to
   • the secret type
   • the time of push
2. Any time the feature is enabled or disabled at whatever level that occurs (see &13151)

We do not need to create audit logs for when pre-receive blocks a secret, because in that case there has not been a security event. (The feature prevented the bad thing from happening.)

Coordinate with track count issues:

• Track count of detected secrets (#443352 - closed) • Ethan Urie • 17.2
• Track count of suppressed secret detections (#443353 - closed) • Ethan Urie • 17.2
• Track types of secrets blocked and their cardin... (#443354 - closed) • Ethan Urie • 17.2

Outside the scope of this issue

This idea is outside the scope for this issue so won't be worked on, but we may want to consider it after audit events/count tracking issues are finished:

We can use the difference between the time of initial blocked push and time of next successful push without secret to determine resolution time.

Considerations

• Our docs say that audit events are available in Free, Premium, and Ultimate tiers for .com and self-managed customers only (not Dedicated). However, audit event types are only available for Premium and Ultimate. We need to look into if we can even use audit events for this, or if there is a better solution.

Edit: We have confirmed that Audit Events are available for Dedicated customers.

Streaming-only event or normal event?

Normal

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 requires assistance or support from other groups, and it's indicated in the issue description.
• This issue could affect application security or performance, and the concern is explained in the issue description.
• 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.