Découvrir vos NHIs

Inventaire des NHIs

L'inventaire fournit un tableau centralisé et interrogeable répertoriant toutes les Non-Human Identities découvertes dans votre périmètre. Cette vue dynamique vous aide à surveiller, auditer et trier efficacement les NHIs à travers divers environnements et sources.

Aperçu du tableau d'inventaire

Chaque ligne de l'inventaire représente une NHI unique et affiche les attributs clés suivants :

• Secret name – L'identifiant du secret associé.
• Validity : Indique si le secret fonctionne toujours, tel que vérifié par ggscout auprès de son fournisseur : Valid, Invalid, Failed to check, Unknown (pas encore vérifié) ou No checker. Survolez le tag pour afficher la date de la vérification. Voir Validité et permissions des secrets.
• Detector : Le détecteur du Secrets Detection Engine qui a classifié le secret, ou Unknown si aucun ne correspond.
• Source – L'intégration où la NHI a été découverte (par exemple, le nom du gestionnaire de secrets ou du cluster Kubernetes).
• Path – Le chemin ou l'emplacement exact du secret au sein de la source.
• Environment – Les environnements des secrets de cette NHI (production, pré-production, staging, testing ou development). L'environnement de chaque secret est inféré à partir de son chemin, de ses tags et de ses labels, avec l'env de la source comme solution de repli, de sorte qu'une identité dont les secrets résident dans plusieurs environnements affiche plusieurs valeurs. Voir Environnement ci-dessous.
• Breached policies – Toute mauvaise configuration détectée ou violation des bonnes pratiques de sécurité. En savoir plus sur les politiques enfreintes
• Identity level – Indique si la NHI détient des permissions de niveau administrateur sur sa source (par exemple un principal AWS IAM avec AdministratorAccess, un Microsoft Entra Global Administrator ou un Okta Super Admin). Les identités admin sont marquées d'un badge dédié dans la vue détaillée. En savoir plus
• Risk criticality – Un niveau agrégé (low, medium, high, critical) combinant la violation de politique au risque le plus élevé sur l'identité avec des modificateurs pour le statut admin et l'exposition en production. En savoir plus
• Owners – La ou les personnes responsables de la NHI. Voir Propriété des NHIs ci-dessous.

L'inventaire prend en charge le filtrage basé sur :

• Validity : Valid, Invalid ou Unknown (tout statut autre que valide ou invalide)
• Détecteur : n'importe quel détecteur, ou Unknown
• Type de détecteur : Generic, Specific ou Unknown
• Famille de secret
• Catégorie de secret
• Fournisseur de secret
• Politique enfreinte
• Environnement
• Source
• Identity level : Admin ou Non-admin
• Risk criticality : Critical, High, Medium ou Low
• Owner : par propriétaire spécifique, No owner ou Current user

Les filtres liés aux détecteurs (détecteur, type de détecteur, famille de secret, catégorie et fournisseur) sont les mêmes facettes que celles utilisées sur les incidents de secret, de sorte que vous pouvez poser les mêmes questions sur les secrets stockés dans des coffres que sur les fuites. En savoir plus sur les catégories et les fournisseurs.

Mettez à niveau ggscout vers la version 0.34.1 ou ultérieure

La classification par détecteur nécessite ggscout 0.32.0 ou ultérieur, et la validité et les permissions nécessitent la version 0.34.1 ou ultérieure. Jusqu'à ce que vous effectuiez la mise à niveau, les secrets collectés restent non classifiés et leur validité reste Unknown. Après la mise à niveau, la prochaine récupération classifie et vérifie l'inventaire existant. Aucune configuration supplémentaire n'est requise.

Cliquer sur une NHI ouvre une vue détaillée qui inclut le détecteur, la validité, les permissions, les violations de politiques, la version du secret et une carte visuelle des relations et du contexte de la NHI.

Notez que si une version est supprimée, les métadonnées demeurent mais le graphe est vide et marqué comme supprimé, tandis que les secrets entièrement détruits disparaissent de l'inventaire.

Validité et permissions des secrets

Pour chaque secret qu'il collecte, ggscout demande au fournisseur si l'identifiant fonctionne toujours et ce qu'il permet de faire, depuis l'intérieur de votre réseau. L'inventaire affiche le résultat sans aucune action de votre part :

