Si l’IA peut rétroconcevoir n’importe quelle appli, quel avenir pour la sécurité applicative ?

Dans une vidéo publiée le 12 octobre 2026, Fireship se demande si toutes les applications deviennent « open source », que leurs créateurs le veuillent ou non.

Elle présente l’analyse logicielle assistée par l’IA, notamment Reverse Engineer Anything (REA). Ce kit open source relie des agents de programmation à des outils de rétroconception via MCP.

L’idée est séduisante : un agent peut aider à examiner une application compilée, parcourir les résultats d’analyse et expliquer une partie de son comportement sans disposer du code source original.

Certaines investigations pourraient ainsi aller plus vite. Cela ne rend pas un logiciel propriétaire open source, ne garantit pas la récupération du code source exact et ne prouve pas une faille.

Toute conclusion reste une hypothèse tant qu’elle n’est pas étayée par des éléments indépendants. Pour l’AppSec, la question n’est pas de savoir si l’IA peut « comprendre n’importe quelle appli ».

Il s’agit de gagner en visibilité tout en gardant artefacts, outils et conclusions dans un processus de sécurité défendable.

Ce que fait Reverse Engineer Anything

REA relie des agents de programmation à des fonctions de rétroconception.

Selon l’artefact et la configuration, les analystes peuvent étudier des binaires natifs, des applications JavaScript et Electron, des assemblies .NET, des paquets Android, des firmwares et d’autres formats.

Pour les binaires natifs, le flux de travail peut utiliser des outils éprouvés comme Ghidra, IDA ou Hopper. Ils existaient avant les agents d’IA actuels.

Ils désassemblent le code machine, produisent du pseudocode approximatif, affichent les références entre fonctions et exposent la structure des exécutables.

N’utiliser REA que pour des analyses légales et autorisées. Le dépôt indique que l’analyse des outils s’exécute localement. Les résultats transmis à l’agent peuvent parvenir au fournisseur configuré ; sa politique de données s’applique.

REA n’accorde aucune licence pour IDA ou Hopper, qui sont soumis à des licences distinctes.

La couche agent peut aider à formuler des questions, récupérer les résultats pertinents, suivre les références et résumer une piste d’implémentation possible.

Un analyste peut s’en servir pour localiser la gestion d’une fonctionnalité dans un programme de bureau inconnu, puis examiner les fonctions concernées et vérifier son interprétation.

L’agent facilite une investigation ; il ne reconstruit pas automatiquement le programme complet et ne certifie pas son comportement.

Les compilateurs transforment des informations, des symboles peuvent manquer et le pseudocode peut être incomplet ou trompeur. Une fonction reconstruite peut seulement ressembler au comportement original.

Pourquoi c’est important pour l’AppSec

Plus de visibilité sans accès au code source

Les organisations dépendent d’applications tierces, de bibliothèques natives, de clients mobiles, de firmwares et de logiciels commerciaux dont elles ne peuvent pas consulter le code source.

L’analyse de binaires apporte parfois de la visibilité lorsque les méthodes axées sur le code source ne sont pas possibles. Elle peut signaler une entrée suspecte, des données codées en dur ou une fonction inattendue à examiner.

Une fonction suspecte ne prouve pas qu’elle est exploitable. Il faut établir si une entrée peut l’atteindre, dans quelle configuration et avec quel impact de sécurité.

Une SBOM aide à identifier les composants, mais ni une SBOM ni l’analyse d’un binaire ne prouvent à elles seules qu’un composant est sûr ou vulnérable.

Formuler des hypothèses plus rapidement

La rétroconception nécessite des connaissances des formats exécutables, de l’assembleur, de la mémoire, des conventions d’appel et des compilateurs.

L’IA peut aider à parcourir cette complexité : suivre une entrée potentielle entre plusieurs fonctions, repérer une opération risquée ou réunir des résultats connexes.

Cela peut orienter l’analyse humaine vers les opérations de mémoire, la cryptographie, les parseurs natifs et les frontières où des données non fiables influencent des fonctions privilégiées. Les sorties des outils restent des pistes.

Une analyse statique peut manquer de contexte d’exécution et l’explication du modèle peut être erronée.

Un apport possible aux tests autorisés

L’analyse de binaires peut éclairer un test d’intrusion si le propriétaire a explicitement autorisé la cible et les méthodes.

Un analyste peut examiner un chemin suspect et concevoir un test contrôlé pour vérifier s’il est atteignable et exploitable dans les conditions convenues. REA ne constitue pas à elle seule une plateforme complète de pentest autonome.

Les fonctions de rétroconception ne garantissent ni la découverte, ni l’exploitation, ni la correction d’une vulnérabilité.

Les tests doivent respecter le périmètre écrit et les conclusions de sécurité doivent être confirmées par des preuves reproductibles.

L’hypothèse de sécurité remise en cause

