Rétro-ingénierie par agents : ce que ça change pour les équipes sécurité

Le dimanche 11 octobre 2026 au matin, le dépôt GitHub de REA (Reverse Engineer Anything) affichait 76 998 étoiles, après en avoir gagné 25 793 en une journée¹. Le 23 octobre, l'API de GitHub en comptait 369 860². Ce serveur MCP donne à un agent de code les outils d'un rétro-ingénieur : Ghidra, Hopper ou IDA pour le natif, des analyseurs statiques pour JavaScript, Electron, .NET ou Android. Pour une équipe sécurité, la question devient : combien de temps faut-il désormais à un attaquant pour comprendre un logiciel fermé ? Cette page rassemble ce que nous en retenons, et renvoie aux analyses détaillées du cluster.

Le coût de la curiosité s'effondre

Connor Turland a fait analyser Slack 4.52.171 par REA et publié son retour le 20 octobre : 529 fichiers JavaScript, 1 904 modules, 45 canaux IPC et 8 add-ons natifs cartographiés, et la logique du mode Ne pas déranger reconstituée en une dizaine de minutes. Sa conclusion porte sur l'économie de l'opération : ce qui a changé, selon lui, c'est « how much curiosity costs »³. Le même jour, 404 Media décrivait une vague de particuliers qui réécrivent le système de leur TV connectée ou ressuscitent des objets abandonnés avec des agents⁴.

Pour la sécurité, la conséquence est directe. Comprendre comment fonctionne un logiciel fermé précède souvent une attaque : repérer un endpoint non documenté, une clé embarquée, un contrôle fait côté client. Cette étape demandait des années de pratique ; elle tient désormais dans une session d'agent supervisée. Le fonctionnement de l'outil est expliqué dans REA expliqué en trois schémas.

Boîte noire, boîte blanche

Les métiers de la sécurité distinguent deux postures. En boîte noire, l'auditeur se place à l'extérieur, sans accès au code, et cherche à pénétrer : test d'intrusion, red team, injection de prompt contre une application d'IA. En boîte blanche, il dispose du code source et cherche comment un attaquant pourrait l'exploiter : une requête construite par concaténation, un contrôle d'accès oublié sur une route, une désérialisation non vérifiée.

Les agents de rétro-ingénierie déplacent la frontière. Un attaquant qui ne dispose que du binaire obtient désormais, à faible coût, du pseudocode, des chaînes et une cartographie des appels : il se rapproche de la boîte blanche. Le défenseur, lui, possède déjà le code source de ses propres applications. C'est son avantage, à condition de s'en servir avant l'attaquant. Faire lire ce code par les mêmes modèles, avec un prompt adapté à chaque projet et à chaque type de faille, donne une profondeur d'analyse qu'aucun audit manuel ponctuel n'atteignait à cette échelle.

Le code interne passe en premier

Le code exposé sur internet a en général été audité. Le code interne, développé ou sous-traité au fil des années, l'a été une fois, puis de moins en moins, au motif qu'il ne serait pas attaqué. Or les modèles trouvent des failles anciennes même dans le code le plus relu : Z.ai revendique 2 436 vulnérabilités découvertes par GLM-5.3 dans 269 projets open source, vieilles en moyenne de 26,6 ans (voir les failles du meilleur open source annoncent celles de votre code interne). Sonatype mesure de son côté, sur une cohorte fixe d'applications suivie de juin 2022 à juin 2026, un passage de 14,14 à 54,3 vulnérabilités critiques et élevées par application⁵. La course entre découverte et correctif s'est accélérée, comme l'a montré la faille PHP2Shell.

Défragiliser ce patrimoine relève d'une politique plus que d'un audit : l'analyse du stock se relance à chaque nouveau modèle, le legacy d'abord, puisque le code neuf passe déjà par les contrôles des outils de développement. Le code n'a pas à sortir de l'entreprise : un modèle à poids ouverts tourne désormais en réseau fermé (voir Aikido Altar).

Ce que la rétro-ingénierie par agents ouvre pour la défense

