Investiguer les incidents

Vue d'ensemble de l'investigation

Une investigation appropriée est cruciale pour une remédiation efficace des secrets. Comprendre le contexte complet d'une exposition de secret vous aide à prendre des décisions éclairées sur la priorité et l'approche de remédiation.

Avant de remédier aux incidents, tirez parti de tout le contexte et des insights GitGuardian pour une remédiation sûre et efficace.

Risk score

Fonctionnalité Business

Seuls les workspaces avec un plan Business peuvent accéder au risk score.

Chaque incident inclut un risk score (0-100) qui fournit des insights de priorisation basés sur l'ML, où 100 indique le risque le plus élevé et 0 le plus faible. Le score est affiché de manière proéminente dans la page de détail d'incident avec une explication détaillée des facteurs contributifs.

Caractéristiques principales :

• Scoring dynamique qui se met à jour à mesure que le contexte de l'incident évolue
• Explication en langage naturel des principaux facteurs de risque
• Mécanisme de retour pour aider à améliorer la fonctionnalité Le risk score vous aide à évaluer rapidement si un incident nécessite une attention immédiate ou peut être traité via les workflows standard.

→ En savoir plus sur le Risk Score et comment l'utiliser

Ce que GitGuardian fournit pour l'investigation

Pour chaque incident, GitGuardian vous fournira les métadonnées suivantes sur le secret et ses occurrences :

