Cycle de vie des incidents

Statuts d'incident

info

Un incident de secret public peut être dans l'un des deux états globaux suivants :

• Open : comprenant les statuts Triggered et Assigned
• Closed : comprenant les statuts Resolved et Ignored

Triggered

Un incident triggered est un incident détecté et stocké par GitGuardian, mais qui n'a pas encore été examiné par un membre de votre workspace.

Assigned

Un incident assigned est en cours d'examen par un membre spécifique du workspace. Il n'est pas encore résolu ou ignoré.

Resolved

Un incident resolved est un incident considéré comme remédié. Dans le cas d'un incident de secret public lié à votre entreprise, vous devez généralement vous assurer que le secret a été révoqué, et facultativement que la preuve a été supprimée de GitHub public.

Paramètre de régression pour les incidents résolus

• Si vous considérez qu'une nouvelle occurrence d'un incident déjà résolu est problématique, vous voudrez activer le comportement de régression. Lorsque le comportement de régression est positionné sur On et qu'une nouvelle occurrence de ce secret est détectée en temps réel (qu'il ait été révoqué ou non), GitGuardian rouvre l'incident, repasse son statut à Triggered et déclenche une notification.
• Si l'exposition du secret n'est pas importante pour vous et que seule la révocation compte, vous pouvez positionner sur Off le comportement de régression, et GitGuardian ajoutera silencieusement l'occurrence à l'incident résolu existant sans envoyer de notification.

Le comportement de régression peut être configuré dans la section Incidents lifecycle des paramètres généraux de votre workspace.

Ignored

Un incident ignored est un incident qui n'est pas considéré comme tel par un membre de votre équipe et qui ne nécessite pas de remédiation.

Pour les incidents de secrets publics, une raison typique d'ignorer un secret est que le secret est un identifiant personnel d'un développeur, et n'est pas réellement lié à votre entreprise (« Credential is not related to the company »). Cependant, plusieurs autres raisons d'ignorer sont possibles :

• il s'agit d'un identifiant de test
• il s'agit d'un secret à faible risque
• ce n'est pas un secret (faux positif)
• le développeur n'est pas connecté à l'entreprise
• l'identifiant n'est pas lié à l'entreprise

Ignorer un incident signifie que vous ne voulez plus que GitGuardian le prenne en compte. Si une nouvelle occurrence apparaît pour un incident ignoré, GitGuardian ne le rouvrira pas et ne vous alertera pas.

Cycle de vie d'un incident

1. Réception des alertes d'incidents

GitGuardian peut envoyer une alerte lors de la détection d'un nouvel incident. Tous les membres ayant accès à Public Monitoring peuvent être alertés par e-mail, et/ou sur leurs intégrations d'alerting, afin de traiter le nouvel incident aussi rapidement que possible.

Notez que pour les incidents détectés grâce au scan historique, nous n'envoyons pas une alerte par incident mais plutôt un e-mail récapitulatif avec tous les incidents découverts lors d'un scan historique donné.

Les membres recevront également des alertes similaires en cas de régression d'un incident déjà résolu.

2. Assignation des incidents

L'examen et la remédiation d'un incident peuvent prendre du temps. Faites donc savoir à vos coéquipiers que vous travaillez actuellement sur un incident donné, en déclarant l'assigné, afin de ne pas dupliquer le travail au sein de votre équipe.

Prioriser et savoir quel incident est plus grave qu'un autre peut être très difficile, surtout lorsque vous traitez un grand nombre d'incidents. Consultez notre guide de priorisation pour découvrir nos bonnes pratiques pour identifier les incidents que vous devez traiter en premier.

3. Collaborer et remédier

Une fois que vous avez décidé sur quel incident vous voulez travailler, une nouvelle phase de collaboration et de remédiation commence. GitGuardian vous aide en fournissant autant d'informations contextuelles que possible et des fonctionnalités qui vous aident à entrer en contact avec les parties prenantes appropriées et à vérifier que l'incident a été correctement remédié. Pour en savoir plus à ce sujet, consultez notre section Remédiation des incidents.

En fin de compte, vous pouvez résoudre ou ignorer l'incident. Vous aurez toujours la possibilité de le rouvrir manuellement. Dans le cas spécifique d'incidents résolus pour lesquels de nouvelles occurrences sont à nouveau détectées, vous pouvez configurer GitGuardian pour rouvrir automatiquement les incidents et recevoir des alertes ou non, en choisissant votre paramètre de régression préféré.

Toute l'activité utilisateur et les notes d'équipe attachées à un incident donné se trouvent dans la section Activity de la page de l'incident.