Les mêmes outils servent la défense dès lors qu'on les cadre. Auditer un composant livré sans code source avant sa mise en production : auditer un binaire fournisseur, avec le lien vers l'inventaire exigé par le Cyber Resilience Act. Analyser un échantillon suspect sans l'envoyer à un service tiers : analyser un malware en local. Extraire le firmware d'un équipement avant de le brancher : firmware et objets connectés. Vérifier ce qu'une application tierce envoie réellement : RGPD et télémétrie, analyse d'une APK et audit d'un logiciel extra-européen.

Côté éditeurs, la même lecture oblige à revoir ce que le client embarque : votre logiciel est lisible par n'importe quel agent, les secrets dans l'ASAR d'Electron et ce que vaut encore l'obfuscation. Notre position d'ensemble est dans la fin de l'avantage du code fermé.

Ce que ça impose

REA n'est pas un bac à sable, et sa politique de sécurité le dit⁶ : tout binaire inconnu s'ouvre en environnement isolé (REA n'est pas un sandbox). Un outil viral attire les imitateurs, et un faux dépôt a distribué un cheval de Troie dès le 13 octobre (faux dépôts et supply chain). La version 6.7.0 expose 207 outils MCP, mesurés par Javier Cañete le 19 octobre⁷ : un tel catalogue se gouverne (déployer REA en entreprise, les limites réelles de REA, REA, GhidraMCP ou ida-pro-mcp). Et l'agent se trompe : ses conclusions se relisent avec méthode (lire une sortie REA). Former les équipes à cette revue prend du temps, et les crackmes sont le terrain d'entraînement le plus sûr.

Le cadre juridique

Auditer votre propre code, ou un logiciel que vous êtes autorisé à examiner, relève d'un cadre clair. La décompilation d'un logiciel tiers est encadrée en Europe par la directive 2009/24/CE et, en France, par l'article L122-6-1 du Code de la propriété intellectuelle. Le DISCLAIMER de REA rappelle que posséder un fichier ne donne pas, à lui seul, la permission de toute opération⁸. Le panorama est dans clean-room ou reverse engineering.

Questions fréquentes

La rétro-ingénierie par agents est-elle offensive ou défensive ?

Les deux. L'usage dépend de qui pilote l'agent, sur quelle cible et avec quelle autorisation.

Faut-il un expert pour superviser l'agent ?

Oui. L'agent accélère la lecture ; il rate des éléments et peut être trompé par le contenu d'un binaire. Un analyste vérifie les conclusions importantes.

Par où commencer ?

Par votre propre code interne, en boîte blanche, sur les applications sensibles, en environnement confiné et avec un modèle choisi selon la sensibilité du code.

Quelle différence avec un test d'intrusion ?

Le test d'intrusion attaque de l'extérieur, sans le code. L'analyse en boîte blanche lit le code et cherche comment le détourner ; les deux se complètent.

L'offre AI Cyber de SFEIR défragilise le code existant en boîte blanche : analyse par agents des applications internes, preuve par test de chaque faille, correctif proposé, et relance à chaque nouveau modèle.

Sources

1. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App — hackernoon.com, 14 octobre 2026.
2. API GitHub, dépôt morluto/rea — github.com, relevé du 23 octobre 2026.
3. Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out — atcyrus.com, 20 octobre 2026.
4. 404 Media, 'Reverse-Engineer Anything' Is the New Wild West of AI, 20 octobre 2026, rapporté par Let's Data Science — letsdatascience.com.
5. Aaron Linskens (Sonatype), Securing Software at the Speed of AI: What Four Years of Data Reveal — sonatype.com, 18 août 2026.
6. morluto/rea, SECURITY.md — github.com, consulté le 23 octobre 2026.
7. Javier Cañete Arroyo, REA: ingeniería inversa con tu agente de código, probada con Ghidra y Electron — jacar.es, 19 octobre 2026.
8. morluto/rea, DISCLAIMER.md — github.com, consulté le 23 octobre 2026.