AI Cyber :
défragiliser
le code existant
Des agents lisent le code de votre système d'information, un projet et un type de faille à la fois, et prouvent chaque correctif par un test. Le code ne sort pas.
Boîte blanche
Nous partons du code source que vous possédez. Nous ne faisons pas de pentest externe, de red team ni de test d'injection de prompt : c'est le métier des pure players de la boîte noire.
Le code qui ne sort jamais
Applicatifs internes, développés ou sous-traités, audités une fois à la mise en production puis oubliés parce que « c'est en interne, il n'y aura pas d'attaque ». C'est le code que personne d'autre ne relira pour vous : l'open source est défragilisé par les chercheurs et les chasseurs de primes, le code neuf passe par les contrôles des outils de développement. Le legacy, lui, attend.
Le legacy d'abord
Les applications les plus anciennes ont été écrites avant les outils d'analyse actuels et n'ont jamais été relues avec un modèle capable de les lire en entier.
Les applicatifs internes
Back-offices, portails, API métier : le code que vous possédez, que vous pouvez corriger, et qu'aucun chercheur extérieur ne verra.
Le code sous-traité
Livré, recetté, en production depuis des années, avec un prestataire qui a changé deux fois. Vous en avez le code, rarement la lecture.
Hors périmètre
Le pentest de vos sites exposés, la red team, les attaques sur vos agents conversationnels : nous ne le faisons pas, et nous vous dirons qui le fait.
Les modèles lisent une base de code entière, et les attaquants ont les mêmes.
2 436
vulnérabilités revendiquées par Z.ai pour son modèle à poids ouverts GLM-5.3, dans 269 projets open source, vieilles de 26,6 ans en moyenne selon l'éditeur. Ce qu'un modèle ouvert trouve dans l'open source, il le trouve dans votre code interne. Lire l'analyse
14,14 → 54,3
vulnérabilités critiques et élevées par application sur une cohorte fixe, de juin 2022 à juin 2026, d'après Sonatype (18 août 2026). Le volume de code produit avec l'IA grossit plus vite que la capacité à le relire. Voir les chiffres
Un prompt par projet et par type de faille
« Trouve des failles dans ce dépôt » ne donne rien d'exploitable. Nous découpons : un projet, un type de faille, un pipeline agentique qui cherche, reproduit, corrige et prouve, un bug à la fois.
Chercher
Un agent parcourt le projet avec une seule question : où ce type de faille peut-il se produire ?
Prouver
Chaque hypothèse devient un test qui échoue sur le code actuel. Sans test, pas de bug remonté.
Corriger
Un correctif, le test qui passe, et le reste de la suite qui passe toujours. Un bug à la fois.
Rendre
Quatre niveaux de rendu : bug, bug avec correctif, faille, faille avec correctif. Vous choisissez où vous arrêter.
Le rapport
Il ne parle que de sécurité. Nous vérifions que les portes de secours s'ouvrent et que les extincteurs ne sont pas vides, pas que le bureau est confortable : la dette technique, la lisibilité et l'architecture ne sont pas notées.
Relancer à chaque nouveau modèle
Un audit date du jour où il est rendu. Les modèles, eux, progressent de génération en génération sur la découverte de failles : ce qu'un modèle ne voyait pas, le suivant peut le voir. Nous relançons donc l'analyse du stock à chaque nouveau modèle, le legacy en premier, et nous datons chaque passage.
Le résultat est un registre : pour chaque application, les types de failles cherchés, le modèle utilisé, la date, les bugs prouvés et les correctifs livrés. C'est le genre de trace que le Cyber Resilience Act demande aux fabricants de tenir sur leurs produits.
Modèles ouverts, chez vous
Les modèles à poids ouverts qui trouvent des failles, GLM-5.3 ou Mistral, s'exécutent sur votre infrastructure ou chez un hébergeur souverain, et le code source n'est transmis à aucun fournisseur. Quand la politique de sécurité l'exige, l'analyse tourne réseau coupé. Voir le cas Aikido Altar
Quand un sous-système accumule trop de bugs prouvés, la réécriture devient abordable avec les agents. Si l'on réécrit, autant réécrire dans un langage qui ferme la classe de failles trouvée, Rust par exemple pour la mémoire.
Le confinement des agents
Les agents qui lisent votre code en ont les droits. Un agent d'analyse n'est pas un bac à sable, les outils de rétro-ingénierie le disent eux-mêmes, et un binaire piégé peut lui faire raconter autre chose que ce qu'il fait. Nous cadrons postes, conteneurs, droits, choix du modèle et règles d'approbation des outils avant la première analyse.
→ Pourquoi REA n'est pas un sandboxRétro-ingénierie par agents
Un serveur MCP comme REA met Ghidra, JADX ou l'analyse d'une application Electron à portée d'un agent de code. Ce que cela permet, et ce que cela exige, en quatre pages.
Par quelle application commencer ?
Donnez-nous le nom de votre applicatif interne le plus ancien. Nous vous dirons quel type de faille chercher en premier et ce qu'il faut pour que le code ne sorte pas.
Échanger avec SFEIR