Examiner les incidents publics

Avant de prioriser ou de remédier à un incident de secret public, vous devez savoir ce qu'il représente et s'il est pertinent pour votre organisation, ce qui constitue la partie la plus difficile du travail avec les sources publiques. Cette page décrit le contexte fourni par GitGuardian sur chaque incident pour vous aider à répondre à cette question.

Les conclusions propres aux agents, le verdict Company-related et le risk score, sont traités séparément dans Analyse des agents.

Détail du secret

Chaque incident public fournit des informations détaillées sur le secret lui-même :

Informations sur le détecteur

Le détecteur identifie le type de secret trouvé. Cela vous aide à comprendre quel service ou système pourrait être compromis.

Validité du secret

GitGuardian effectue des contrôles de validité lorsque cela est possible pour déterminer si le secret détecté est toujours actif et utilisable. Les secrets valides présentent des risques de sécurité immédiats et, lorsqu'ils sont liés à votre entreprise, doivent être priorisés pour une remédiation rapide.

Résultats de l'analyseur de secret

Pour certains détecteurs, lorsque le secret est valide, notre analyseur de secret fournit un contexte supplémentaire sur les permissions et la portée du secret. Cette analyse vous aide à comprendre l'impact potentiel si le secret venait à être exploité.

Détail des occurrences

Le tableau des occurrences vous fournit les informations détaillées dont vous avez besoin :

• Identité de l'auteur : Le nom et l'e-mail de l'auteur Git associés au commit
• Horodatage du commit : Le moment où l'occurrence du secret a été committée
• Dépôt : Le dépôt GitHub où le secret a été trouvé
• Hash du commit : Le commit spécifique contenant le secret
• Chemin du fichier : Le fichier exact et l'emplacement au sein du dépôt
• Aperçu du patch : Un extrait de code montrant le secret dans son contexte (peut être masqué pour les patchs volumineux)
• Lien GitHub : Lien direct pour voir l'occurrence sur GitHub (lorsqu'elle est encore visible publiquement)
• Indicateur de présence : Indique si l'occurrence est toujours visible sur GitHub public. La valeur « removed from GitHub » indique généralement que le dépôt a été supprimé ou rendu privé après la fuite, ou que le commit lui-même a été supprimé.

attention

Le fait que l'occurrence ait été effacée de GitHub ne signifie pas que l'incident est résolu ! En effet, un acteur malveillant pourrait avoir cloné le dépôt et vu le secret avant qu'il ne soit effacé de GitHub.

Raisons de rattachement

Les raisons de rattachement expliquent pourquoi GitGuardian a associé un incident de secret public à votre organisation. Comprendre ces raisons aide à valider la pertinence de chaque incident :

• By developer from perimeter : L'un de vos développeurs surveillés est impliqué dans l'incident de secret.
• On organization from perimeter : L'incident de secret s'est produit sur un dépôt de l'une de vos organisations GitHub surveillées.
• From secret grasper : L'incident de secret a été rattaché à votre entreprise grâce à un secret grasper dans le commit.

info

Les raisons de rattachement donnent un aperçu de la probabilité qu'une fuite soit liée à votre organisation. Les incidents rattachés « By developer from perimeter » peuvent contenir des secrets de l'entreprise, mais pourraient tout aussi bien être des identifiants personnels sans rapport provenant de vos développeurs. En revanche, les incidents fuités « On organization from perimeter » sont liés à l'entreprise puisqu'ils proviennent des dépôts de votre organisation.

Tags et informations contextuelles

GitGuardian applique automatiquement des tags à chaque incident pour faire ressortir des détails utiles sur la fuite et l'endroit où elle a été trouvée. Ce sont des indices plutôt que des conclusions, et ils peuvent être utilisés dans les filtres et les vues enregistrées.

• Company domain in commit : L'un de vos domaines surveillés apparaît dans le contenu du fichier de l'occurrence.
• Company name in commit : Le nom de votre entreprise apparaît dans le patch où le secret est fuité.
• Secret grasper in commit : L'un de vos secret graspers définis (qui peuvent être considérés comme des identifiants spécifiques à l'entreprise) apparaît dans le patch de l'occurrence.
• Internally leaked : Ce tag (disponible uniquement si vous disposez également d'Internal Monitoring) indique que le même secret a été trouvé dans un incident interne au sein de vos sources surveillées. La carte d'exploration vous montrera l'incident interne associé. Dans Internal Monitoring, cette relation est affichée comme le type d'exposition Public incident linked sur les secrets fuités en interne. Consultez Informations sur l'exposition publique pour plus de détails.
• Sensitive file : L'une des occurrences de l'incident s'est produite sur un fichier potentiellement sensible
• Production : Le commit associé à l'une des occurrences semble lié à un environnement de production.
• Test file : L'une des occurrences de l'incident s'est produite sur un fichier de test potentiel. Un fichier est automatiquement classé comme fichier de test si son chemin contient l'un des motifs suivants (avec uniquement des chiffres ou des caractères spéciaux autour d'eux) : test/tests, example/examples, mock/mocks, fixture/fixtures, fake, dummy, false ou testdata. Par exemple, .test.env ou 00testdata.json correspondront, mais dummydata.json ne correspondra pas.
• False positive : Le moteur ML de GitGuardian a identifié qu'il ne s'agit probablement pas d'un secret réel. Ces incidents peuvent généralement être ignorés en toute sécurité. (En savoir plus ici)
• From historical scan : L'incident a été découvert lors d'un scan historique plutôt que par surveillance en temps réel.

Comportement précédent

Sur les workspaces qui n'ont pas encore basculé vers l'analyse des agents, un tag Context related to company apparaît également : le moteur ML de GitGuardian signale les fuites dont le contexte environnant semble lié à votre entreprise, sur la base de termes spécifiques à l'entreprise ou d'indicateurs de niveau entreprise. L'analyse des agents le remplace.

Carte d'exploration

info

Cette fonctionnalité apporte le plus de valeur lorsque vous utilisez également Internal Monitoring, NHI Governance, ou que vous avez intégré vos gestionnaires de secrets à l'aide de GitGuardian Scout pour un contexte complet.

La carte d'exploration fournit une représentation visuelle des endroits où GitGuardian a détecté ce secret spécifique à travers vos sources intégrées et de l'accès qu'il accorde potentiellement.

La carte peut révéler :

• Incidents internes (si vous utilisez Internal Monitoring) : Si le secret apparaît également dans votre base de code interne, vos tickets JIRA, vos messages Slack ou d'autres sources internes
• Stockage dans un gestionnaire de secrets (si vous avez intégré des gestionnaires de secrets) : Si le secret est stocké dans vos coffres-forts ou gestionnaires de secrets
• Utilisation dans l'infrastructure (si vous utilisez NHI Governance avec des intégrations d'infrastructure) : Si le secret est utilisé dans des sources d'infrastructure comme GitLab CI ou les clusters Kubernetes

Un signal fort de lien avec l'entreprise

Pour les incidents de secret public, une carte d'exploration affichant plusieurs nœuds constitue une preuve solide que le secret appartient réellement à votre entreprise et nécessite une remédiation immédiate.

Regroupement d'incidents similaires par ML

GitGuardian regroupe automatiquement les incidents qui partagent des caractéristiques similaires, afin que vous puissiez repérer les schémas récurrents et traiter les incidents associés ensemble. Sur un incident public, vous obtenez une section Similar incidents dans la barre latérale, une colonne Similar incidents triable dans le tableau des incidents, et un opérateur de recherche similar_to.

Consultez le regroupement d'incidents similaires pour comprendre comment fonctionne le regroupement.