Auditer un binaire fournisseur sans son code source

Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent signaler à l'ENISA les vulnérabilités activement exploitées, au titre du Cyber Resilience Act¹. À partir du 11 décembre 2027, ses exigences essentielles leur demanderont aussi de documenter les composants de leurs produits, notamment par une nomenclature logicielle. Pour une DSI qui intègre un composant livré en binaire, sans code source ni inventaire, la question devient pressante : que contient-il, qu'appelle-t-il, quelles bibliothèques embarque-t-il ? Les agents de rétro-ingénierie rendent cette due diligence abordable.

La boîte noire dans votre chaîne

Un pilote d'équipement, un module d'export comptable, un client lourd d'éditeur, un agent de supervision : beaucoup de composants arrivent compilés, avec une documentation commerciale et rien d'autre. Ils tournent pourtant avec des droits étendus, parlent au réseau et manipulent vos données. Répondre aux questions de base (bibliothèques embarquées et leurs versions, domaines contactés, permissions demandées, présence de secrets codés en dur) demandait jusqu'ici plusieurs jours d'un spécialiste. Le volume de failles rend l'exercice moins facultatif : Sonatype a mesuré, 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 en moyenne².

Ce qu'un audit par agent révèle

REA orchestre des outils de rétro-ingénierie existants et rend leurs résultats à l'agent avec les preuves et les limites de chaque conclusion (REA expliqué en trois schémas). Selon son README, la couverture dépend de la nature du binaire³. Sur un exécutable natif, avec Ghidra, Hopper ou IDA installé, il renvoie pseudocode, assembleur, chaînes, symboles, appels et références. Sur une application JavaScript ou Electron, il reconstruit modules, imports, routes, canaux IPC et add-ons natifs sans exécuter l'application. Sur une assembly .NET, il lit métadonnées, instructions CIL et dépendances natives déclarées, là encore sans charger le code (voir analyser des assemblies .NET avec REA).

Plusieurs cibles intéressent directement l'inventaire. Pour un binaire Rust compilé avec cargo-auditable, REA extrait les noms, versions et sources des crates embarquées, avec leurs dépendances. Pour un binaire Go, la version du compilateur, les modules et leurs remplacements. Pour un exécutable Windows signé, l'identité du signataire Authenticode³. Une application Electron, de son côté, expose sa structure dès l'analyse statique, comme le montre ce qu'une analyse REA révèle d'une application Electron.

Chaque trouvaille doit être relue. REA rend aussi ce qu'il n'a pas pu résoudre, et ces inconnues indiquent où l'inventaire reste incomplet. La méthode de lecture est détaillée dans lire une sortie REA.

Du constat à l'embryon de SBOM

Reconstituer les bibliothèques et leurs versions à partir du binaire, c'est produire un embryon de nomenclature logicielle (SBOM). Croisé avec les bases de vulnérabilités (CVE), cet inventaire dit si le composant embarque une bibliothèque connue pour être vulnérable. Le règlement n'oblige pas le fournisseur à vous remettre sa SBOM : il peut choisir de la mettre à disposition, et les autorités de surveillance peuvent la lui demander. Votre inventaire ne remplace donc pas celle du fournisseur : il la complète, la vérifie, ou comble son absence le temps de l'obtenir par contrat. Il sert aussi de pièce de diligence datée, avec ses inconnues assumées. Le calendrier du règlement et la méthode d'inventaire sont détaillés dans Cyber Resilience Act et SBOM.

Confiner l'audit

Un binaire fournisseur n'est pas un malware, mais il reste du code que vous ne connaissez pas. REA n'est pas un bac à sable : l'ouverture d'un binaire le fait parser par Ghidra ou Hopper avec vos droits⁴. L'audit se fait donc dans une VM ou un conteneur dédié, et en analyse statique tant que l'exécution n'est pas nécessaire (voir REA n'est pas un sandbox). Si le composant traite des données sensibles, choisissez aussi le modèle : les résultats d'outils partent chez le fournisseur du modèle de l'agent.

Le cadre contractuel et juridique

Le cas le plus sain est celui d'un contrat qui autorise l'audit. Prévoyez-le dans les achats : droit d'audit technique, remise d'une SBOM, notification des vulnérabilités. À défaut, le droit français réserve des marges que la licence ne peut pas supprimer. L'article L122-6-1 du Code de la propriété intellectuelle permet à l'utilisateur légitime d'observer, d'étudier et de tester le fonctionnement du logiciel pour en déterminer les idées et principes, lors des opérations qu'il est autorisé à effectuer, et déclare nulle toute clause contraire⁵. La décompilation obéit à des règles plus strictes : sans autorisation, elle n'est prévue que pour l'interopérabilité, sous conditions, ou, selon l'arrêt Top System, pour la correction d'erreurs. Un audit qui passe par la décompilation demande donc en principe l'accord du fournisseur, d'où l'intérêt de la clause d'audit (voir décompiler pour interopérer). Le DISCLAIMER de REA rappelle de son côté que « Authorization to inspect an artifact does not necessarily authorize execution, interception, device changes, or interaction with another party's system »⁶. Pour les clauses de licence, voir ce qui est nul en France, et pour le panorama, clean-room ou reverse engineering.

Questions fréquentes

Puis-je auditer un binaire fournisseur ?

Si le contrat l'autorise, oui. Sinon, l'observation du fonctionnement lors d'une utilisation autorisée est protégée par l'article L122-6-1 ; la décompilation obéit à des règles plus strictes. Faites valider votre cas par un juriste.

Un audit par agent remplace-t-il la SBOM du fournisseur ?

Non. Il la complète ou la vérifie, et documente votre diligence en attendant un inventaire officiel. Comme le règlement n'impose pas au fournisseur de vous la transmettre, demandez-la dans le contrat.

Faut-il confiner l'audit ?

Oui : VM ou conteneur dédié, analyse statique d'abord, aucun secret de l'entreprise dans l'environnement.

Que faire d'une vulnérabilité trouvée ?

La documenter avec ses preuves, la transmettre au fournisseur selon une démarche de divulgation coordonnée, et décider des mesures compensatoires en attendant le correctif.

L'offre AI Cyber de SFEIR outille cette due diligence : analyse confinée des composants livrés en binaire, inventaire daté de leurs dépendances et rapport limité à l'axe sécurité.

Sources

1. ENISA, The CRA Single Reporting Platform is launched — enisa.europa.eu, 11 septembre 2026 ; règlement (UE) 2024/2847 (Cyber Resilience Act) — eur-lex.europa.eu.
2. Aaron Linskens (Sonatype), Securing Software at the Speed of AI: What Four Years of Data Reveal — sonatype.com, 18 août 2026.
3. morluto/rea, README, section « What you can analyze » — github.com, consulté le 17 octobre 2026.
4. morluto/rea, SECURITY.md — github.com, consulté le 17 octobre 2026.
5. Code de la propriété intellectuelle, article L122-6-1 — legifrance.gouv.fr.
6. morluto/rea, DISCLAIMER.md — github.com, consulté le 17 octobre 2026.