Attraper le secret avant le commit : une analyse de code qui ne quitte jamais la machine
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.
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 :
- CLI → hooks git (pre-commit / pre-push) et CI
- LSP → soulignements rouges dans l'éditeur à mesure que vous tapez (VSCode/Cursor/JetBrains)
- MCP + hook → agents IA (comme Claude Code) — bloque un secret avant qu'il ne soit écrit sur le disque
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).
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