J'ai construit un outil de sécurité. Il a trouvé une faille critique en lui-même.
Je développe un analyseur de sécurité de code. Je l'appelle vibeanalyzer.
L'objectif est simple. Aujourd'hui, beaucoup de gens pratiquent le « vibe-coding ». Ils laissent des agents d'IA écrire le code. Le code semble propre. Les tests passent. Mais le développeur n'a aucune idée de ce qui se trouve réellement à l'intérieur du projet.
Avant de me lancer pleinement, j'ai fait ce que j'aurais dû faire il y a longtemps. J'ai vérifié si des outils existants résolvaient déjà ce problème. C'était le cas. Des outils comme Semgrep, CodeQL et Snyk sont bien meilleurs que moi.
J'ai exécuté Semgrep sur mon propre projet. Les résultats m'ont ramené à la réalité.
Semgrep a trouvé six problèmes dans mes dépendances :
• Un problème cosmétique lié au choix d'un hash. • Deux problèmes de sévérité haute dans esbuild et vite. • Trois problèmes de sévérité moyenne impliquant une traversée de chemin (path traversal). • Un problème critique dans vitest.
Le problème de vitest était une vulnérabilité de type path traversal. Elle pourrait permettre à quelqu'un de lire ou d'exécuter des fichiers en dehors du projet. C'est moi qui ai ajouté cette dépendance.
Comment un outil de sécurité peut-il présenter une vulnérabilité critique ?
La réponse réside dans la chaîne d'approvisionnement (supply chain). Mon code est peut-être honnête. Mais les outils sur lesquels je m'appuie ne sont pas toujours sûrs. Si j'ai manqué cela alors que je construisais un outil de sécurité, un développeur ordinaire n'a aucune chance de le détecter.
C'est pourquoi je continue de construire.
Les outils existants comme Semgrep trouvent des schémas de danger. Ils trouvent des vulnérabilités connues. Mais ils ne comprennent pas l'intention. Ils ne savent pas ce que votre code était censé faire réellement.
Ils ne peuvent pas dire si une fonction est sûre mais résout un problème qui ne devrait pas exister dans votre projet.
J'appelle cela l'écart d'intention (intent gap). C'est la distance entre le code et son objectif.
Vibeanalyzer se concentre sur cet écart. L'outil vous demande l'intention du projet et ses objectifs non visés (non-goals). Il établit des garde-fous. Lorsque l'IA évalue le code, elle connaît l'objectif. Elle sait ce qui dépasse les limites.
J'ai terminé la partie de chargement de l'intention. J'ai une analyse TypeScript de base et des graphes de structure de dossiers. Ensuite, je dois construire la couche d'IA. Je ne sais pas si l'IA peut réellement évaluer le code par rapport à l'intention. Elle pourrait simplement créer de fausses alertes. Je vais construire cela en public pour le découvrir.
J'ai mis à jour mes dépendances et corrigé les bugs connus. Mais des failles inconnues et des erreurs de logique subsistent. C'est pourquoi le travail continue.
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi