Gestion du périmètre surveillé
Découvrez comment 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 savoir quelles sources intégrer et comment elles se comparent, 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 bien plus encore.
Si votre workspace utilise le périmètre d'équipe, l'accès aux incidents suit les affectations d'équipe.
Utilisez votre page de périmètre pour :
- Mesurer dans quelle mesure GitGuardian couvre votre périmètre, avec le Coverage Hub
- Trouver les sources à risque : les sources ayant des incidents ouverts, et les sources non surveillées, inaccessibles ou non scannées
- Agir sur de nombreuses sources à la fois avec les actions groupées
- Définir la visibilité, la criticité et les équipes de vos sources
Le Coverage Hub résume votre couverture. Le tableau ci-dessous liste vos sources dans tous les statuts, triées par incidents ouverts. Filtrez sur Has open incidents pour ne conserver que les sources à risque.
Utilisez les vues enregistrées pour basculer entre des ensembles de filtres. GitGuardian fournit des vues non modifiables telles que « Monitored », « Critical sources », « With open secret incidents », « Scanning issues » et « Without honeytoken ». La vue par défaut « Monitored » liste les sources surveillées et inaccessibles. Utilisez le filtre Source status pour voir les autres.
Cliquez sur Columns pour afficher, masquer ou réorganiser les colonnes du tableau.
Suivre votre couverture avec le Coverage Hub
Quatre cartes au-dessus du tableau montrent dans quelle mesure GitGuardian couvre votre périmètre. Cliquez sur l'action d'une carte pour filtrer le tableau sur les sources correspondantes.
- Integrations : le nombre d'intégrations installées. Un badge rouge compte les sources inaccessibles. Cliquez sur Show more details pour voir les sources de chaque intégration.
- Real time monitoring : la proportion de vos sources dont la surveillance en temps réel est activée. À 100 %, chaque source que vous pouvez surveiller est surveillée. Un badge vert compte les sources ajoutées au cours des 30 derniers jours. Cliquez sur See unmonitored sources pour trouver les sources à surveiller.
- Historical scans : la proportion de vos sources dont le dernier scan historique a réussi. Cliquez sur See unscanned sources pour trouver les sources à scanner, ou sur See scan activity pendant l'exécution des scans.
- Team ownership : la proportion de vos sources surveillées qui appartiennent à une équipe. Cliquez sur See unassigned sources pour trouver les sources sans propriétaire. Les équipes sont disponibles dans les plans payants.
Si votre accès est restreint à certaines équipes, les cartes ne comptent que les sources de ces équipes.
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 de push (et ses commits) est scanné à la recherche de secrets dès qu'il arrive sur votre serveur VCS (hooks post-receive).
Nous utilisons le même concept pour d'autres sources de données, telles que Slack et Jira, grâce à l'abonnement à des événements spécifiques.
Nous vous alertons alors 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.
Le Coverage Hub montre la proportion de vos sources qui sont surveillées. Certaines sources peuvent ne pas être éligibles à la surveillance en raison de restrictions liées au plan.
Pour des raisons de performance, nous limitons le nombre de commits scannés par événement de push. Par défaut, cette limite est de 1 000 commits scannés/événement de 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 secret. 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 capacité de scanner l'historique des commits de toutes les sources que vous avez intégrées à GitGuardian.
La colonne Last scan montre le résultat du dernier scan de chaque source. Un scan Skipped ne s'est pas exécuté : survolez le badge pour en connaître la raison.
Des limitations 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 afin d'éviter de retraiter tout l'historique. Cependant, si la version du tokenscanner a changé depuis le dernier scan historique — GitGuardian ayant introduit de nouveaux détecteurs — le scan se poursuivra, même s'il n'y a pas de nouveaux commits.
Scanner les commits orphelins et les 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 exécutez 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 dépôt distant et récupère celles qui ne sont pas déjà couvertes.
Les espaces de noms suivants sont récupérés automatiquement :
| Espace de noms de référence | Ce qu'il contient | Fournisseur |
|---|---|---|
refs/pull/* | Commits de tête / de fusion 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 de tête / de fusion des pull requests | Bitbucket (Cloud & Data Center) |
refs/changes/* | Références de changements en attente et abandonnées | 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 le garbage collection (ex. commits de pipeline CI) | GitLab |
| Autres espaces de noms personnalisés | Tout ce que le dépôt distant expose par ailleurs (ex. refs/sandbox/*, refs/replace/*, …) | Tous les fournisseurs |
Erreurs potentielles lors du scan historique et leurs résolutions
| Raison | Message d'erreur | Étapes de résolution |
|---|---|---|
| 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 dispose d'une liste d'autorisation d'IP configurée. | Contactez le propriétaire de la source pour examiner et ajuster la liste d'autorisation d'IP. |
| Dépôt introuvable | La source est introuvable. 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 clone bloquée ou trop lente | La connexion au serveur est lente ou bloquée. | Contactez l'administrateur du VCS pour investiguer les problèmes de connexion au serveur. |
| VCS non prêt ou a 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 réessayez le scan. |
| Dépôt désactivé dans le projet GitLab | Le dépôt git du 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 sous 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'Admin area. |
| 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 éventuellement étendre la limite de temps du scan. Pour les environnements self-hosted, envisagez d'ajuster repo_scan_time_limit_in_sec dans les préférences de l'Admin area. |
| Timeout Pending | 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 groupé. Veuillez contacter notre support. | Contactez le support GitGuardian pour traiter les timeouts de scan groupé 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'Admin area. |
| Erreur du worker de scan | Le scan a échoué en raison d'une erreur interne du worker, souvent due à des limitations de mémoire. | Veuillez contacter notre équipe de 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. En outre, générez un Support Bundle à des fins de dépannage supplémentaires. |
| Erreur de moteur | Le scan a échoué en raison d'une erreur interne du moteur. | Veuillez contacter notre équipe de support. Si vous exécutez GitGuardian dans un environnement self-hosted, générez un Support Bundle à des fins de dépannage. |
| Le processus a reçu SIGKILL | Le processus de scan a été arrêté de force (SIGKILL). | Veuillez contacter notre équipe de 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) ne peuvent pas ê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 submodule mais que la référence donnée pour le submodule n'existe plus. Contactez le propriétaire de la source pour vérifier la configuration des submodules. |
| 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 lors d'une utilisation normale, mais si vous le rencontrez, veuillez contacter notre équipe de support. |
| Fichier d'image de conteneur introuvable dans le registre | Une couche de l'image de conteneur est introuvable dans le registre et n'a pas pu être téléchargée. | Vérifiez que l'image de conteneur existe toujours dans le registre et n'a pas été supprimée ou nettoyé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 terminer son installation dans le canal. Attendez quelques minutes que l'installation se termine et réessayez le scan. Si l'erreur persiste, confirmez que l'application GitGuardian pour Slack a bien été ajoutée au canal. |
| Inconnue | Le scan a échoué en raison d'une erreur inconnue. | Veuillez contacter notre équipe de 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 du VCS sont envoyés séparément.
Limites de débit sur les sources self-hosted
Certaines intégrations de sources imposent des limites de débit d'API. Pour les services SaaS tels que GitHub.com ou Slack, GitGuardian régule automatiquement son scan pour rester dans les limites connues du fournisseur, de sorte que vous n'avez rien à configurer.
Pour les sources self-hosted, les limites sont contrôlées par votre propre instance. Lorsque la limitation de débit est activée, les valeurs par défaut peuvent être assez basses et peuvent limiter les requêtes de GitGuardian, ralentissant considérablement les scans historiques et la détection en temps réel, ou provoquant une Erreur de limite de débit.
Pour scanner ces sources dans un délai raisonnable, nous vous recommandons soit de relever les limites de débit sur votre instance, soit d'exempter le compte, le token ou le compte de service que GitGuardian utilise de la limitation de débit. La plupart des plateformes vous permettent d'accorder une exemption par utilisateur ou une limite plus élevée sans modifier le paramètre global.
Les sources self-hosted suivantes vous permettent de configurer les limites de débit :
Sur les produits Atlassian Data Center (Bitbucket, Jira, Confluence), la limitation de débit est désactivée par défaut mais, une fois activée, s'applique au trafic de l'API REST. Ajoutez le compte GitGuardian comme exemption afin que son scan ne soit pas limité.
Statut de source
Chaque source de votre périmètre a un statut : Monitored, Unmonitored, Unreachable, Archived ou Deleted. Vous pouvez filtrer sur ce statut depuis la page de périmètre et la liste des incidents, et enregistrer le résultat sous forme de vue, par exemple pour mettre de côté les incidents des sources archivées ou supprimées.
Un secret valide dans une source archivée ou supprimée n'est pas nécessairement moins risqué. L'archivage ou la suppression de la source ne révoque pas le secret, alors traitez ces incidents selon leurs propres mérites.
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 la présence d'un plan qui prend en charge sa surveillance.
Les sources surveillées sont listées dans la vue « Monitored » de la page de périmètre.
Source non surveillée
Une source est considérée comme non surveillée lorsque GitGuardian n'écoute plus aucune activité sur cette source.
Cela peut être le résultat de :
- l'exclusion de la source du périmètre surveillé,
- ou d'un changement dans votre plan qui ne prend plus en charge cette source.
Une source non surveillée présente un risque, car aucune occurrence ne sera créée après qu'un secret y a été publié.
Une telle source est identifiée par une icône de bouclier barré à côté d'elle.
Pour lister les sources non surveillées sur la page de périmètre, réglez le filtre Source status sur Unmonitored, ou cliquez sur See unmonitored sources dans le Coverage Hub. Sélectionnez-les et utilisez l'action groupée Monitor pour les surveiller à nouveau.
Par défaut, désurveiller une source la retire de toutes ses équipes. En conséquence :
- les membres de ces équipes perdent l'accès aux incidents liés à cette source,
- et la source n'affiche plus aucune affectation d'équipe sur la page de périmètre.
Pour permettre aux équipes de conserver l'accès aux sources non surveillées, les managers peuvent désactiver le paramètre de périmètre d'équipe pour les sources non surveillées.
Seuls les managers et les owners peuvent surveiller ou désurveiller une source.
Source inaccessible
Une source est inaccessible lorsque GitGuardian ne peut pas s'y connecter, par exemple après l'expiration des identifiants, la révocation de l'accès ou une indisponibilité temporaire du fournisseur.
Tant qu'une source est inaccessible, GitGuardian met en pause l'ingestion en temps réel et les scans historiques sur celle-ci, puis les reprend automatiquement une fois la connectivité rétablie. GitGuardian fait également apparaître une étape de récupération actionnable pour que vous puissiez corriger le problème sous-jacent. Consultez le guide d'intégration approprié pour les étapes spécifiques au fournisseur.
Source archivée
Une source est considérée comme archivée lorsqu'elle a été archivée chez le fournisseur, par exemple un dépôt archivé sur GitHub. Aucune nouvelle activité n'est attendue sur une source archivée, mais ses incidents existants restent visibles afin que vous puissiez encore agir dessus.
Source supprimée
Une source est considérée comme supprimée uniquement lorsque GitGuardian reçoit la preuve de sa suppression réelle. 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. Ex. : le dépôt est supprimé sur GitHub.
Une telle source est identifiée par une icône de corbeille à côté d'elle.
Pour lister les sources archivées et supprimées sur la page de périmètre, réglez le filtre Source status sur Archived ou Deleted.
Les sources archivées et supprimées restent dans leurs périmètres d'équipe. Pour les retirer automatiquement des périmètres d'équipe, les managers peuvent activer les paramètres de périmètre d'équipe correspondants.
Visibilité de 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 exposé publiquement 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 en consulter le contenu. Une telle source est identifiée par une icône de cadenas à côté d'elle.
Criticité de 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 faible, moyenne, élevée ou critique, 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 aux ressources d'un environnement de production.
Équipes de source
Si votre workspace utilise les équipes, la colonne Teams montre les équipes de chaque source. Elle est affichée par défaut dans la vue « Monitored ».
Pour trouver les sources sans équipe, filtrez sur Team et choisissez No team assigned. Les sources personnalisées et les endpoints ne sont pas listés, car ils ne peuvent pas appartenir à une équipe.
Actions groupées sur les sources du périmètre
Les actions groupées sur la page de périmètre vous permettent de gérer plusieurs sources simultanément, rationalisant votre flux de travail de surveillance du périmètre.
Comment utiliser les actions groupées
- Accédez à votre page de périmètre.
- Sélectionnez des sources. La barre d'actions groupées apparaît au-dessus du tableau.
- Choisissez une action.
Utilisez la case à cocher de l'en-tête pour sélectionner toutes les sources de la page, puis cliquez sur Select all N sources that match filters pour sélectionner toutes les sources correspondant à vos filtres.
Actions disponibles
Gestion des sources
- Monitor : Commencer à surveiller les sources sélectionnées.
- Unmonitor : Arrêter de surveiller les sources sélectionnées. Désurveiller une source la retire également de toutes ses équipes, de sorte que les membres de ces équipes perdent l'accès aux incidents de la source (voir Source non surveillée).
- Assign team : Ajouter les sources sélectionnées à une équipe. Seules les sources surveillées sont ajoutées à l'équipe ; toute source non surveillée dans votre sélection est ignorée.
- Set criticality : Mettre à jour les niveaux de criticité métier (Critical, High, Medium, Low) pour plusieurs sources.
- Launch historical scan : Lancer des scans historiques sur les sources sélectionnées (si le scan est activé).
Une action est grisée lorsqu'elle ne s'applique pas à votre sélection. Survolez-la pour en connaître la raison.
Confirmer une action groupée
GitGuardian vous demande de confirmer Monitor, Unmonitor et Launch historical scan lorsque vous sélectionnez plus de 30 sources, ou lorsque certaines sources seront ignorées. La confirmation liste les sources ignorées et la raison, par exemple les sources déjà surveillées.
Bonnes pratiques
- Filtrez d'abord : Utilisez la recherche et les filtres pour affiner votre sélection de sources
- Vérifiez 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 source en fonction de l'impact métier et des environnements de production
- Scan : Tenez compte de la charge du système lors du lancement de scans historiques groupés (self-hosted)
Permissions
Les actions groupées sur les sources nécessitent des permissions de workspace appropriées :
- Manager : Peut surveiller et désurveiller les sources, affecter des sources à des équipes, mettre à jour la criticité des sources et lancer des scans.
- Member : Peut lancer des scans sur les sources du périmètre de son équipe mais ne peut pas surveiller ou désurveiller les sources, affecter des équipes, ni 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 :
- Comparaison des capacités entre tous les types de sources
- Guides d'intégration organisés par catégorie
- Conseils stratégiques sur la priorisation des intégrations
- Recommandations pour démarrer
L'aperçu comprend des informations détaillées sur toutes les intégrations disponibles, y compris les VCS, les registres de conteneurs, les plateformes de messagerie, les systèmes de documentation et les sources personnalisées.
Dépannage 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.
Au cas où vous auriez 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 de sortie via des endpoints d'API non authentifiés. Vous pouvez les utiliser pour maintenir automatiquement vos règles de pare-feu à jour :
- US :
GET https://api.gitguardian.com/v1/ips(Référence de l'API) - EU :
GET https://api.eu1.gitguardian.com/v1/ips(Référence de l'API)
GitGuardian US utilise les IP 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 (ex. : GitHub, GitLab)
- Intégrations de registres de conteneurs (ex. : Amazon ECR, Azure Container Registries, Docker Hub, Google Artifact Registry, JFrog Container Registry)
- Intégrations de messagerie (ex. : Slack, Microsoft Teams)
- Intégrations de ticketing (ex. : Jira Cloud, Jira Data Center, ServiceNow)
- Intégrations de documentation (ex. : Confluence Cloud, Confluence Data Center)
- Intégrations d'alerting (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é de mettre les domaines sur liste blanche à la place.
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.
