Playbooks disponibles
GitGuardian fournit plusieurs playbooks intégrés qui peuvent être appliqués aux incidents internes, aux incidents publics, ou aux deux.
Partage automatique du lien public de l'incident au développeur impliqué
Ce playbook est disponible uniquement pour Internal Monitoring.
Automatise le partage des incidents avec les développeurs impliqués par e-mail à l'aide de liens de partage publics.
Trigger : Incident créé par un non-membre du workspace
Action : Crée un lien de partage public et envoie un e-mail au développeur
Prérequis : Le partage public doit être activé dans les paramètres du workspace
Options :
- Collecte de retours : Le développeur peut soumettre des retours via le lien
- Capacité de résolution : Le développeur peut résoudre/ignorer l'incident via le lien
Si l'incident est déclenché par un membre du workspace, ce playbook ne s'appliquera pas car il peut accéder à l'incident via le dashboard authentifié.
Octroi automatique de l'accès au développeur impliqué (in-app)
Ce playbook est disponible à la fois pour Internal Monitoring et Public Monitoring.
Accorde automatiquement l'accès à l'incident aux membres du workspace ayant des niveaux d'accès Restricted ou Member lorsqu'ils sont impliqués dans l'incident.
Trigger : Le playbook accorde l'accès dans trois situations :
- Nouveaux incidents — lorsqu'un nouvel incident est détecté impliquant un membre du workspace, ce membre se voit accorder l'accès automatiquement.
- À l'activation (incidents historiques) — lorsque le playbook est activé pour la première fois, GitGuardian exécute un remplissage unique qui accorde l'accès à tous les incidents existants dont un membre actuel du workspace est l'auteur. Activer le playbook s'applique donc de manière rétroactive, et non uniquement aux incidents détectés par la suite.
- Lorsqu'un membre rejoint — lorsqu'un nouveau membre est ajouté au workspace alors que le playbook est actif, il se voit accorder l'accès aux incidents existants dans lesquels il est impliqué.
Action : Accorde à l'utilisateur impliqué l'accès pour consulter cet incident spécifique. Cela se fait en faisant correspondre l'e-mail de l'auteur du commit avec l'e-mail de l'utilisateur du dashboard.
Résolution automatique des secrets révoqués
Ce playbook est disponible à la fois pour Internal Monitoring et Public Monitoring. Il est activé par défaut pour Internal Monitoring.
Résout automatiquement les incidents lorsque des secrets précédemment valides sont révoqués.
Trigger : Un secret précédemment vérifié comme valide par GitGuardian devient invalide.
Action : Clôture automatiquement l'incident comme « Resolved », avec la raison « Secret was revoked »
L'activation de ce playbook s'applique à la fois à la détection en temps réel (lorsqu'un incident est re-vérifié et trouvé invalide) et à tous les incidents historiques devenus invalides par le passé. Lors de l'activation, une invite de confirmation vous indiquera combien d'incidents historiques seront automatiquement résolus.
Ignorer automatiquement les secrets invalides
Ce playbook est disponible à la fois pour Internal Monitoring et Public Monitoring. Il est activé par défaut pour Internal Monitoring.
Ignore automatiquement les incidents ouverts dont le secret est connu comme invalide.
Trigger : GitGuardian apprend que le secret d'un incident ouvert est invalide. Cela se produit dans quatre situations :
- Nouveaux incidents : un incident est créé avec un secret déjà vérifié comme invalide.
- Re-vérifications de validité : une re-vérification périodique, une re-vérification à la demande, une actualisation de validité d'un endpoint ou un remplacement manuel de validité signale le secret comme invalide.
- Régressions : un incident se rouvre alors que son secret est toujours invalide.
- À l'activation (incidents historiques) : lorsque le playbook est activé pour la première fois, GitGuardian l'applique aux incidents existants de votre workspace.
Action : Clôture automatiquement l'incident comme « Ignored », avec la raison « Invalid secret ».
Lors de l'activation, une invite de confirmation vous indiquera combien d'incidents historiques seront automatiquement ignorés.
Priorité avec Résolution automatique des secrets révoqués : les deux playbooks réagissent au même signal. La résolution automatique des secrets révoqués s'exécute en premier et prend les incidents dont le secret a été vérifié comme valide au moins une fois. Ignorer automatiquement les secrets invalides prend ensuite les incidents encore ouverts.
| Historique de validité du secret | Résolution automatique des secrets révoqués | Résultat |
|---|---|---|
| A été vérifié comme valide au moins une fois | Actif | Resolved, avec la raison « Secret was revoked » |
| A été vérifié comme valide au moins une fois | Inactif | Ignored, avec la raison « Invalid secret » |
| N'a jamais été vérifié comme valide | Actif ou inactif | Ignored, avec la raison « Invalid secret » |
Ce playbook ne s'applique pas aux détecteurs qui prennent en charge des hôtes personnalisés. Pour ces détecteurs, la validité dépend de l'hôte sur lequel le secret est vérifié. Consultez Personnaliser les vérifications de validité.
Ignorer automatiquement les faux positifs
Ce playbook est disponible et activé par défaut à la fois pour Internal Monitoring et Public Monitoring.
Ignore automatiquement les incidents qui ont été marqués comme faux positifs par le modèle interne de machine learning de GitGuardian.
Trigger : Un incident est identifié comme un faux positif par le modèle ML
Action : Clôture automatiquement l'incident comme « Ignored », avec la raison « False positive (not a secret) »
Ce playbook fonctionne exclusivement avec les secrets génériques, car le modèle de machine learning n'analyse que ce type de secret. Il s'applique à la détection en temps réel dès qu'un incident est identifié comme faux positif, et peut également être appliqué aux incidents historiques en lançant un scan historique sur votre périmètre.
L'activation de ce playbook s'applique à la fois aux incidents en temps réel et aux incidents historiques qui étaient déjà invalides lors de leur détection. Lors de l'activation, une invite de confirmation vous indiquera combien d'incidents historiques seront automatiquement résolus.
