Guide
Comment détecter les secrets divulgués dans le code généré par IA
Scannez l’instantané du dépôt, contrôlez l’exposition côté frontend et examinez l’historique Git à part. Ce que vetkit détecte et que faire quand un identifiant fuite.
· 5 min de lecture · Par l’équipe vetkit
Pour détecter les secrets divulgués dans du code généré par IA, exécutez un scanner de secrets sur la version du dépôt que vous comptez livrer, examinez les éléments de preuve (fichier et ligne) et révoquez tout identifiant exposé. Dans vetkit, le Security Quick Scan inclut la détection de secrets dans le dépôt ; l’historique Git et l’exposition de clés côté navigateur nécessitent des contrôles distincts. Un rapport vierge ne couvre que les fichiers et les contrôles réellement exécutés.
1. Choisir le périmètre du scan
Le code généré peut contenir un identifiant recopié, un placeholder réaliste, ou du code qui n’expose une clé qu’au moment du build de l’application. Ce sont des problèmes différents. Déterminez de quels éléments vous avez besoin avant d’interpréter le résultat :
| Question | Contrôle pertinent | Limite |
|---|---|---|
| Un identifiant est-il présent dans les fichiers du dépôt scanné ? | Secrets (gitleaks), inclus dans le Security Quick Scan | Détection par motifs dans le checkout, pas une preuve de l’absence de tout identifiant |
| Un identifiant a-t-il été supprimé des fichiers actuels mais laissé dans des commits ? | L’analyseur distinct de l’historique des secrets, s’il est disponible dans le périmètre d’audit choisi | Historique limité ; ne fait pas partie du Quick Scan |
| La configuration de build pourrait-elle exposer une clé de fournisseur aux navigateurs ? | Les contrôles des applications LLM pour les schémas de code pris en charge, plus votre propre inspection du build | Ne fait pas partie du Quick Scan ; un audit du code source n’inspecte pas vos ressources déployées |
2. Scanner la bonne version du dépôt
- Connectez le dépôt dans vetkit, puis sélectionnez le Security Quick Scan ou un périmètre d’audit disponible qui inclut la détection de secrets.
- Vérifiez le dépôt et la ref ciblée. Les scans de dépôts distants ne voient ni le contenu non enregistré de l’éditeur ni les fichiers locaux que vous n’avez pas poussés. Ne commitez pas un secret présumé simplement pour qu’il puisse être scanné.
- Attendez la fin du scan et vérifiez les résultats des analyseurs (erreurs ou contrôles ignorés) avant de lire les résultats. Un scanner indisponible n’est pas un contrôle réussi.
Si vous travaillez via un assistant, le guide MCP pour Claude Code et Cursor explique comment choisir un dépôt et consulter les résultats d’audit. Utilisez des placeholders dans vos prompts ; ne collez jamais un vrai identifiant dans l’assistant pour lui demander s’il est valide.
3. Examiner chaque résultat
Lisez la règle, la sévérité, le chemin du fichier et l’emplacement de la ligne. Les résultats de vetkit concernant les secrets utilisent des extraits masqués ; examinez la source en privé pour distinguer un véritable identifiant de données de test synthétiques. Les motifs génériques peuvent produire des faux positifs, et des formats inhabituels peuvent passer inaperçus. Une correspondance ne suffit pas à établir si l’identifiant est toujours actif.
Traitez en priorité les identifiants qui donnent accès à des ressources cloud, à des dépôts, à la publication de paquets ou à des données de production. Consignez le service concerné et le responsable de la correction sans recopier le secret dans un ticket, une capture d’écran ou un chat. N’écartez pas un résultat au seul motif que l’assistant présente la valeur comme un exemple.
4. Vérifier l’exposition côté navigateur et l’historique
Une clé peut rester hors de Git et pourtant atteindre les utilisateurs via un build frontend. Examinez l’usage des variables d’environnement publiques, les appels aux SDK des fournisseurs et la configuration du bundler, puis inspectez les ressources générées pour le navigateur dans un environnement que vous contrôlez. Voir le guide sur les clés d’API côté frontend pour des exemples. Le scan du dépôt ne build pas automatiquement votre application avec les secrets de déploiement et n’examine pas les bundles du site en ligne.
Si un identifiant a pu être commité par le passé, ajoutez le contrôle distinct de l’historique lorsque votre périmètre d’audit le permet. Sa fenêtre par défaut est d’au plus 500 commits, et elle peut être plus réduite si l’historique du checkout est moins profond. Ce n’est pas une recherche exhaustive dans chaque branche, fork ou copie du dépôt.
5. Réagir et scanner à nouveau
- Révoquez ou renouvelez l’identifiant exposé auprès de son fournisseur. Supprimer une ligne ou réécrire un commit n’invalide pas une clé déjà copiée.
- Placez le nouvel identifiant dans un coffre à secrets côté serveur ou dans un environnement d’exécution adapté. Assurez-vous qu’il ne peut pas être intégré au code du navigateur ni affiché dans les logs.
- Examinez les accès et les journaux d’utilisation du fournisseur pour repérer toute activité inattendue. Coordonnez tout nettoyage de l’historique avec les collaborateurs du dépôt ; le renouvellement reste nécessaire.
- Lancez un nouveau scan sur la version corrigée et refaites les contrôles de build ou d’historique pertinents. Conservez la version ciblée par l’audit avec votre trace de correction.
Sources et limites
Vérifié le 1er novembre 2026 par rapport à la configuration du Quick Scan de vetkit et aux implémentations des analyseurs gitleaks, secrets-history et LLM app. Le Quick Scan exécute posture, gitleaks et OSV ; il n’inclut pas tous les analyseurs d’un audit complet. Par défaut, l’intégration gitleaks ignore les fichiers de plus de 5 Mo, et les scans sont soumis à des limites de dépôt, de fichiers et de durée. Examinez la couverture et les avertissements de l’exécution réelle.
La documentation décrit le workflow d’audit, et le catalogue public de contrôles documente les règles maison. Ce catalogue n’est pas une liste complète des signatures gitleaks tierces. Ce guide décrit des étapes de détection et de correction ; ni un scan vierge ni un score élevé ne garantissent qu’une application est sécurisée.