Le code compilé est plus difficile à lire que le code source, mais le secret de l’implémentation n’est pas une frontière de sécurité.

Si un client de bureau vérifie localement les droits et que le serveur accepte la requête sans refaire ce contrôle, une personne peut modifier le client ou appeler le service directement.

Le problème est de faire confiance à un comportement contrôlé par le client, pas l’existence d’un décompilateur.

L’autorisation sensible doit être appliquée à une frontière de service fiable, conformément à OWASP ASVS v5.0, exigence V8 Authorization.

L’obfuscation, l’anti-débogage et l’anti-altération augmentent le coût d’inspection ou de modification. Ils peuvent constituer une défense en profondeur dans certaines applis mobiles, certains jeux et environnements clients.

OWASP MASVS-RESILIENCE considère ces mesures complémentaires. Elles ne compensent pas une authentification, une autorisation ou une conception cryptographique défaillante.

Les agents de rétroconception peuvent aussi être attaqués

Un agent d’IA peut analyser un binaire contenant des chaînes, des métadonnées ou d’autres contenus contrôlés par un attaquant.

Si un outil renvoie ce contenu et que l’agent le prend pour une instruction, l’artefact peut franchir une frontière de confiance par injection de prompt indirecte. Un scénario simplifié :

1. Un agent reçoit un binaire inconnu à analyser.
2. Un outil de rétroconception extrait des chaînes, des métadonnées ou du pseudocode.
3. Une partie du contenu vise à influencer un système d’IA.
4. L’agent le confond avec une instruction fiable ou une conclusion fondée.
5. Il peut proposer une action hors périmètre ou reprendre une fausse affirmation dans son rapport.

Un risque connexe est la fausse corroboration : plusieurs sorties d’outils peuvent répéter le même texte issu de l’artefact.

Elles ne constituent pas des preuves indépendantes simplement parce qu’elles apparaissent dans des panneaux ou des formats différents.

Le préprint arXiv de juillet 2026 « When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering » étudie ce risque dans un environnement contrôlé.

L’expérience a utilisé des programmes C synthétiques et contrôlés pour Linux ELF/x86-64 et deux modèles.

Avant les contrôles d’exécution proposés, elle rapporte que les modèles ont proposé une action dangereuse préparée par un attaquant dans 35 cas sur 40.

REA lui-même n’a pas été évalué et ces pourcentages ne mesurent pas la prévalence de défaillances dans le monde réel. Ce résultat vaut pour les modèles, tâches et conditions expérimentales précis des auteurs.

La leçon générale est que l’artefact étudié doit rester une donnée non fiable, jamais une autorité pour l’agent. Pour sécuriser le processus :

• traiter les chaînes, métadonnées, pseudocodes et documents extraits comme des entrées non fiables ;
• limiter les permissions des outils et demander une validation pour les actions sensibles ou hors périmètre ;
• documenter la provenance afin de rattacher chaque affirmation à son artefact et à la sortie de l’outil ;
• valider les constats importants par des tests indépendants et autorisés ; et
• isoler les binaires inconnus et le code d’analyse généré des identifiants et des systèmes de production.

Cette menace relève de l’OWASP LLM01

La limitation des capacités de l’agent rejoint OWASP LLM06

Un processus d’analyse de binaires fondé sur des preuves

Un processus fiable passe de l’observation à la validation. Ces sept étapes forment une architecture de référence pratique, sans prétendre que REA ou Plexicus les implémente toutes.

1. Définir le périmètre autorisé. Consigner les artefacts, environnements, méthodes permises et actions soumises à validation humaine.
2. Préserver l’artefact. Enregistrer les empreintes, versions, architectures, provenances et informations de composants pour rattacher les résultats à la version exacte.
3. Analyser avec les bons outils. Examiner imports, symboles, chemins, désassemblage et pseudocode ; noter les versions et limites des outils.
4. Formuler des hypothèses. Demander à l’IA de repérer des comportements suspects, mais étiqueter chaque observation comme un constat potentiel.
5. Valider en environnement isolé. Mener des tests contrôlés et autorisés pour déterminer si la faiblesse est réelle et atteignable.
6. Consigner les preuves et l’impact. Conserver résultats, emplacements pertinents, hypothèses d’environnement et conséquences observées ; distinguer les preuves de l’interprétation du modèle.
7. Vérifier la correction. Rejouer le test initial après correction et rechercher les régressions.

Le résultat doit être un constat de sécurité vérifiable, pas simplement une explication convaincante.

L’analyse de binaires complète les autres méthodes AppSec

L’objectif n’est pas de remplacer SAST ou DAST par l’analyse de binaires, mais de combiner des preuves adaptées pour mieux comprendre les risques applicatifs.

Comment se préparer