• Type de secret (remonté par le détecteur)
• Date (à laquelle l'occurrence du secret a été commitée)
• Email de l'auteur du commit (développeur impliqué)
• Nom du dépôt
• Nom et extension du fichier
• Hash SHA-1 du commit
• Présence dans l'historique git (lorsque possible)
• Validité (lorsque possible - voir section dédiée)
• Tags supplémentaires (par exemple, branche par défaut, depuis l'analyse historique, fui publiquement, vaulted, régression, fichier de test, révocable par GitGuardian, etc.)

Vérifications de présence du secret

Avec la vérification de présence, il est possible de vérifier la présence (et donc l'accessibilité) de chaque occurrence du secret dans vos dépôts. Pour chaque incident, GitGuardian affichera les dates auxquelles chaque occurrence a été vue pour la première et la dernière fois et si elle est toujours présente dans le dépôt.

Une fois que vous avez complètement supprimé le dépôt ou réécrit l'historique git, retournez à la page de votre incident pour obtenir la preuve de suppression de l'occurrence du secret (voir capture d'écran ci-dessous). Une fois qu'une occurrence n'est plus visible dans l'historique git, GitGuardian arrêtera de vérifier sa présence.

GitGuardian vérifiera régulièrement la présence des occurrences, dans la mesure du possible et en tenant compte des limites de taux d'API VCS existantes, pour refléter l'état de votre dépôt git. Vous pouvez également exécuter manuellement la vérification de présence si vous devez forcer la mise à jour du statut des occurrences d'un incident.

La fréquence de ces vérifications automatisées dépend de votre plan et du statut et de l'âge des incidents de secrets :

Plan	Statut d'incident	Âge de l'incident	Fréquence
Business	Open	Moins d'un an	Quotidienne
Free	Open	Moins d'un an	Hebdomadaire
Business	Open	Plus d'un an	Hebdomadaire
Free	Open	Plus d'un an	Mensuelle
Business	Ignored	Moins d'un an	Semestrielle
Free	Ignored	Moins d'un an	Jamais
Business	Ignored	Plus d'un an	Jamais
Free	Ignored	Plus d'un an	Jamais
Business	Resolved	Moins d'un an	Mensuelle
Free	Resolved	Moins d'un an	Semestrielle
Business	Resolved	Plus d'un an	Semestrielle
Free	Resolved	Plus d'un an	Jamais

Si vous hébergez GitGuardian on-premise, vous pouvez modifier ces fréquences dans votre admin area.

⚠️ Vérifications de présence et commits orphelins

Lorsque vous supprimez un dépôt, tous ses commits sont définitivement supprimés. Cependant, utiliser git push --force pour supprimer un commit spécifique dans un dépôt ne le supprime pas définitivement. Il devient un commit orphelin, existant toujours mais n'étant plus référencé par aucune branche. Il est impossible de voir les commits orphelins dans une pull request ou dans une branche existante à moins d'avoir accès à l'identifiant unique (sha) du commit. GitGuardian considère qu'une occurrence de secret dans un commit orphelin est présente. Les VCS fournissent un garbage collection, vidant complètement la corbeille des commits orphelins. Dans le cas de :

• GitHub, contacter le support pour exécuter le garbage collection est nécessaire
• GitLab, la fréquence du garbage collection est décidée par l'admin VCS

Lorsque vous décidez de cesser de surveiller un dépôt, GitGuardian perd par conséquent l'accès à ce dépôt, ce qui pousse à son tour la vérification de présence à perdre sa capacité à mettre à jour les valeurs concernant ses occurrences correspondantes. GitGuardian affichera une icône pour indiquer que le dépôt n'est plus surveillé.

Pour les incidents contenant des occurrences liées à plus d'un dépôt, la vérification de présence continuera à fonctionner pour le reste des occurrences liées aux sources surveillées jusqu'à ce que la dernière source surveillée soit retirée du périmètre.

Informations sur l'exposition publique

Lorsqu'un secret a été trouvé dans des emplacements publics, GitGuardian le marque avec le tag Publicly leaked et fournit des informations détaillées sur l'exposition. Comprendre la nature et la portée de l'exposition publique est important pour une remédiation efficace.

Types d'exposition publique

GitGuardian catégorise l'exposition publique en trois types :

La source est visible publiquement

Ce type d'exposition indique que l'incident a au moins une occurrence dans une source surveillée qui est visible publiquement.

Ce que cela signifie :

• Le secret a été commité dans une source que votre organisation a intégrée à GitGuardian Internal Monitoring
• Cette source est visible publiquement

Possède un incident public lié

Le même secret apparaît également dans un ou plusieurs incidents publics détectés par GitGuardian Public Monitoring.

Ce que cela signifie : Le secret a été trouvé dans le périmètre public de votre entreprise (activité de développeur surveillée ou dépôts publics suivis par Public Monitoring)

info

Tous les clients SaaS peuvent voir ce type d'exposition ; les détails complets (incidents liés) nécessitent un abonnement Public Monitoring. Dans Public Monitoring, ces incidents affichent le tag réciproque Internally leaked

Trouvé en dehors du périmètre

Le secret a été trouvé dans des emplacements publics complètement en dehors du périmètre surveillé de votre entreprise.

Ce que cela signifie :

• La capacité HMSL (Has My Secret Leaked) de GitGuardian a détecté le secret sur le GitHub public
• Le secret apparaît dans des dépôts ou emplacements non détenus ou surveillés par votre organisation
• Cela peut indiquer que le secret a été copié, partagé ou divulgué par des parties externes

Informations fournies :

Pour chaque endroit où le secret a été trouvé (jusqu'à 10), GitGuardian fournit :

• Le type d'endroit (dépôt GitHub)
• Un lien vers la source d'origine

Fréquence de vérification automatisée :

GitGuardian vérifie régulièrement les nouvelles occurrences en dehors de votre périmètre. La fréquence dépend de votre plan, du statut de l'incident et de la validité du secret :

Plan	Statut d'incident	Validité du secret	Âge de l'incident	Fréquence
Business	Opened	Non invalide	Moins d'un an	Quotidienne
Business	Opened	Non invalide	Plus d'un an	Hebdomadaire
Business	Resolved	Non invalide	Tout	Mensuelle
Business	Ignored	Non invalide	Tout	Jamais
Business	Opened	Invalide	Tout	Jamais
Business	Resolved	Invalide	Tout	Jamais
Business	Ignored	Invalide	Tout	Jamais

remarque

La vérification "Trouvé en dehors du périmètre" n'est pas prise en charge pour les secrets multi-match. Les secrets détectés en dehors de votre périmètre dans plus de 10 endroits sont considérés comme des faux positifs (par exemple, des credentials de test standard) et n'afficheront pas ce type d'exposition.

Pour les utilisateurs API

Vous pouvez rencontrer deux champs, secret_hash et hmsl_hash, lorsque vous travaillez avec les incidents de secrets, par exemple.

• Le champ secret_hash est un identifiant interne pour chaque secret détecté.
• Le hmsl_hash est associé au service Has My Secret Leaked de GitGuardian. GitGuardian utilise l'algorithme de hachage HMSL pour comparer votre secret — de manière sécurisée et privée — avec les secrets précédemment trouvés sur le GitHub public. Cela permet à GitGuardian de vérifier si votre secret est apparu publiquement, sans exposer la valeur réelle du secret. Le même algorithme de hachage est également utilisé avec ggscout pour identifier les secrets vaulted.

Travailler avec l'exposition publique

Utilisez la vue sauvegardée par défaut "Public exposure" pour vous concentrer sur les incidents qui ont été exposés publiquement. Cette vue affiche uniquement les incidents ouverts publicly leaked et inclut la colonne "Public exposure" pour une visibilité rapide.

Vous pouvez également filtrer par le tag Publicly leaked ou par des types d'exposition spécifiques, et ajouter la colonne Public exposure à toute vue personnalisée.

Les détails de chaque type d'exposition sont affichés dans le panneau latéral de la page de détail de l'incident.

Installations Self-Hosted

Pour les installations Self-Hosted, seul le type d'exposition Source visible publiquement est disponible. Les types d'exposition Incident public lié et En dehors du périmètre ne sont pas du tout disponibles en self-hosted, car ils nécessitent l'infrastructure Public Monitoring de GitGuardian.

Insights d'intégration Secret Manager

Comprendre votre paysage de gestion de secrets est crucial pour une planification efficace de la remédiation. L'intégration de GitGuardian avec les Secret Managers via ggscout fournit un contexte précieux lors de l'investigation.

Identification des secrets vaulted

Lors de l'investigation des incidents, GitGuardian peut identifier si le secret exposé est déjà stocké dans l'un de vos Secret Managers connectés :

• Tag Vaulted : les incidents sont automatiquement tagués lorsque le secret est trouvé dans votre Secret Manager.
• Emplacement de stockage : voir quel Secret Manager contient le secret et son chemin.

Ces informations vous aident à :

• Augmenter la confiance que l'incident est un vrai positif, lorsque le secret associé est vaulted. C'est particulièrement utile lorsque GitGuardian ne peut pas évaluer la validité du secret.
• Déterminer si les applications utilisent à la fois des versions en clair et vaulted.
• Comprendre quelles étapes doivent être considérées pour la remédiation.

Évaluation de la préparation au push-to-vault

Pendant l'investigation, évaluez si le secret est prêt pour l'intégration au Secret Manager :

• Architecture applicative : les applications affectées peuvent-elles récupérer les secrets depuis vos Secrets Managers ?
• Schémas d'accès : à quelle fréquence le secret est-il accédé et par quels services ?
• Considérations d'environnement : différents secrets sont-ils nécessaires pour dev/staging/prod ?

Ces questions devraient vous aider à identifier où les secrets devraient être déplacés, dans quelle instance de secret manager et à quel emplacement.

Implications du workflow Secret Manager

Votre investigation devrait considérer comment l'intégration au Secret Manager affecte la remédiation :

• Infrastructure existante : quelle configuration Secret Manager est déjà en place ?
• Contrôles d'accès : qui a les permissions pour gérer les secrets dans votre Secret Manager ?
• Capacités de rotation : votre Secret Manager prend-il en charge la rotation automatique pour ce type de secret ?
• Dépendances de déploiement : comment les applications seront-elles mises à jour pour utiliser le Secret Manager ?

En savoir plus sur les intégrations Secret Manager

Regroupement d'incidents similaires basé sur l'ML

Sources VCS uniquement

Le regroupement d'incidents similaires basé sur l'ML n'est actuellement disponible que pour les incidents détectés à partir de sources Version Control Systems (VCS). Les sources non-VCS (telles que les intégrations de messagerie, de ticketing ou de documentation) ne sont pas encore prises en charge.

remarque

Le regroupement d'incidents similaires basé sur l'ML est disponible pour les plans Business et Enterprise.

Le regroupement d'incidents similaires basé sur l'ML de GitGuardian vous aide à identifier et gérer les incidents liés plus efficacement en détectant automatiquement les incidents qui partagent des caractéristiques et un contexte similaires.

Comment ça fonctionne

Lors de la consultation d'une page de détail d'incident, vous verrez une section Similar Incidents dans la sidebar qui affiche les incidents avec des schémas similaires détectés par nos algorithmes de machine learning. Cette fonctionnalité analyse le contexte de code dans le patch pour identifier des relations significatives entre les incidents.

Scénarios courants de regroupement

L'algorithme ML identifie différents types d'incidents similaires :

• Tokens en rotation dans des fichiers automatisés : même fichier qui fuit en continu différents tokens via l'automatisation
• Credentials de test QA : clés de test (bots Slack, clés API Postman) apparaissant dans des contextes similaires
• Chaînes de connexion à la base de données : plusieurs chaînes de connexion vers le même environnement avec différents credentials
• Faux positifs répétés : chaînes à haute entropie dans les logs ou scripts de test qui sont probablement générés par le système
• Fuites de code de templating : plusieurs développeurs utilisant des tutoriels ou templates partagés avec des secrets divulgués similaires
• Schémas connus bruyants : faux positifs cohérents provenant de types de fichiers spécifiques ou de services internes

Utiliser les incidents similaires pour l'investigation

1. Depuis les détails d'incident : visualisez les incidents similaires dans la sidebar et cliquez sur "Voir X incidents similaires" pour les voir dans la liste principale d'incidents
2. Filtrer par similarité : dans la zone de recherche, utilisez similar_to pour n'afficher que les incidents similaires à un incident spécifique
3. Trier par nombre de similaires : utilisez la colonne "Incidents similaires" pour trier les incidents par nombre le plus élevé ou le plus bas d'incidents similaires

Cette fonctionnalité est particulièrement utile pour :

• Identifier les faux positifs : repérer les schémas qui indiquent des incidents faux positifs
• Remédiation cohérente : appliquer la même approche de remédiation aux incidents qui nécessitent des correctifs similaires
• Comprendre les schémas d'incidents : découvrir les problèmes récurrents dans votre codebase

Une fois que vous avez identifié des incidents similaires, vous pouvez utiliser les actions en masse pour les résoudre, les assigner ou les tagger ensemble efficacement.

Nous valorisons vos retours

Le regroupement d'incidents similaires utilise des modèles de machine learning qui sont continuellement améliorés sur la base des retours utilisateurs. Si vous remarquez des incidents avec des regroupements inattendus, nous vous encourageons à partager vos retours directement via le dashboard — votre contribution nous aide à affiner le modèle de regroupement.

Prochaines étapes : passer à la remédiation

Une fois que vous avez terminé votre investigation et compris le contexte de l'exposition du secret, vous êtes prêt à commencer la remédiation. Votre investigation devrait vous avoir aidé à déterminer :

• Ce à quoi le secret accède - quels systèmes, services ou ressources
• Niveau de privilège - accès administratif, lecture seule ou portée limitée
• Dépendances - quelles applications ou services dépendent de ce secret
• Chronologie d'exposition - quand le secret a été exposé pour la première fois et pendant combien de temps
• Visibilité publique - si le secret est exposé publiquement

Choisir votre approche de remédiation

En fonction des résultats de votre investigation :

• Pour la plupart des incidents internes : suivez un workflow temps réel ou historique selon le moment où le secret a été détecté
• Pour les secrets à haut risque nécessitant une action immédiate : utilisez le scénario de réponse d'urgence
• Pour les scénarios complexes multi-équipes : considérez l'approche de remédiation en masse
• Pour les nouvelles détections avec développeurs disponibles : utilisez le workflow d'incident temps réel

Prêt à commencer la remédiation ?

• Vue d'ensemble de la remédiation - Comprendre la philosophie et l'approche de remédiation de GitGuardian
• Scénarios de remédiation - Workflows complets pour différentes situations
• Fonctionnalités de la plateforme - Outils GitGuardian pour la collaboration et l'automatisation

Rappel : le temps passé sur une investigation approfondie vous fera gagner du temps et réduira le risque pendant la remédiation. Ne vous précipitez pas dans la remédiation sans comprendre l'impact complet.