Overview

The secret incident and its occurrences

What is a secret occurrence

The same secret can be seen multiple times in your VCS. They are referred to as occurrences.

Thus, an occurrence of a secret incident is uniquely identified by the combination of the following parameters:

• the source (GitHub repository or GitLab project) impacted by the secret occurrence,
• the commit in which we detected the secret occurrence,
• the commit file containing the secret occurrence,
• the line within the commit file where the secret occurred.

Grouping of occurrences into secret incidents

GitGuardian enhances the remediation process by automatically grouping multiple occurrences of the same secret into a single secret incident.
However, within Business Workspaces, the workspace Owner has the exclusive ability to adjust how these secret occurrences are grouped within the settings. Two levels of granularity are available:

1. per secret [default]
   • All occurrences of the same secret across different sources (e.g., repositories) are consolidated into a single secret incident.
   • This means if a particular secret is found in multiple sources, it will generate only one secret incident.
2. per secret x source:
   • Occurrences of the same secret are grouped into separate secret incidents based on their respective sources.
   • This means that if the same secret appears in multiple sources, each source will have its own individual secret incident. This configuration helps tailor the grouping strategy to align with your company's remediation processes and data privacy policies.

danger

Changing the occurrence grouping setting should be done with utmost care, as it has a significant impact on secret incident population and analytics. This modification should be considered a one-off action.
Upon changing this setting, all existing secret incidents will be migrated to comply with the new grouping mode, and please note that this migration process may take some time.

Alerts are sent only when a new incident is created or reopened because of a regression. A new occurrence attached to an already-existing open secret incident won't raise any alerts.

GitGuardian sets a maximum limit of 1,000 occurrences for a single secret incident (this does not apply to the self-hosted platform).

Statuses of an incident

Triggered: A triggered incident is an incident detected and stored by GitGuardian but not yet investigated by a member of your dashboard.

Assigned: An assigned incident is being investigated by a specific member of the dashboard. It is not resolved or ignored yet.

Resolved: A resolved incident is an incident considered as remediated. In the case of secrets incidents, you must revoke the secret (and optionally erase all evidence from the git history) before considering it resolved.

Erasing all evidence from the git history is optional and depends on your code policy.

• If you consider a new occurrence of an incident that has already been resolved to be problematic, you will want the regression behavior enabled. When the regression behavior is turned On, GitGuardian will reopen this incident and alert you again. The regression behavior only applies to occurrences detected through real time monitoring. A resolved incident won't be reopened if a new occurrence is uncovered by a historical scan.
• If rewriting the git history is not important to you and only revocation matters, you can turn Off the regression behavior and GitGuardian will silently add the occurrence to the existing resolved incident without delivering any notifications.

  The regression behavior can be configured in the General section of your settings.

Ignored: An ignored incident is an incident not considered as such by a member of your team and does not require remediation. For secrets incidents, ignore reasons can be:

• this is not a secret (false positive)
• this is test credential
• this is low risk secret

Ignoring an incident means that you don't want GitGuardian to consider it anymore. If a new occurrence appears for an ignored incident, GitGuardian will not reopen it or alert you.

graph LR Triggered --> Assigned Assigned --> Resolved Assigned --> Ignored Ignored -...->|Reopen| Triggered Resolved -...->|Reopen or regression| Triggered

Lifecycle of an incident

1. Receiving incidents alerts

As explained in the section How GitGuardian works, GitGuardian scans every commit in real-time and sends an alert upon detection of a new incident. All the members of the dashboard are alerted by email, and on their alerting integrations, in order to tackle the new incident as quickly as possible.

Note that for incidents detected thanks to historical scanning, we do not send an alert per incident but rather an email recap with all the incidents discovered on a given historical scan.

As mentioned above, all the members of the dashboard receive alert upon regression of an already-resolved incident.

2. Assigning incidents

Investigation and remediation of an incident can take some time. So let your teammates know that you are currently working on a given incident, by declaring the assignee, in order not to duplicate work within your team.

Prioritizing and knowing which incident is more severe than another can be very challenging, especially when you are dealing with a large number of incidents. Have a look at our Prioritize and explore guide to read our good pratices for spotting the incidents you need to tackle first.

3. Collaborate and remediate

Once you decide which incident you want to work on, a new phase of collaboration and remediation starts. GitGuardian helps you by providing as much as contextual information as possible and features that help you get in touch with the appropriate stakeholders and check that the incident has been properly remediated. Read more about this topic in our Remediating incidents section.

Ultimately, you can resolve or ignore the incident. You will always have the possibility to reopen it manually. In the specific case of resolved incidents for which new occurrences are detected again, you can configure GitGuardian to automatically re-open incidents and receive alerts or not by choosing your preferred Regression setting.

All user activity and team notes attached to a given incident can be found in the Timeline section of the incident page.