• Appliquer les contrôles d’accès sur les systèmes fiables. Ne pas protéger les fonctions sensibles par de simples vérifications côté client.
• Réduire les secrets distribués. Ne pas intégrer d’identifiants serveur privilégiés et durables dans des applications téléchargeables.
• Sécuriser les composants natifs. Favoriser la sûreté mémoire, les protections du compilateur, la validation des entrées et les tests adaptés.
• Inventorier les artefacts distribués. Inclure binaires, firmwares et composants tiers dans l’évaluation et la réponse aux risques.
• Utiliser l’obfuscation en défense en profondeur. La définir selon le modèle de menace, sans la substituer à une architecture sûre.
• Protéger les agents d’analyse. Empêcher les artefacts non fiables de remplacer les instructions ; restreindre séparément les accès aux fichiers, au réseau, aux identifiants et à l’exécution.
• Exiger des preuves reproductibles. Une explication assurée n’est pas une vulnérabilité confirmée.

Ces pratiques s’alignent sur OWASP MASVS-RESILIENCE.

Elles s’alignent aussi sur OWASP ASVS v5.0, exigence V8 Authorization.

La version finale publiée du SSDF est NIST v1.1.

La version 1.2 (NIST SP 800-218 Rev. 1 IPD) était un projet initial public daté de décembre 2025, pas encore une version finale : NIST SP 800-218 Rev. 1 IPD.

L’IA rétroconcevra-t-elle toutes les applications ?

Le mot « toutes » masque des différences techniques importantes. Une fonction simple, un programme natif fortement obfusqué, un service distribué et un firmware dépendant du matériel ne s’analysent pas de la même manière.

Un agent peut reconstruire un chemin sans comprendre l’application entière, ou générer du code similaire mais non équivalent. Il est plus raisonnable de penser que l’IA peut réduire le coût d’examen de certains logiciels compilés.

Cela peut aider les défenseurs et les chercheurs, mais également abaisser des barrières pour les attaquants.

L’impact dépend de l’implémentation, de la gouvernance, de l’autorisation et de la validation indépendante, pas d’une prétendue ouverture de tous les logiciels.

L’AppSec a besoin de preuves, pas seulement de visibilité

REA associe des outils de rétroconception établis à des processus assistés par l’IA. Son intérêt réside dans les questions qu’il pose sur la transparence logicielle et sur les systèmes qui analysent des artefacts non fiables.

Repérer un chemin suspect n’est que le début. Il faut encore déterminer s’il est atteignable et exploitable, son impact, et si la correction fonctionne.

L’IA peut accélérer l’investigation, mais les résultats de sécurité exigent des preuves, une validation et une remédiation responsable.

C’est le principe de Proof-Driven AppSec : passer des observations à des constats validés et à des corrections vérifiées.

Découvrez Plexicus et son approche des tests assistés par l’IA, de Deep Code Analysis et de l’AppSec fondée sur les preuves.

Foire aux questions

L’IA peut-elle rétroconcevoir un logiciel fermé ?

Elle peut aider à désassembler, décompiler et analyser le comportement. Elle ne garantit pas la récupération du code source original exact ni la découverte de composants serveur absents du fichier.

Qu’est-ce que Reverse Engineer Anything (REA) ?

C’est une boîte à outils open source qui relie des agents de programmation aux fonctions de rétroconception via MCP. Les artefacts et intégrations pris en charge dépendent de la configuration.

L’analyse assistée par IA peut-elle trouver des vulnérabilités ?

Elle peut aider à repérer des chemins suspects et à formuler des hypothèses. Des analyses supplémentaires et des tests autorisés sont nécessaires pour confirmer une vulnérabilité.

La rétroconception rend-elle les applications propriétaires vulnérables ?

Non. La sécurité ne doit pas dépendre du secret de l’implémentation. La rétroconception peut révéler les faiblesses d’une application qui s’appuie sur des contrôles côté client ou des comportements cachés.

Les agents de rétroconception sont-ils exposés à l’injection de prompt ?

Oui. Des chaînes contrôlées par un attaquant ou des sorties d’outils peuvent influencer un agent si elles sont traitées comme des instructions fiables. Des expériences contrôlées ont montré les risques de confusion de représentation.

L’IA peut-elle remplacer un test d’intrusion ?

Non. Elle peut guider des tests autorisés, mais l’inspection du code ne prouve pas l’exploitabilité ni l’impact dans les conditions de test.

Références

• Fireship : Every app on Earth is now open source… whether it likes it or not
• Reverse Engineer Anything (REA)
• Ghidra
• When Binaries Talk Back: Representation-Confusion Attacks (juillet 2026)
• OWASP LLM01
  Prompt Injection
• OWASP LLM06
  Excessive Agency
• OWASP MASVS-RESILIENCE
• OWASP ASVS v5.0, V8 Authorization
• NIST SP 800-218 : Secure Software Development Framework ; projet public Rev. 1