Skip to main content

Overview

An incident represents a problem that needs to be addressed and resolved.

Secret incidents and more#

GitGuardian raises:

  • Secret incidents.

    Thanks to our secrets detection engine, GitGuardian can identify secrets in your source code and display them on the dashboard for you to remediate.

  • Policy break incidents. (beta)

    As an add-on, GitGuardian has also developed security policies that detect the presence of sensitive filenames, file extensions. These policies only run during real time monitoring.

Incidents and occurrences#

The same secret can be seen multiple times in your VCS. They are referred to as occurrences. GitGuardian automatically groups several occurrences under the same incident in order to facilitate your remediation process.

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

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.

Incident status#

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.
  • 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.

Regression setting

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

Incident lifecycle#

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.

Incident timeline