• Validity indique si le secret peut encore s'authentifier. Une identité affiche le dernier verdict Valid ou Invalid parmi ses secrets. Si le même secret figure aussi dans un incident de secret, la validité de cet incident (y compris un statut de validité personnalisé) compte comme une vérification supplémentaire, et la plus récente l'emporte.
• Permissions liste les scopes accordés par le fournisseur à l'identifiant, comme repo et admin:org pour un token GitHub ou api pour un token GitLab.
• Owner et expiry affichent le compte côté fournisseur derrière l'identifiant, avec son indicateur admin lorsqu'il est connu, ainsi que la date d'expiration lorsque le fournisseur en définit une.

Utilisez le filtre Validity pour lister les secrets Invalid encore présents dans vos coffres-forts et les nettoyer, ou triez par validité pour afficher en premier les identifiants actifs. Dans la vue détaillée, les permissions vous indiquent l'étendue des dégâts si le secret fuite, avant que vous ne décidiez de l'urgence de sa rotation.

La vérification s'exécute dans ggscout, et non depuis les serveurs de GitGuardian. C'est ce qui lui permet de fonctionner pour les fournisseurs self-hosted et les services qui n'acceptent que le trafic de votre réseau. Elle est activée par défaut et peut être désactivée par déploiement. Consultez Vérifier la validité et les permissions à la source pour savoir ce qui est vérifié, ce qui est envoyé et comment la désactiver.

Environnement

GitGuardian attribue un environnement à chaque secret. L'environnement pilote la colonne et le filtre Environment de l'inventaire, la politique Cross-Environment Secrets et le modificateur de production de Risk criticality.

Comment l'environnement est résolu

Pour chaque secret, GitGuardian lit les éléments suivants, dans l'ordre, et s'arrête à la première correspondance :

1. Le chemin du secret.
2. Les tags attachés au secret.
3. Les labels attachés au secret.
4. L'env déclaré pour la source dans la configuration ggscout.

Lorsque rien ne se résout à partir du chemin, des tags ou des labels, l'« env » est hérité de la source. Lorsque la source n'a pas non plus d'env, le secret n'a pas d'environnement défini.

Environnements reconnus et alias

• Production : production, prod, prd, live, et toute valeur commençant par prod- (comme prod-eu)
• Pré-production : pre-production, pre-prod, preprod, preproduction
• Staging : staging, stage, stg
• Testing : testing, test, qa, sit, int, uat, sandbox, demo
• Development : development, dev, local

Les chemins utilisent un vocabulaire plus restreint : live, sit, int, demo et local sont aussi souvent utilisés comme noms de variables que comme environnements, ils sont donc ignorés dans les chemins. L'env de la source accepte les cinq noms complets ainsi que les alias listés sur la page de configuration ggscout.

Ce que chaque source apporte

• Path : HashiCorp Vault (namespace, KV mount et path), Akeyless (dossier), AWS Secrets Manager (nom du secret), CyberArk Secrets Manager SaaS et Self-Hosted (policy branch). Les chemins ne sont pas lus sur Azure Key Vault, Delinea Secret Server, Google Cloud Secret Manager ou Kubernetes.
• Tags et labels : HashiCorp Vault KV v2 custom_metadata, tags de ressource AWS Secrets Manager, tags de secret Azure Key Vault, labels et annotations Google Cloud Secret Manager, annotations CyberArk, item_tags Akeyless, labels Kubernetes Secret, environment_scope GitLab CI et le tag environment GitHub Actions. Les tags Azure Key Vault, environment_scope GitLab CI et item_tags Akeyless nécessitent ggscout 0.33.0 ou ultérieur.
• Rien : Delinea Secret Server n'expose ni chemin lisible ni tags, de sorte que ses secrets prennent l'env de la source.

Règles de chemin

• Seuls les segments de chemin entiers comptent : vault/prod/db et vault/prod-eu/db se résolvent en production, tandis que dev-tools/prod-db ne résout rien.
• Lorsque plusieurs segments correspondent, le plus profond l'emporte.
• int, sit, live, demo et local sont ignorés dans les chemins. Ils comptent toujours dans les tags et les labels.

Règles de tags et de labels

• Un tag est lu lorsque le dernier segment de sa clé est env, environment, stage ou tier (ainsi finops:environment fonctionne), ou lorsque la clé est deployment.environment.name ou environment_scope.
• Lorsque plusieurs clés correspondent, celle qui est la moins namespacée l'emporte : env l'emporte sur finops:env.
• Les tags sont lus avant les labels. Un label n'est lu que lorsqu'aucun tag ne se résout, de sorte qu'un tag environment=staging l'emporte sur un label env=prod.
• Les labels ne sont lus que sous la forme key:value ou key=value, et leur clé suit les mêmes règles qu'une clé de tag.

