Foire aux questions

À tout moment dans cette FAQ, vous pouvez consulter notre glossaire pour des définitions utiles.

Comment fonctionne le moteur de détection de GitGuardian, en résumé ?

Pour une réponse détaillée, consultez cette page. Le moteur de détection GitGuardian s'articule autour des détecteurs. Un détecteur est un ensemble d'instructions que le moteur exécute sur un document d'entrée pour y trouver des secrets. Le flux est toujours le même :

• Pré-validation : écarter au plus tôt les documents sans intérêt pour la détection.
• Correspondance (matching) : rechercher un motif donné.
• Post-validation : appliquer des étapes de validation pour ne garder que les secrets pertinents.

Toutes ces étapes combinent expressions régulières et heuristiques basées sur le contexte.

Quelle est la différence entre détecteurs génériques et spécifiques ?

En bref, un détecteur spécifique cible un type de secret bien identifié, alors qu'un détecteur générique produit des secrets non associés à un fournisseur précis. Pour plus de détails, voir la documentation sur les détecteurs.

GitGuardian vérifie-t-il la validité des identifiants ?

Lorsque c'est possible, GitGuardian vérifie la validité des identifiants détectés via l'appel le moins intrusif possible vers le service. Nous privilégions les requêtes HEAD, ou GET si nécessaire, et des points de terminaison qui ne renvoient pas d'informations personnelles. Le secret est alors étiqueté :

• valid : l'appel a réussi et confirme que le secret est valide.
• invalid : l'appel a réussi et confirme que le secret est invalide.
• failed to check : l'appel a échoué, nous ne pouvons pas conclure.

Plusieurs situations mènent à « failed to check » : service interne inaccessible depuis nos serveurs, service indisponible au moment de l'appel, etc. Nous restons prudents et signalons l'incident.

Pourquoi certains détecteurs ne remontent-ils des incidents que pour des secrets valides ?

Le format de certains secrets empêche d'obtenir une précision suffisante sans vérification (pas de préfixe, pas de suffixe, longueur non fixe). Remonter toutes les correspondances possibles générerait trop de faux positifs. Nous ne signalons donc le secret que s'il est confirmé valide par une vérification. Ces détecteurs portent la mention « Only valid secrets raise an alert ».

Qu'entendez-vous exactement par « faux positif » en détection de secrets ?

Un faux positif survient lorsque le moteur lève une alerte pour quelque chose qui n'est pas et n'a jamais été un secret. Pour aller plus loin sur faux positifs, rappel et précision, voir cet article de blog.

Comment tester correctement les capacités de détection de GitGuardian ?

Lisez attentivement cette documentation, notamment les exemples des détecteurs qui fournissent de bons cas de test. Vous pouvez aussi utiliser ce dépôt d'exemples. Si un secret n'est pas détecté, voir cette question.

Pourquoi GitGuardian n'a-t-il pas détecté mon secret ?

Construisez d'abord vos cas de test à partir de la documentation des détecteurs : pour chaque détecteur, nous fournissons des exemples détectés par le moteur. Raisons possibles d'absence d'alerte :

• Le détecteur associé est activé et votre secret n'est plus valide : il est marqué invalid et aucune alerte n'est levée.
• Vous avez obfusqué le secret pour tester (bonne pratique), mais le motif a pu être cassé : gardez une longueur et un jeu de caractères identiques au format attendu.
• Le secret n'a pas passé nos étapes de pré-validation (fichiers Markdown bannis pour certains détecteurs, contexte requis, etc.) : voir la documentation du détecteur ici.
• Le secret ne fait pas partie de l'affectation (assignment) attendue : consultez les exemples du détecteur.

Nous avons déjà vu de vrais identifiants dans des fichiers .md : pourquoi certains détecteurs ignorent-ils le Markdown ?

Notre défi est d'atteindre la meilleure précision et le meilleur rappel possible. Nous testons nos algorithmes sur le flux de données GitHub et monitorons en permanence les performances (retours explicites des développeurs ou des checkers, retours implicites comme la suppression de secrets). Grâce à ces retours, certains détecteurs ignorent les fichiers Markdown pour réduire la fatigue d'alerte et augmenter la précision. Les détecteurs concernés sont indiqués dans la documentation de leurs étapes de pré-validation.

Les clés cryptographiques sont-elles des données sensibles ?

Clés cryptographiques

Les algorithmes cryptographiques sécurisent les communications sur des canaux publics comme Internet. Ils s'appuient sur des problèmes mathématiques difficiles et sont la base de protocoles comme TLS (navigation https) ou SSH (accès distant sécurisé). Les fonctionnalités offertes sont authentification, autorisation et chiffrement ; elles sont liées à des clés qui activent ou verrouillent ces fonctions.

On distingue :

• une clé symétrique partagée entre les parties ;
• des clés asymétriques : une clé publique distribuée pour initier la communication, et une clé privée pour poursuivre le protocole.

L'accès à la clé symétrique ou à la clé privée d'un tiers peut avoir des conséquences graves : usurpation, altération des communications, accès aux données protégées.

Détection des clés privées

Après les RFC IETF 1421, 1422, 1423 et 1424, la plupart des bibliothèques (OpenSSL, etc.) stockent les clés au format PEM (Privacy-Enhanced Mail), à structure très régulière. Nous nous appuyons sur cette particularité pour des détecteurs efficaces et précis :

• Generic private key.
• DSA private key.
• Elliptic curve private key.
• RSA private key.
• OpenSSH private key.
• PGP private key.
• Encrypted private key.
• Putty private key.

Nous couvrons les principaux algorithmes ou protocoles les plus répandus et normalisés, avec un détecteur pour le format PEM et pour la version encodée en Base64.

Et les certificats à clé publique ?

Les certificats publics TLS (cadenas vert, https) sont en substance des clés publiques enrichies d'une signature vérifiable par tous. Ils ne sont pas considérés comme sensibles ; la chaîne de confiance repose sur des autorités référencées par le navigateur ou l'OS.