Doogree
DevSec · shift-left

Attraper le secret avant le commit : une analyse de code qui ne quitte jamais la machine

02/07/2026 · ~7 min de lecture
Analyse de codeSecretslocal-firstCIAgent IA

La fuite la plus fréquente dans une petite entreprise n'est pas une attaque sophistiquée — c'est un mot de passe ou une clé d'API oublié dans le code, poussé sur git, et de là exposé au monde entier. Nous voulions l'attraper à l'instant où il est écrit, et non deux semaines après la compromission. Mais il y avait une condition non négociable.

La condition : le code ne quitte jamais la machine

De nombreux outils d'analyse téléversent votre code source dans leur cloud pour l'analyser. Pour une entreprise israélienne — avec son code, ses secrets et parfois des données clients — c'est exactement le problème que nous avons entrepris de résoudre, non de créer. La première règle était donc : l'analyse s'exécute à 100 % sur la machine du développeur. Le code et les valeurs des secrets n'atteignent jamais notre cloud ; seul un résultat assaini (identifiant de règle, gravité, fichier:ligne, une empreinte masquée du secret — jamais le secret lui-même) est remonté vers le tableau de bord de l'organisation.

Une promesse que vous pouvez expliquer à votre comptable : « Vos clés et votre code source ne quittent jamais votre ordinateur — nous analysons localement, dans l'éditeur et dans git, avant qu'un secret ou une vulnérabilité n'arrive dans un commit. »

La décision centrale : un moteur, pas dix plugins

Nous aurions pu construire un plugin distinct pour chaque éditeur — un pour VSCode, un pour Cursor, un pour JetBrains, et d'autres. C'est un piège : dix bases de code à maintenir, une logique qui se fragmente, et des bugs différents partout. Au lieu de cela, nous avons construit un moteur unique — un seul exécutable statique (Rust) — qui contient toute la logique, et chaque « surface » n'est qu'une fine enveloppe autour de lui :

La logique est écrite une seule fois. La même règle exacte qui protège votre commit protège aussi votre CI et tout ce qu'un agent IA tente d'écrire.

Ce qu'il attrape

Le cœur combine une détection de secrets à la manière de gitleaks (un catalogue d'expressions régulières) avec une mesure d'entropie de Shannon — pour distinguer une chaîne aléatoire ressemblant à une vraie clé d'un innocent espace réservé comme "your-api-key-here". Clés AWS, jetons GitHub, clés privées, mots de passe dans les chaînes de connexion, et plus encore — le tout signalé avec une correction en langage clair et une référence CWE. À venir : une analyse approfondie des vulnérabilités (Semgrep) et une analyse des dépendances (CVE).

Pourquoi c'est crucial : un secret poussé sur git reste dans l'historique pour toujours — même si vous le supprimez au commit suivant. Le seul moyen de rester propre est de l'attraper avant qu'il n'entre. C'est là que réside toute la valeur.

L'angle dont personne ne parle : les agents IA qui écrivent du code

De plus en plus de code aujourd'hui est écrit par des agents IA. Ils sont excellents — mais ils peuvent aussi « halluciner » un motif non sécurisé ou intégrer un secret par erreur. Notre moteur se place comme un hook sur l'agent : lorsque l'agent tente d'écrire un secret ou une vulnérabilité critique, le hook refuse — avant que le contenu ne touche le disque. Nous avons transformé un nouveau risque (l'IA qui écrit du code) en une barrière défensive.

Comment nous l'avons testé

Nous avons exécuté l'outil sur notre propre base de code. Deux choses importaient : qu'il attrape les vrais secrets (nous avons testé avec des échantillons synthétiques — AWS, Stripe, chaînes de connexion — et tous ont été attrapés), et qu'il ne fasse pas de bruit sur du code valide (les espaces réservés ont été correctement rejetés). Le résultat sur notre propre code : 100/100 — zéro secret intégré, car ils vivent tous au bon endroit (un gestionnaire de secrets), exactement comme nous le recommandons à nos clients.

Comment nous continuons de l'améliorer — un contrôle qualité continu

L'outil s'exécute sur lui-même à chaque modification de code que nous apportons (une barrière CI), y compris l'analyse des dépendances (SCA) qui signale lorsqu'une bibliothèque dont nous dépendons devient vulnérable. Prochaines étapes : la surface éditeur (LSP) et la surface agent (MCP) pour chaque client, un moteur de diff qui n'alerte que sur ce qui est nouveau (et non sur l'ancien bruit), et un éclairage IA optionnel qui explique chaque résultat. Même philosophie : un outil, local, transparent — le savoir est exposé, le code reste chez vous.

Cet article décrit l'approche au niveau des principes. Il ne contient aucune signature de détection sensible, aucune clé ni aucun détail qui aiderait un attaquant — au contraire, la transparence du modèle est un point de force.

← Tous les articles