Machine learning
Détecter les secrets avec une qualité élevée est un défi complexe. Pour renforcer notre moteur, nous utilisons plusieurs modèles de machine learning qui analysent le code comme un développeur expérimenté, repèrent les faux positifs et enrichissent les secrets génériques avec du contexte.
False Positive Remover
Seuls les espaces de travail sur le plan Business y ont accès.
Pour limiter les faux positifs, la programmation impérative et les regex atteignent vite leurs limites : on ne peut couvrir tous les cas par des conditions explicites.
Pour dépasser cette contrainte, nous entraînons des modèles capables de naviguer efficacement dans ce domaine complexe.
False Positive Remover est un modèle interne, entraîné en interne, indépendant des services tiers, qui identifie et étiquette les incidents comme faux positifs après analyse approfondie.
Comment l'utiliser ?
Utilisez le filtre Filters > GitGuardian tags > False positive dans la liste des incidents pour isoler et traiter ces cas.
FAQ
Que considère le modèle comme « faux positif » ?
Tout ce qui ne peut être un secret dans aucun contexte.
Dans l'exemple ("signup_form_confirm_password": " Confirmar contrasinal"), une regex peut croire à un vrai positif ; notre modèle, qui lit le contexte (lignes avant/après), non.
{
"signup_form_username": "Identificador",
"signup_form_password": "Contrasinal",
"signup_form_confirm_password": " Confirmar contrasinal", <- a regex may consider this a true positive, not our model,
"signup_form_button_submit": "Crear conta",
}
Si ce sont des faux positifs, pourquoi ne pas les supprimer automatiquement ?
Pendant la bêta, nous évaluons la précision du modèle avant d'éventuellement filtrer tous les faux positifs en amont.
Détectez-vous tous mes faux positifs ?
En v1, nous estimons ~50 % des faux positifs en moyenne. Nous privilégions la précision et améliorerons le rappel dans le temps.
Secret Enricher
Secret Enricher est un modèle spécialisé qui analyse le contexte autour des secrets génériques et les classe en catégories et fournisseurs. Cela aide à prioriser la remédiation en clarifiant l'impact et la criticité.
Destiné aux incidents génériques non rattachés à un détecteur spécifique. Le modèle infère catégorie et fournisseur à partir du contexte.
Affichage des incidents piloté par l'enrichissement
Lorsque l'enrichissement réussit, le nom enrichi remplace le nom du détecteur générique : au lieu de « Generic Database Assignment » ou « Generic High Entropy Secret », vous voyez par exemple :
- Redis Identifiers
- Stripe API Key
- PostgreSQL Connection String
- AWS Access Key
Les noms enrichis apparaissent dans les listes d'incidents, la recherche, l'API et les exports CSV/JSON.
Dans certains cas, le nom du détecteur générique peut encore s'afficher ; l'harmonisation progresse au premier semestre 2026.
Comment les catégories aident la remédiation
- Prioriser l'infrastructure critique (cloud, bases de données…)
- Cibler les services à fort impact (paiement, identité…)
- Repérer les secrets impactant l'activité (messagerie, e-commerce…)
- Rationaliser les workflows de remédiation
- Adapter les politiques de sécurité au type de service
Comment l'utiliser ?
Noms enrichis dans les listes
Affichage automatique dès que le modèle identifie le type de secret — sans configuration.
Personnaliser vos vues
Bouton « Columns » : ajoutez « Secret category » et « Secret provider » pour voir les attributs d'enrichissement.
Filtrer vos données
Trois filtres (Provider, Category, Family) pour isoler les incidents génériques critiques.
Exemple 1 : « Detector Type is Generic » + « Secret Provider is not Empty »
Exemple 2 : « Detector Type is Generic » + « Secret Category is Data Storage »
Référence catégories et fournisseurs
Voir la référence détaillée GSE.
FAQ Secret Enricher
Que se passe-t-il si un secret ne peut pas être enrichi ?
L'incident conserve le nom du détecteur générique. Les filtres permettent toujours de retrouver les incidents non enrichis.
Pourquoi ne pas les transformer en incidents « spécifiques » ?
La détection reste « générique » ; l'enrichissement est contextuel, pas basé sur des règles de motifs. Le nom enrichi apporte toutefois la spécificité utile à la priorisation.
Sur quoi le modèle est-il entraîné ?
Catégories détectées :
- AI
- CDN
- CI/CD
- Cloud provider
- Code analysis
- Collaboration tool
- CRM
- Cryptos
- Data storage
- E-commerce
- Identity provider
- Internal
- Messaging system
- Monitoring
- Other
- Package registry
- Payment system
- Private key
- Remote access
- Secret management
- Social network
- Version control platform
Fournisseurs (extrait) :
- Amazon AWS et services associés
- Microsoft Azure et services associés
- Google Cloud Platform
- Bases de données courantes (PostgreSQL, MySQL, MongoDB, Redis)
- CI/CD (GitHub, GitLab, Jenkins, CircleCI)
- Paiement (Stripe, PayPal, Square)
- IA (OpenAI, Anthropic, Hugging Face)
- Messagerie (Slack, Discord, Twilio)
- Et bien d'autres…
Liste complète : référence GSE.
Risk score (priorisation ML des incidents)
Le risk score est une fonctionnalité ML qui évalue automatiquement le risque de chaque incident sur une échelle 0–100 (100 = risque maximal). Il combine type de secret, validité, contexte d'exposition et signaux comportementaux pour concentrer l'attention sur les menaces les plus importantes.
Le risk score utilise des modèles de machine learning qui sont continuellement améliorés sur la base des retours utilisateurs. Si vous remarquez des incidents avec des scores ou des explications inattendus, nous vous encourageons à partager vos retours directement via le dashboard — votre contribution nous aide à affiner le modèle de scoring.
Capacités clés
- Évaluation automatique pour tous les incidents (Internal et Public Monitoring)
- Score dynamique selon l'évolution du contexte
- Explications en langage naturel
- Priorisation fine sur 0–100
- Boucle de retour pour améliorer le modèle
Où l'utiliser
Regroupement d'incidents similaires (ML)
Cette fonctionnalité regroupe automatiquement les incidents similaires selon le contexte (patch). Vous traitez des groupes entiers plutôt que cas par cas.
Capacités
- Regroupement automatique
- Actions de remédiation en masse
- Mise à jour dynamique des groupes
Intérêt
- Réduire le temps de remédiation
- Révéler des problèmes systémiques
- Appliquer une remédiation cohérente
- Traiter d'abord les groupes pour libérer du temps sur les cas uniques
Où l'utiliser
Cette fonctionnalité s'inscrit dans l'initiative ML plus large de GitGuardian pour la précision de détection et l'efficacité de remédiation.
