Remédier aux incidents
Ce guide couvre les fonctionnalités de la plateforme GitGuardian qui soutiennent vos efforts de remédiation, y compris les outils de collaboration, les capacités d'automatisation et la gestion intégrée des secrets.
Nouveau sur la remédiation ? Commencez par notre Vue d'ensemble de la remédiation pour comprendre l'approche de GitGuardian, puis choisissez le Scénario de remédiation adapté à votre situation.
Collaborer avec les développeurs
Impliquer les développeurs est crucial pour la remédiation. Les développeurs ont également des connaissances sur le secret lui-même, puisque ce sont eux qui l'ont utilisé. Ils comprennent également l'architecture du système et les services qui peuvent dépendre du secret. Ils peuvent fournir des informations sur les services affectés et la meilleure façon d'atténuer les problèmes. Cette connaissance est essentielle pour créer un plan de remédiation efficace et efficient.
L'objectif de GitGuardian est de permettre une collaboration facile avec vos développeurs en offrant des moyens flexibles de partager vos incidents.
Partager l'incident
Vous pouvez collaborer en partageant l'incident de deux manières :
- En interne, avec les utilisateurs enregistrés sur le dashboard, via l'action "Grant access". Cette option est disponible uniquement pour les workspaces Business.
- En externe, avec des utilisateurs non enregistrés, via l'action "Public sharing".
Lorsque vous partagez un incident, l'incident entier avec toutes ses occurrences est partagé, et non uniquement des occurrences individuelles. Cela fournit un contexte complet pour une collaboration de remédiation efficace.
Plus de détails sont disponibles dans notre section dédiée Collaboration et partage.
Recueillir les retours
Le formulaire de retour vous permet de collecter des retours standardisés sur un incident. Pour remplir le formulaire, les utilisateurs enregistrés doivent disposer de la permission "Can edit" sur l'incident. Ils peuvent également modifier ou supprimer leur propre retour.
Chaque fois qu'un retour est soumis pour un incident, qu'il provienne d'un utilisateur enregistré ou non, une notification par e-mail est envoyée :
- à l'assigné de l'incident, le cas échéant.
- à tous les utilisateurs ayant accès à l'incident, s'il n'y a pas d'assigné.
Chaque action effectuée par le développeur sera enregistrée dans la timeline des détails de l'incident.
Le formulaire de retour n'est pas encore personnalisable.
Mentionner des Members et des Teams
Dans les notes et retours d'incident, vous pouvez mentionner un Member ou une Team pour notifier directement les bonnes personnes. Tapez @, puis choisissez un Member ou une Team dans la liste consultable. La liste ne suggère que les Members et Teams qui ont déjà accès à l'incident.
- Mention d'un Member (
@name) : le Member mentionné reçoit une notification par e-mail avec un lien direct vers l'incident. - Mention d'une Team (
@team-name) : chaque membre de la Team reçoit la notification.
Les mentions respectent les permissions existantes : le sélecteur ne liste que les Members et Teams ayant accès, et une personne mentionnée n'est notifiée que pour les incidents auxquels elle peut accéder.
Les destinataires peuvent gérer ces e-mails depuis leurs paramètres de notification sous Workspace.
Personnalisation des workflows
GitGuardian affiche un workflow de remédiation par défaut sur la page de détails de chaque incident pour guider les efforts de remédiation. Les organisations peuvent personnaliser ce workflow pour correspondre à leurs politiques et procédures spécifiques.
Personnaliser les workflows
Les Managers du workspace peuvent personnaliser les workflows de remédiation dans les paramètres de détection des secrets :
- Créer des workflows personnalisés - Définissez jusqu'à 20 étapes personnalisées avec des titres, descriptions et liens
- Basculer entre workflows - Choisissez entre le workflow GitGuardian par défaut et les versions personnalisées
- Modifier les workflows existants - Ajoutez, modifiez, supprimez ou réorganisez les étapes selon les besoins
- Appliquer à l'échelle de l'organisation - Les workflows personnalisés apparaissent sur toutes les pages d'incidents et les incidents partagés
Cette personnalisation permet de s'assurer que la remédiation suit les procédures de sécurité établies et les exigences de conformité de votre organisation.
Messages personnalisés lors de l'utilisation de la CLI GitGuardian (ggshield)
Lorsque la CLI GitGuardian détecte des secrets dans le code des développeurs, que ce soit en pre-commit ou à d'autres étapes, il est très bénéfique de leur fournir des instructions claires sur l'utilisation des secrets dans leur code selon les standards de l'entreprise (Vaults, variables d'environnement, ..).
Les équipes de sécurité ont la possibilité de personnaliser ces messages, qui seront diffusés via la CLI à différentes étapes du cycle de vie du développement logiciel telles que pre-commit, pre-push et pre-receive.
Intégration avec Secret Manager
GitGuardian s'intègre avec les Secret Managers via ggscout pour rationaliser le processus de remédiation :
Capacités clés
- Push-to-vault - Déplacez les secrets exposés directement vers votre Secret Manager depuis le dashboard GitGuardian
- Identification des secrets - Taguez automatiquement les incidents lorsque les secrets sont déjà stockés dans un vault
- Suivi de la remédiation - Surveillez la progression de la détection jusqu'à la mise en œuvre du stockage sécurisé
Intégrations prises en charge
GitGuardian fonctionne avec les principales plateformes de Secret Manager pour fournir des workflows de remédiation fluides. L'intégration aide à identifier quels secrets doivent être déplacés vers un stockage sécurisé et facilite le processus de transition.
En savoir plus sur les intégrations Secret Manager
Révocation de secrets depuis GitGuardian
La fonctionnalité intégrée de révocation de secrets de GitGuardian vous permet de révoquer des secrets valides directement depuis la plateforme pour les fournisseurs pris en charge, réduisant drastiquement le temps pendant lequel les secrets restent exposés et accélérant vos workflows de réponse aux incidents.
Cette fonctionnalité élimine le besoin de basculer entre plusieurs outils et plateformes pendant la remédiation, offrant un chemin rationalisé de la détection à la résolution.
- Le secret doit avoir un statut Valid.
- Vous devez disposer des permissions
Full Accesssur l'incident. - La révocation de secret est prise en charge par le fournisseur.
Fournisseurs pris en charge
La révocation de secrets est actuellement disponible pour les fournisseurs suivants :
- Tokens d'accès personnels et fine-grained GitHub.
- Tokens d'accès personnels GitLab.
- Clés API OpenAI.
- Clés API SendGrid.
- Tokens utilisateur et tokens Slackbot Slack.
- Clés de plateforme Heroku.
GitGuardian plaide activement auprès des fournisseurs de services pour qu'ils adoptent des capacités de révocation programmatique et implémentent des endpoints de révocation standardisés, rendant la gestion des secrets plus sécurisée dans l'ensemble de l'écosystème.
D'autres fournisseurs sont ajoutés régulièrement. Revenez consulter les mises à jour ou contactez le support pour demander la prise en charge d'un fournisseur spécifique.
Activer la révocation de secrets
La fonctionnalité de révocation de secrets peut être activée ou désactivée dans les paramètres de votre workspace :
- Naviguez vers Settings > Secrets > General.
- Localisez le bouton Secret Revocation.
- Activez ou désactivez la fonctionnalité selon vos besoins.
Les Managers et Owners du workspace peuvent contrôler ce paramètre. Lorsqu'il est désactivé, le bouton de révocation n'apparaîtra pas sur les pages de détails des incidents.
Filtrer les incidents révocables
Concentrez les efforts de votre équipe sur ces incidents à fort impact et exploitables qui peuvent être révoqués immédiatement :
- Naviguez vers votre liste d'incidents.
- Filtrez les secrets
Validen utilisantSecret Validity. - Filtrez les secrets révocables en utilisant le tag GitGuardian
Revocable by GitGuardian.
Révoquer un secret
La révocation d'un secret peut avoir des effets secondaires dramatiques sur vos systèmes, applications ou workflows. Par conséquent, vous devriez toujours envisager de vérifier ce que la révocation impactera avant de procéder.
GitGuardian vous fournit beaucoup de contexte et d'informations pour évaluer l'impact de l'exposition, mais surtout, mesurer l'impact de la révocation, grâce à l'identification des workloads utilisant ces identifiants.
Pour révoquer un secret directement depuis GitGuardian :
- Naviguez vers l'incident : Ouvrez la page de détails de l'incident pour le secret que vous souhaitez révoquer.
- Localisez le bouton de révocation : Trouvez le bouton Revoke dans la section du panneau latéral droit des détails du secret.
- Lancez la révocation : Cliquez sur Revoke pour ouvrir la boîte de dialogue de confirmation.
- Confirmez l'action : Confirmez la révocation en insérant
revokedans la boîte de dialogue modale.
- Surveillez la timeline : L'action de révocation sera automatiquement enregistrée dans la timeline de l'incident.
Après la révocation
Une fois qu'un secret est révoqué, GitGuardian relance automatiquement le validity checker. En cas de succès :
- Le statut du secret passe de
ValidàInvalid. - Le statut de l'incident lié passe à
Resolveden supposant que le Playbook Résoudre automatiquement les incidents lorsque des secrets valides sont révoqués est activé.
Toutes les activités de révocation sont enregistrées dans la timeline de l'incident à des fins d'audit et de conformité.
La plupart des API de révocation ne confirment pas explicitement le succès de la révocation. GitGuardian s'appuie sur des vérifications de validité ultérieures pour déterminer si la révocation a réussi.
Automatiser la remédiation avec les playbooks
Les playbooks GitGuardian peuvent automatiser de nombreuses tâches de remédiation pour les incidents internes, réduisant le travail manuel et accélérant les temps de réponse.
En savoir plus sur la configuration des playbooks pour votre workspace.
Les playbooks pertinents pour Internal Monitoring sont :
- Partage automatique de l'accès à l'incident à l'auteur de la fuite (lien par e-mail)
- Attribution automatique de l'accès à l'incident à l'auteur de la fuite (in-app)
- Résolution automatique de l'incident lorsqu'un secret valide est révoqué
- Ignorer automatiquement les incidents lorsque les secrets sont taggés comme faux positifs
- Ignorer automatiquement les incidents lorsque les secrets sont directement marqués comme invalides
Consultez le détail complet des playbooks disponibles.
