Skip to main content

Prioritize incidents

One of the key challenges of a secrets detection and remediation program is prioritizing incidents and identifying where you should focus remediation efforts.

GitGuardian focuses on the precision of its secrets detection engine (to raise the highest percentage of true positives). You can refer to our dedicated documentation for further information. That being said, the severity of a secret incident is still a notion that is hard to grasp from an external standpoint. That is why GitGuardian tries to give as much factual information as possible in order to help you categorize the severity of the secret incident.

1. Prioritize with the incidents table#

You can find a table of all your incidents in the Incident section. Our aim is to help you navigate this table in the most efficient way possible.

Open incidents by default#

The table is filtered by default by open incidents (triggered and assigned incidents). You can still have access to incidents that have been resolved or ignored thanks to the Status filter.

status filter

Most recent incidents#

By default, the table of incidents is sorted by "most recent" incidents. As a matter of fact, secrets that were detected most recently have the highest probability of being valid and thus harmful. The date of an incident is the date of its first occurrence.

It is especially important to note here that GitGuardian creates secrets incidents during historical scans. The date of those incidents is the date of the commit where the secret exposure happened, not the date of the historical scan. Such incidents will be marked with the "From historical scan" tag.

Therefore, you can end up with very old incidents as you run GitGuardian on your git history. That is why, we allow you to modify the time frame of the listed incidents and set it to All time. By default, this time frame is set to Last Month.

Secret preview#

You can quickly preview the actual secret from the incidents table with a simple hover. If you would like to further investigate, you can click on the secret incident and visit its dedicated page.

Be cautious: sometimes the broader context of a secret can be much more harmful than the secret itself. We always recommend going beyond the secret preview and conducting an in-depth investigation before making a decision on a particular incident.

secret preview

Secret validity#

The table of incidents indicates for each incident if the compromised secret is still valid or not. You can also filter your incidents to view valid secrets only. This can help you set your priorities straight in terms of remediation. We recommend you take care of exposed and valid credentials as soon as possible, since they still represent unmitigated threats.

Secret validity preview and filter

For more details on this feature, please refer to the dedicated section on validity checkers.

Occurrences count and presence in git history#

The table of incidents also indicates the number of occurrences for each incident. The severity of an incident should not be determined simply by its number of occurrences. This informs you about the potential sprawl of the secret but keep in mind that a secret that is present in more than one place is often not an harmful secret.

The total count is split between the occurrences of the incident present in your git repository and the ones that have been rendered non-existent (following the deletion of a repository or rewriting of the git history).

Occurrences count and breakdown

Removing any trace of the secret in your git repositories may be one of your requirements for full incident remediation. If that is the case, it is possible to filter your incidents to only view the ones for which at least one occurrence is still present or in other words, the ones for which remediation is incomplete.

Incident presence filter


For each incident, we try to give you as much contextual information as possible. Tags are meant to help you quickly evaluate each incident. In the incidents table, you will see all the tags associated with occurrences of an incident. The different tags are:

  • Regression: the incident was once resolved but GitGuardian detected a new occurrence.
  • Test file: one of the occurrences of the incident happened on a potential test file.
  • Sensitive file: one of the occurrences of the incident happened on a potential sensitive file.
  • Exposed publicly: one of the occurrences of the incident was detected on a public repository of
  • From historical scan: one of the occurrences of the incident was detected thanks to a historical scan, as opposed to being detected in real-time.



To help you prioritize incidents during triage, you can set a severity for each incident. You can define the severity of an incident either in its dedicated remediation page, or directly from the table of incidents.

The different severity levels are:

  • Critical: concerns a critical service. Must be tackled as quickly as possible.
  • High: concerns an important service with a potentially broad impact.
  • Medium: concerns an important service with a potentially limited impact.
  • Low: concerns a minor service with a potentially broad impact.
  • Info: concerns a minor service with a potentially limited impact.
  • Unknown: default level applied by GitGuardian to new incidents.


2. Explore with the incident page#

Each incident has a dedicated page in which you can find additional information to help you investigate.

Table of occurrences#

The table of occurrences provides you with the following detailed information:

  • when the occurrence happened
  • who is the developer responsible for the leak (git name, git email)
  • where the occurrence took place (repository, commit, file)
  • when the occurrence was last seen by GitGuardian and if it still visible in your git history
  • the tags associated with the occurrence

For the needs of conducting further investigation, each occurrence has its own menu, with a link to the actual location of the secret occurrence on the VCS, if still present.


For each occurrence of a given secret incident, you have access to the patch of the commit where the secret has been detected. The patch is composed of:

  • the lines of code added by the commit
  • the lines of code deleted by the commit
  • the contextual lines surrounding the added or deleted lines. These lines are also monitored by GitGuardian since they are part of the commit.

A secret can consist of several components. For example, an AWS secret is the combination of client_id and client_secret. You can easily navigate and understand these multiple secret components with the patch in your GitGuardian workspace.

Incident table and patch

From our experience, lots of valuable information can be found around the patch of a secret (other secrets, sensitive data, ...).