themiddleblue/vibegateCrochet de sécurité pré-écriture agnostique à l'hôte pour agent de codage : détecte les motifs de saisie utilisateur via Semgrep et émet des conseils de sécurité déterministes, sans LLM.
Un point de contrôle de sécurité pour les outils d'IA de codage. Il examine chaque fichier qu'un assistant IA écrit, et bloque les dangereux avant qu'ils n'atteignent le disque.
Les assistants de codage IA (Claude Code, Codex, …) écrivent du code rapidement — y compris du code qui manipule des mots de passe, des e-mails, des clés API ou des entrées utilisateur brutes. Il est facile pour un assistant de connecter ces données directement dans une requête de base de données, une commande shell ou une réponse HTTP sans penser à la sécurité.
VibeGate se place entre l'assistant et votre système de fichiers. Chaque fois que l'assistant essaie d'écrire ou de modifier un fichier, VibeGate scanne d'abord le nouveau code :
Aucun LLM n'est impliqué dans l'analyse elle-même — c'est une analyse statique rapide et déterministe, donc elle n'invente jamais rien et ne vous coûte jamais de tokens.
Voici tout ce que VibeGate vérifie actuellement :
| Vérification | Ce qu'elle détecte | Résultat |
|---|---|---|
| Injection de commande | Une entrée non assainie atteint une commande shell | Bloque |
| Injection SQL | Une entrée non assainie atteint une requête de base de données | Bloque |
| Injection NoSQL | Le corps de la requête est utilisé directement comme filtre de base de données | Bloque |
| Injection de template (SSTI) | La source du template elle-même, pas seulement ses données, provient d'une entrée utilisateur | Bloque |
| Désérialisation non sécurisée | Des données non fiables atteignent un désérialiseur dangereux (pickle, YAML non sécurisé, ...) | Bloque |
| Traversée de chemin | Une entrée non assainie atteint une lecture, écriture ou suppression de fichier | Bloque |
| XXE | Du XML non fiable est analysé avec des entités externes activées | Bloque |
| XSS | Une entrée non assainie est rendue comme HTML brut | Bloque |
| Téléchargement de fichier sans restriction | Le nom propre du fichier téléchargé est utilisé pour construire le chemin de sauvegarde | Bloque |
| SSRF | Le serveur récupère une URL qui n'est pas codée en dur | Avertit |
| Redirection ouverte | Une cible de redirection qui n'est pas codée en dur | Avertit |
| Affectation massive | L'ensemble du corps de la requête est passé à un constructeur ou à une mise à jour de modèle | Avertit |
| Données sensibles dans un corps de requête | E-mails, mots de passe, tokens, etc. lus depuis le corps de la requête | Avertit |
| Données sensibles dans une URL/requête | E-mails, mots de passe, tokens, etc. lus depuis la chaîne de requête | Avertit |
| Données sensibles dans les en-têtes | E-mails, mots de passe, tokens, etc. lus depuis les en-têtes de requête | Avertit |
| Chemin de fichier provenant d'une entrée utilisateur | Une variable, pas une chaîne codée en dur, est utilisée comme chemin de fichier | Avertit |
| Arguments CLI | Des données proviennent d'arguments de ligne de commande | Avertit |
| Entrée standard | Des données proviennent de stdin | Avertit |
| Variables d'environnement | Des données proviennent d'une variable d'environnement | Avertit |
| Action GitHub non épinglée | Un workflow utilise un tag mutable (@v4) au lieu d'un SHA de commit | Avertit |
pull_request_target non sécurisé | Un workflow utilise le déclencheur pull_request_target | Avertit |
| Journalisation d'identifiants | Un mot de passe, une clé API ou un token est passé à print/console.log/un journal | Avertit |
| Secret codé en dur | Une variable nommée comme un secret se voit attribuer une valeur littérale réaliste | Avertit |
La liste complète et actuelle se trouve dans guidance.TECHNICAL_RISKS et
formatter.BLOCKING_CATEGORIES, au cas où ce tableau deviendrait obsolète.
┌───────────────────────────────┐
│ Vous demandez à Claude Code │
│ d'écrire ou de modifier un fichier │
└───────────────┬───────────────┘
│
▼
┌───────────────────────────────┐
│ Claude Code essaie de sauvegarder │
│ le fichier (outil Write/Edit) │
└───────────────┬───────────────┘
│
▼
┌───────────────────────────────┐
│ Hook VibeGate │
│ (s'exécute automatiquement, │
│ avant que le fichier soit sauvegardé) │
└───────────────┬───────────────┘
│
scanne le nouveau code avec Semgrep
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────────┐ ┌────────────────────┐ ┌──────────────────────┐
│ Aucune entrée │ │ Entrée risquée, │ │ Entrée risquée │
│ risquée trouvée │ │ mais risque plus │ │ atteint un sink │
│ │ │ faible (ex. │ │ critique │
│ │ │ affichée dans une │ │ (SQL/commande/RCE, │
│ │ │ réponse HTTP) │ │ injection de │
│ │ │ │ │ template) │
└─────────┬──────────┘ └─────────┬──────────┘ └───────────┬──────────┘
│ │ │
▼ ▼ ▼
Le fichier est sauvegardé, Le fichier est sauvegardé, Le fichier N'EST PAS
rien n'est affiché. plus un avertissement sauvegardé.
dans le terminal avec Claude Code voit
le risque et comment la raison du blocage
le corriger. et reçoit les
instructions pour
corriger.
En résumé : le code sûr passe sans modification, le code risqué mais viable est sauvegardé avec un avertissement, et le code à un pas de l'injection SQL, de l'injection de commande ou de l'exécution de code à distance est bloqué avant d'atteindre le disque.
Si VibeGate lui-même rencontre une erreur inattendue, il laisse toujours l'écriture passer — un bug dans le hook ne doit jamais être la raison pour laquelle votre travail est bloqué.