Skip to main content

Status and lifecycle

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. For instance for secrets incidents, the secret has been revoked and erased from the git history.

Resolving an incident means that you don't expect to see it appear again in your perimeter. In case a new occurrence appears for an incident that had been resolved, GitGuardian will reopen this incident and alert you again. We call this a regression.

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. In case a new occurrence appears for an incident that has been ignored, GitGuardian won't reopen this incident and won't alert you.

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

Life cycle#

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 a recap by email of 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 tries to help you as much as possible along the way by delivering as much as contextual information as possible and by providing 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 Collect feedback and Remediate sections.

Eventually you can then decide to resolve or ignore the incident. You will always have the possibility to reopen it manually.

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

Incident timeline