Gestion du périmètre surveillé
Apprenez à gérer, surveiller et dépanner efficacement vos sources intégrées à l'aide du dashboard et des outils de périmètre de GitGuardian.
Pour obtenir des conseils sur les sources à intégrer et leur comparaison, consultez notre Aperçu de l'intégration des sources.
Comprendre votre périmètre
Votre périmètre englobe toutes les sources que vous avez intégrées à GitGuardian pour la surveillance des secrets. Cela inclut les dépôts, les registres de conteneurs, les plateformes de messagerie, les systèmes de documentation, et plus encore.
Si votre workspace utilise le périmètre d'équipe, l'accès aux incidents suit les affectations d'équipe.
Votre page de périmètre a deux objectifs principaux :
- Identifier celles de vos sources qui sont à risque
- S'assurer que l'ensemble de votre périmètre est bien protégé par GitGuardian
Pour une navigation efficace dans le tableau du périmètre, les utilisateurs peuvent tirer parti des vues enregistrées pour basculer entre différents ensembles de filtres. La fonctionnalité inclut des vues GitGuardian non modifiables telles que « All sources », « Critical sources », « Scanning issues », « With open secret incidents », « Without honeytoken ».
Différences entre le scan historique et la protection en temps réel
Surveillance en temps réel
La première protection et la plus efficace pour la remédiation des secrets est la surveillance en temps réel.
Comme vous avez pu le lire dans notre section Fonctionnement d'Internal Monitoring, la surveillance en temps réel signifie que chaque événement push (et ses commits) est scanné à la recherche de secrets dès son arrivée sur votre serveur VCS (post-receive hooks).
Nous utilisons le même concept pour d'autres sources de données, telles que Slack et Jira, via la souscription à des événements spécifiques.
Nous vous alertons ensuite instantanément, ce qui vous fera gagner du temps dans le processus de remédiation. En effet, plus un secret est exposé longtemps, plus la remédiation devient difficile.
Dans le panneau latéral droit, nous indiquons le pourcentage de sources couvertes, en fonction du nombre de sources que vous avez intégrées à GitGuardian. Notez que certaines sources peuvent ne pas être éligibles à la surveillance en raison de restrictions de plan.
Notez que le tableau des sources affiché sur la page Perimeter ne contient que les sources qui sont surveillées en temps réel. Les sources qui ne sont pas sélectionnées dans la page de paramètres d'intégration ne sont pas affichées.
Pour des raisons de performance, nous limitons le nombre de commits scannés par événement push. Par défaut, cette limite est de 1 000 commits scannés/événement push, mais elle peut être personnalisée par workspace sur demande.
Scan incrémental
GitGuardian fournit une protection continue grâce à des scans automatisés planifiés de votre contenu lorsque l'intégration ne prend pas en charge les Webhooks.
Le contenu nouveau et modifié est systématiquement surveillé à intervalles réguliers, garantissant une couverture complète et une détection rapide de toute exposition de secrets. Votre source reste sous la protection de GitGuardian, vous donnant l'assurance que les secrets ne passeront pas inaperçus.
Scan historique
Le deuxième type de protection offert est la possibilité de scanner l'historique des commits de toutes les sources que vous avez intégrées à GitGuardian.
Des limites de taille s'appliquent aux scans historiques, selon votre plan :
- Free : vous pouvez scanner des sources jusqu'à 1 Go,
- Business et essai : vous pouvez scanner des sources jusqu'à 12 Go.
Pour des raisons de performance, si un scan historique est demandé pour un dépôt qui n'a eu aucun nouveau commit sur aucune branche depuis le dernier scan historique, GitGuardian ignorera le scan pour éviter de retraiter tout l'historique. Toutefois, si la version du tokenscanner a changé depuis le dernier scan historique — GitGuardian ayant introduit de nouveaux détecteurs — le scan sera effectué, même s'il n'y a pas de nouveaux commits.
Scan des commits orphelins et des références Git supplémentaires lors des scans historiques
Un git clone standard ne récupère que les branches (refs/heads/*) et les tags (refs/tags/*). Lorsque vous lancez un scan historique sur un système de contrôle de version, GitGuardian va plus loin : après le clone initial, il inspecte chaque référence exposée par le serveur distant et récupère celles qui ne sont pas déjà couvertes.
En pratique, les espaces de noms suivants sont désormais pris en compte automatiquement :
| Espace de noms de référence | Ce qu'il contient | Fournisseur |
|---|---|---|
refs/pull/* | Commits head / merge des pull requests ouvertes, fermées et fusionnées | GitHub, Azure DevOps |
refs/merge-requests/* | Commits des merge requests ouvertes, fermées et fusionnées | GitLab |
refs/pull-requests/* | Commits head / merge des pull requests | Bitbucket (Cloud & Data Center) |
refs/changes/* | Références de changements en attente et abandonnés | Gerrit |
refs/notes/* | Notes Git (refs/notes/commits et tout espace de noms de notes personnalisé) | Tous les fournisseurs |
refs/keep-around/* | Références que GitLab conserve pour empêcher la garbage collection (par ex. commits de pipelines CI) | GitLab |
| Autres espaces de noms personnalisés | Toute autre référence exposée par le serveur distant (par ex. refs/sandbox/*, refs/replace/*, …) | Tous les fournisseurs |
Ce que cela vous apporte :
- Les commits orphelins ne sont plus invisibles : les secrets dans des commits qui ne vivent que dans une pull/merge request fermée, ou qui ont été supprimés de l'historique d'une branche par force-push, sont désormais détectés.
- Les secrets dans les notes Git sont détectés : tout secret stocké dans une note Git attach ée à un commit (via
git notes add) est désormais scanné comme du contenu de commit ordinaire. - Meilleure couverture sur GitLab et Gerrit : les keep-around refs et les références de changements Gerrit sont désormais inclus, de sorte que les commits réservés à la CI et les changements abandonnés sont couverts.
Les scans préexistants ne sont pas retraités rétroactivement — vous devez déclencher un nouveau scan historique pour bénéficier de la couverture supplémentaire. Disponible à partir de la version Self-Hosted 2026.6.0.
Erreurs potentielles lors du scan historique et leurs résolutions
| Raison | Message d'erreur | Étapes pour résoudre |
|---|---|---|
| Retrait DMCA | La source est indisponible en raison d'un retrait DMCA. | Contactez le propriétaire de la source pour discuter du retrait DMCA. |
| L'accès au dépôt est désactivé | La source a été désactivée. | Contactez le propriétaire de la source pour demander la réactivation de l'accès au dépôt. |
| Le compte a été désactivé | Le compte de la source a été désactivé. | Contactez le propriétaire de la source pour résoudre les problèmes de compte et retrouver l'accès. |
| Accès au dépôt restreint par IP | Le compte de la source a une liste d'IP autorisées configurée. | Contactez le propriétaire de la source pour examiner et ajuster la liste d'IP autorisées. |
| Dépôt introuvable | La source n'a pas pu être trouvée. Veuillez réessayer et contacter le propriétaire de la source si le problème persiste. | Vérifiez l'URL du dépôt et réessayez. Contactez le propriétaire de la source si le problème persiste. |
| Opération de clonage bloquée ou trop lente | La connexion au serveur est lente ou bloquée. | Contactez l'administrateur du VCS pour examiner les problèmes de connexion au serveur. |
| VCS non prêt ou ayant répondu avec une erreur | Le serveur n'a pas répondu après plusieurs tentatives. | Contactez l'administrateur du VCS pour vous assurer que le serveur est opérationnel et relancez le scan. |
| Dépôt désactivé dans le projet GitLab | Le dépôt git dans le projet GitLab a été désactivé. | Activez la fonctionnalité « repository » dans les paramètres du projet GitLab. |
| Le dépôt a été supprimé | Le dépôt cible a été supprimé. | Contactez l'administrateur du VCS pour confirmer et traiter la suppression du dépôt. |
| Erreur d'authentification VCS | L'authentification au VCS a échoué. | Vérifiez le token d'authentification dans Settings > Integrations et contactez l'administrateur du VCS si nécessaire. |
| Erreur de limite de débit | La limite de débit a été dépassée. | Attendez la réinitialisation de la limite de débit ou contactez l'administrateur du VCS pour une résolution. |
| Trop volumineux | Le scan historique a échoué car il a dépassé la limite de taille autorisée. | Contactez le support GitGuardian pour discuter des options de scan de dépôts plus volumineux. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_size_limit dans les préférences de l'espace Admin. |
| Timeout | Le scan historique a échoué en raison d'une erreur de timeout car il a dépassé la limite de temps autorisée pour un scan individuel. | Contactez le support GitGuardian pour le dépannage et pour potentiellement étendre la limite de temps de scan. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_time_limit_in_sec dans les préférences de l'espace Admin. |
| Timeout en attente | Le scan historique a échoué en raison d'une erreur de timeout car il a dépassé la limite de temps autorisée pour un scan en masse. Veuillez contacter notre support. | Contactez le support GitGuardian pour résoudre les timeouts de scans en masse et explorer des solutions alternatives. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_pending_limit_in_hours dans les préférences de l'espace Admin. |
| Erreur du worker de scan | Le scan a échoué en raison d'une erreur interne du worker, souvent causée par des limitations de mémoire. | Veuillez contacter notre équipe support. Si vous exécutez GitGuardian dans un environnement self-hosted, envisagez d'augmenter l'allocation de mémoire pour les workers afin de résoudre le problème. De plus, générez un Support Bundle pour faciliter le dépannage. |
| Erreur de moteur | Le scan a échoué en raison d'une erreur interne du moteur. | Veuillez contacter notre équipe support. Si vous exécutez GitGuardian dans un environnement self-hosted, générez un Support Bundle à des fins de dépannage. |
| Processus ayant reçu SIGKILL | Le processus de scan a été terminé de force (SIGKILL). | Veuillez contacter notre équipe support. Si vous exécutez GitGuardian dans un environnement self-hosted, générez un Support Bundle à des fins de dépannage. |
| Nom de fichier trop long | Un nom de fichier dans le dépôt est trop long. | En raison de limitations internes, les dépôts contenant des noms de fichiers de plus de 255 octets (environ > 200 caractères, selon les caractères utilisés) empêchent les dépôts d'être scannés. Vous pouvez trouver ces fichiers avec des commandes telles que find . -type f | awk -F/ '{if(length($NF)>200) print}'. |
| Référence Git introuvable | La référence n'existe plus. | Cela se produit généralement si le dépôt utilise un sous-module mais que la référence donnée pour le sous-module n'existe plus. Contactez le propriétaire de la source pour vérifier la configuration des sous-modules. |
| Limite de sécurité atteinte | La source a trop de problèmes à scanner. | Une limite de sécurité de 200 000 incidents par source est en place. Ce seuil est peu susceptible d'être atteint en utilisation normale, mais si vous le rencontrez, veuillez contacter notre équipe support. |
| Fichier d'image conteneur introuvable dans le registre | Une couche de l'image conteneur n'a pas été trouvée dans le registre et n'a pas pu être téléchargée. | Vérifiez que l'image conteneur existe toujours dans le registre et n'a pas été supprimée ou collectée par le garbage collector. |
| Application Slack absente du canal | L'installation du canal est peut-être encore en cours. Veuillez réessayer plus tard. | L'application GitGuardian pour Slack est peut-être encore en train de finaliser son installation dans le canal. Attendez quelques minutes la fin de l'installation et relancez le scan. Si l'erreur persiste, confirmez que l'application GitGuardian pour Slack a été ajoutée au canal. |
| Inconnu | Le scan a échoué en raison d'une erreur inconnue. | Veuillez contacter notre équipe support. Si vous exécutez GitGuardian dans un environnement self-hosted, générez un Support Bundle à des fins de dépannage. |
Le scan historique est également disponible pour Slack. Vous pouvez scanner l'intégralité de l'historique de vos canaux Slack publics et privés surveillés. Les conversations et les canaux archivés ne sont pas pris en charge.
Notez que le scan historique est soumis à la limitation de débit de l'API de Slack. Nous pouvons scanner jusqu'à 10 000 messages/min par workspace Slack.
Les rapports de scan historique de Slack et de VCS sont envoyés séparément.
Statut de la source
Source surveillée
Une source est considérée comme surveillée lorsque la plateforme GitGuardian écoute toute activité sur cette source.
C'est le résultat de :
- l'intégration réussie de GitGuardian avec la source
- et d'un plan qui prend en charge sa surveillance.
Les sources surveillées sont listées sur la page Perimeter.
Source qui n'est plus surveillée
Une source est considérée comme n'étant plus surveillée lorsque GitGuardian n'écoute plus aucune activité sur cette source.
Cela peut être le résultat de :
- la désinstallation de GitGuardian de la source,
- ou l'exclusion de la source du périmètre surveillé,
- ou un changement dans votre plan qui ne prend plus en charge cette source.
Une source qui n'est plus surveillée présente un risque, car aucune occurrence ne sera créée après la publication d'un secret dans celle-ci.
Une telle source est identifiée par une icône de bouclier barré à côté d'elle.
Les sources qui ne sont plus surveillées ne sont plus listées sur la page Perimeter.
Source supprimée
Une source est considérée comme supprimée uniquement lorsque GitGuardian reçoit la preuve de sa suppression effective. Cela signifie que nous ne considérons pas une source comme supprimée simplement parce qu'elle a été retirée de GitGuardian, mais uniquement lorsqu'elle a été véritablement effacée. Par exemple : le dépôt est supprimé sur GitHub.
Une telle source est identifiée par une icône de corbeille à côté d'elle.
Les sources supprimées ne sont plus listées sur la page Perimeter.
Visibilité de la source
Une source est définie par une portée de visibilité. Selon l'instance installée, une source peut être :
public: toute personne ayant accès à Internet peut consulter le contenu de cette source. Votre secret est publiquement exposé et présente un risque de sécurité plus élevé.internal(spécifique à GitLab) : les projets GitLab internes peuvent être consultés par tout utilisateur authentifié, à l'exception des utilisateurs externes. Un tel projet GitLab est identifié par une icône de bouclier à côté de lui.private: seuls les utilisateurs autorisés ayant accès à la source peuvent consulter son contenu. Une telle source est identifiée par une icône de cadenas à côté d'elle.
Criticité de la source
La fonctionnalité de criticité de source vous permet d'évaluer et d'attribuer un niveau d'importance à vos sources surveillées, vous aidant à prioriser efficacement vos incidents. Cette fonctionnalité vous permet de les catégoriser comme low, medium, high ou critical, ou de la laisser non renseignée, en fonction de la gravité potentielle de l'impact d'un incident de sécurité. Sa valeur dépend du contexte métier de votre source, qui sera déterminé par des facteurs tels que la nature des données traitées et sa connexion à des ressources dans un environnement de production.
Actions en masse sur les sources du périmètre
Les actions en masse sur la page de périmètre vous permettent de gérer plusieurs sources simultanément, rationalisant votre flux de surveillance du périmètre.
Comment utiliser les actions en masse
- Naviguez vers votre page de périmètre
- Sélectionnez plusieurs sources à l'aide des cases à cocher
- La barre d'outils des actions en masse apparaît en haut
- Choisissez l'action souhaitée
Utilisez la case à cocher d'en-tête pour sélectionner toutes les sources de la page, ou cliquez sur « Select all X sources » pour sélectionner toutes celles qui correspondent à vos filtres actuels.
Actions disponibles
Gestion des sources
- Set criticality : mettez à jour les niveaux de criticité métier (Critical, High, Medium, Low) pour plusieurs sources
- Scan : lancez des scans historiques sur les sources sélectionnées (si le scan est activé)
Bonnes pratiques
- Filtrer d'abord : utilisez la recherche et les filtres pour affiner votre sélection de sources
- Vérifier la sélection : le bouton « Select all » ne sélectionne que les sources affichées. Utilisez « Select all sources that match the filters » pour sélectionner l'ensemble de la sélection.
- Évaluation de la criticité : définissez la criticité de la source en fonction de l'impact métier et des environnements de production
- Scan : tenez compte de la charge système lors du lancement de scans historiques en masse (self-hosted)
Permissions
Les actions en masse sur les sources nécessitent les permissions appropriées dans le workspace :
- Manager : peut effectuer des mises à jour de criticité de source et lancer des scans
- Member : peut lancer des scans sur les sources dans le périmètre de son équipe, mais ne peut pas mettre à jour la criticité des sources.
Ajouter de nouvelles sources à votre périmètre
Pour étendre votre périmètre surveillé avec de nouvelles intégrations, consultez notre Aperçu de l'intégration des sources complet qui fournit :
- Une comparaison des capacités pour tous les types de sources
- Des guides d'intégration organisés par catégorie
- Des conseils stratégiques sur la priorisation des intégrations
- Des recommandations pour démarrer
L'aperçu inclut des informations détaillées sur toutes les intégrations disponibles, y compris VCS, registres de conteneurs, plateformes de messagerie, systèmes de documentation et sources personnalisées.
Résolution des problèmes de connectivité
Le plus souvent, les problèmes de connectivité surviennent parce qu'un pare-feu, un serveur proxy, un réseau d'entreprise ou un autre réseau est configuré d'une manière qui bloque GitGuardian.
Si vous avez besoin d'autoriser les connexions entrantes/sortantes vers/depuis l'application SaaS, ce paragraphe fournit les informations nécessaires.
Autoriser les connexions entrantes depuis les adresses IP de GitGuardian
GitGuardian expose ses adresses IP sortantes via des endpoints d'API non authentifiés. Vous pouvez les utiliser pour maintenir vos règles de pare-feu synchronisées automatiquement :
- US :
GET https://api.gitguardian.com/v1/ips(référence API) - EU :
GET https://api.eu1.gitguardian.com/v1/ips(référence API)
GitGuardian US utilise les IPs suivantes :
- 35.161.89.114/32
- 35.162.178.46/32
- 35.163.105.95/32
- 35.83.131.170/32
- 44.224.13.10/32
- 44.231.207.147/32
- 44.239.165.162/32
- 52.25.45.243/32
- 54.184.247.227/32
- 54.188.183.19/32
- 54.189.40.226/32
- 54.212.233.107/32
GitGuardian EU utilise les adresses IP suivantes :
- 18.153.164.184/32
- 18.158.109.52/32
- 18.184.72.235/32
- 18.198.133.200/32
- 3.127.11.54/32
- 3.64.118.208/32
- 3.75.125.128/32
- 3.76.233.226/32
- 52.28.29.48/32
Ces adresses IP sont utilisées pour :
- Intégrations VCS (par ex. : GitHub, GitLab)
- Intégrations de registres de conteneurs (par ex. : Amazon ECR, Azure Container Registries, Docker Hub, Google Artifact Registry, JFrog Container Registry)
- Intégrations de messagerie (par ex. : Slack, Microsoft Teams)
- Intégrations de ticketing (par ex. : Jira Cloud, Jira Data Center, ServiceNow)
- Intégrations de documentation (par ex. : Confluence Cloud, Confluence Data Center)
- Intégrations d'alerting (par ex. : Slack, Microsoft Teams, PagerDuty, ...)
- Contrôles de validité
Autoriser les connexions sortantes vers les domaines de GitGuardian
Les requêtes vers GitGuardian utilisent des adresses IP qui changent régulièrement. Il est conseillé d'ajouter les domaines à la liste blanche plutôt que les IPs.
Les domaines suivants sont utilisés par GitGuardian US :
- dashboard.gitguardian.com
- hook.gitguardian.com
- api.gitguardian.com
Les domaines suivants sont utilisés par GitGuardian EU :
- dashboard.eu1.gitguardian.com
- hook.eu1.gitguardian.com
- api.eu1.gitguardian.com
Tous les endpoints utilisent HTTPS. HTTP est exclusivement utilisé pour rediriger vers HTTPS.