Propriété des NHIs

La propriété attribue la responsabilité de chaque NHI à une ou plusieurs personnes de votre organisation : vous pouvez voir qui est responsable d'une identité, filtrer l'inventaire par propriétaire, et ajouter ou modifier des propriétaires manuellement.

Propriétaires suggérés vs manuels

• Propriétaires suggérés – GitGuardian peut suggérer automatiquement des propriétaires en utilisant les données de vos sources intégrées et des incidents de secret. Les propriétaires suggérés sont étiquetés comme Set automatically by GitGuardian dans la vue détaillée de la NHI. Vous pouvez les conserver, les supprimer ou ajouter d'autres propriétaires.
• Propriétaires manuels – Tout propriétaire que vous ajoutez ou confirmez vous-même est étiqueté Set manually. Les attributions manuelles ne sont jamais écrasées par les suggestions automatiques.

Comment les propriétaires sont suggérés

Les suggestions sont basées sur plusieurs signaux, par ordre de confiance (le plus élevé en premier) :

1. Champ owner direct – La source de la NHI expose un propriétaire explicite pour l'identité (par exemple un champ owner IAM ou IdP).
2. Tags de métadonnées – Un tag sur la ressource contient un propriétaire (par exemple un tag AWS IAM ou Azure avec un e-mail).
3. Propriétaire au niveau de la source – L'intégration a un propriétaire déclaré (par exemple l'utilisateur qui a configuré l'intégration).
4. Dernier éditeur ou créateur – La personne qui a modifié ou créé la ressource en dernier, lorsque la source le fournit.
5. Committer de l'incident – Un développeur qui a commité un secret ayant conduit à un incident lié à cette NHI (privé ou public).
6. Scan de secrets publics – L'utilisateur dont le scan a détecté le secret associé à cette NHI.

Lorsque plusieurs candidats existent, le système ne conserve que ceux ayant la confiance la plus élevée. Vous pouvez avoir jusqu'à 5 propriétaires par NHI.

Qui peut être propriétaire

• Un membre du workspace (lié à son utilisateur GitGuardian).
• Un utilisateur externe identifié par e-mail (par exemple un prestataire ou une personne d'une autre équipe). Aucun compte GitGuardian n'est requis.

Gestion des propriétaires

• Dans l'inventaire, la colonne Owner affiche jusqu'à deux propriétaires par NHI ; utilisez le filtre Owner pour affiner la liste (par exemple No owner, Current user ou une personne spécifique).
• Dans la vue détaillée d'une NHI, utilisez la section Owners pour ajouter, supprimer ou remplacer des propriétaires. Vous pouvez saisir un membre du workspace ou toute adresse e-mail valide pour ajouter un propriétaire externe. Supprimer un propriétaire suggéré écarte cette suggestion afin qu'elle ne soit pas réappliquée automatiquement.

API

La propriété peut être gérée via l'API publique en utilisant les scopes nhi:ownership:read et nhi:ownership:write. Les endpoints vous permettent de lister les propriétaires d'une identité, d'ajouter des propriétaires, de supprimer un propriétaire ou de remplacer la liste complète des propriétaires.

Carte d'exploration

La carte d'exploration vous offre une vue visuelle de bout en bout d'une NHI, vous aidant à comprendre ses connexions, son utilisation et son impact potentiel à travers votre environnement.

La carte est composée de :

• Secrets managers – Où les secrets de la NHI sont stockés en toute sécurité.
• Consumers – Les entités (telles que des services, scripts ou jobs) qui utilisent le secret pour s'authentifier et accéder à d'autres systèmes.
• Accessed resources – Les cibles accédées par les consumers, ainsi que leurs permissions, basées sur les Secret Analyzers.
• Incidents – Les incidents de secret à la fois publics et privés associés à la NHI.

Vous pouvez accéder à la carte depuis la vue détaillée d'une NHI ou directement depuis un incident de secret, permettant une navigation rapide et contextuelle entre détection et analyse.

Cas d'usage

Bien que l'objectif principal soit de visualiser et contextualiser les NHIs, la carte aide également à :

• Rationaliser la remédiation – Évaluer rapidement l'impact de la révocation d'un secret et identifier tous les systèmes affectés.
• Examiner les fuites – Tracer quels consumers et ressources ont pu être compromis.
• Améliorer l'hygiène des secrets – Repérer les secrets obsolètes ou surprivilégiés, les consumers inutilisés et d'autres problèmes d'hygiène à travers votre périmètre.