La révolution silencieuse des systèmes embarqués est devenue bruyante. selon un nouveau rapport 2025 époustouflant de RunSafe Security, 80,5 % des ingénieurs embarqués utilisent désormais des outils d’IA pour écrire du code, et un nombre stupéfiant de 83,5 % ont déployé ce code généré par l’IA directement dans des environnements de production.
Dans n’importe quelle autre industrie, ce serait une victoire pour la productivité. Mais dans le monde des systèmes embarqués (où le code contrôle les pompes à insuline, les armatures industrielles et les systèmes de freinage automobile), cela représente un découplage terrifiant entre vitesse et validité.
Le rapport, intitulé “L’IA dans les systèmes embarqués : l’IA est là. La sécurité ne l’est pas”, dresse le portrait d’une industrie à un point d’inflexion dangereux. Les ingénieurs écrivent du code plus rapidement que jamais, en utilisant des langages qui n’ont jamais été conçus pour être sûrs et en le déployant sur du matériel qui ne peut pas être facilement corrigé.
L’analyse technique approfondie : pourquoi les « bonnes » ruptures de code
La qualité du code n’est pas la principale préoccupation. Les LLM génèrent une syntaxe valide.
Le problème est que C et C++ sont des langages intrinsèquement dangereux qui nécessitent une parfaite vigilance des développeurs – ce que les modèles d’IA, qui sont des prédicteurs probabilistes de jetons, ne peuvent pas garantir structurellement.
L’écart de sécurité de la mémoire
Dans une application moderne de haut niveau (écrite en Python, Rust ou Go), le langage d’exécution gère l’allocation de mémoire. Vous créez un objet ; le système trouve de l’espace. Vous arrêtez de l’utiliser ; le garbage collector le libère.
En C/C++ intégré, vous êtes le ramasse-miettes. Vous allouez manuellement de la mémoire (malloc) et la libérez manuellement (free). Si vous faites une erreur, vous n’obtenez pas seulement une erreur ; vous créez une vulnérabilité.
Le rapport RunSafe souligne que cette approche de « transmission manuelle » entre en collision avec la vitesse de l’IA. Lorsqu’une IA génère un analyseur de 50 lignes pour un flux JSON, elle utilise souvent des modèles C standards et efficaces. Mais il prend rarement en compte le contexte de la disposition de la mémoire.
- Débordements de tampon : l’IA écrit des données dans un tampon sans vérifier rigoureusement si les données correspondent. Dans une application de bureau, cela fait planter le programme. Dans un contrôleur embarqué sans MMU (Memory Management Unit), cela écrase le pointeur d’instruction et donne à un attaquant le contrôle du périphérique.
- Use-After-Free (UAF) : l’IA libère correctement un pointeur mais laisse une référence en suspens ailleurs dans le code. Plus tard, la logique tente d’accéder à cette mémoire libérée. Si un attaquant a pulvérisé le tas de données malveillantes, il est désormais propriétaire de l’exécution.
Le multiplicateur de surface d’attaque
Les statistiques du rapport sont alarmantes en raison de la superficie. 53 % des personnes interrogées ont cité la sécurité comme leur principale préoccupation, mais 91 % augmentent leurs investissements dans la sécurité intégrée. Ils savent que la vague arrive.
Le développement traditionnel agit comme un régulateur naturel du volume de code. Un ingénieur humain ne peut écrire qu’un nombre limité de lignes de C++ par jour, et de bonnes équipes révisent ce code. L’IA supprime l’accélérateur. L’industrie inonde désormais les bases de code existantes avec de grandes quantités de nouvelles logiques non vérifiées.
Si 1 ligne de code humain sur 10 000 présente un défaut de mémoire critique et que l’IA permet aux ingénieurs d’écrire 100 000 lignes dans le temps qu’il a fallu pour en écrire 10 000, l’industrie n’a pas seulement augmenté sa productivité ; elle a augmenté la densité des vulnérabilités latentes d’un ordre de grandeur.
Histoire contextuelle : le modèle de négligence
L’industrie a déjà vu ce film, mais sur différents écrans.
Au début des années 2000, la phase « Connect Everything » du boom de l’IoT a conduit au botnet Mirai. Les fabricants se sont précipités pour installer des piles IP sur les caméras et les DVR sans penser aux mots de passe par défaut ou aux ports Telnet ouverts. Le résultat a été une infrastructure DDoS massive construite à partir de grille-pain et de webcams compromis.
Dans les années 2010, l’industrie automobile s’est empressée d’ajouter l’infodivertissement et la connectivité aux voitures. Le résultat a été le piratage du Jeep Cherokee, où des chercheurs ont tué à distance la transmission d’un véhicule sur une autoroute parce que le système de divertissement pouvait communiquer avec le bus CAN.
Aujourd’hui, en 2025, cela se reproduit avec la génération de code. Le rapport RunSafe note que 73 % des ingénieurs évaluent le risque lié au code d’IA comme « modéré ou supérieur », mais les chiffres de déploiement (83,5 %) montrent qu’ils se poursuivent malgré tout.
La pression économique pour proposer des fonctionnalités « intelligentes » (maintenance prédictive, traitement de l’IA de pointe, interfaces vocales) l’emporte sur la discipline d’ingénierie requise pour les sécuriser.
La contre-mesure : randomisation des fonctions de temps de chargement (LFR)
Si la confiance dans le code est impossible (parce qu’il y en a trop) et que réécrire 30 ans de C++ dans Rust du jour au lendemain est irréalisable, quelle est la défense ?
Le rapport pointe vers la résilience d’exécution. Si vous supposez que le bug existe, vous devez le rendre inexploitable.
L’une des techniques les plus efficaces pour cela dans l’espace embarqué est la Load-time Function Randomization (LFR).
Comment ça marche
Dans une compilation de micrologiciels standard, chaque fonction réside à une adresse statique connue. calculate_voltage() peut toujours être à 0x08001234.
Les attaquants adorent ça. Pour créer un exploit (comme la programmation orientée retour ou ROP), ils doivent savoir exactement où sauter pour exécuter le code souhaité. Ils enchaînent de petits extraits de code existant (gadgets) pour créer un programme malveillant.
LFR brise cette chaîne.
- Compile Time : le compilateur émet du code qui ne passe pas aux adresses absolues. Au lieu de cela, il accède à un « stub » ou à une table de recherche.
- Temps de chargement : lorsque l’appareil démarre, le chargeur sécurisé mélange le deck. Il attribue de manière aléatoire des adresses mémoire réelles à toutes les fonctions.
- Patching : le chargeur met à jour la table de recherche ou corrige le binaire en mémoire afin que les appels fonctionnent toujours.
Le résultat ? Chaque fois que l’appareil redémarre (ou chaque fois que le micrologiciel est mis à jour, selon l’implémentation), la carte mémoire change. Un exploit qui fonctionne sur le périphérique A fera planter le périphérique B. Un exploit qui a fonctionné hier ne fonctionnera pas après un redémarrage.
L’implémentation exclusive de cette technologie par RunSafe gagne du terrain car elle ne nécessite pas de réécriture du code source. Vous l’appliquez au niveau binaire. Ceci est crucial pour les 60 % des personnes interrogées qui tentent déjà d’utiliser les protections d’exécution.
Analyse prospective : les perspectives sur 5 ans
Le rapport 2025 est un instantané d’une période de transition. Le secteur est actuellement dans la phase « Far West » de génération de code d’IA.
Au cours des cinq prochaines années, trois changements majeurs sont attendus :
- L’essor de la sécurité basée sur le silicium : les mesures d’atténuation logicielles telles que LFR deviendront effectivement obligatoires. Les réglementations (similaires à la loi européenne sur la cyber-résilience) exigeront probablement que les dispositifs d’infrastructure critique possèdent des capacités de randomisation binaire.
- La transition Rust : Même si l’IA écrit facilement du C++, elle écrit également Rust facilement. Les frictions liées au passage à des langages sécurisés en mémoire diminueront à mesure que l’IA gérera le passe-partout. Cependant, cela ne protège que le nouveau code. Les milliards de lignes de l’ancien C/C++ demeurent.
- Changement de responsabilité : à mesure que le code généré par l’IA provoque des pannes physiques (par exemple, un bras robotique qui se balance trop rapidement, un système de gestion de batterie défaillant), la conversation juridique passera des « bogues logiciels » à la « responsabilité du fait des produits ». Si un fabricant a utilisé l’IA pour générer du code critique pour la sécurité sans examen humain ni protection d’exécution, il s’agit d’une négligence.
L’essentiel
Le rapport RunSafe Security 2025 n’est pas seulement un ensemble d’enquêtes ; c’est une fusée d’avertissement. L’industrie a débouché la bouteille de la productivité de l’IA, et il n’est pas possible de la remettre en place.
Le volume considérable de code produit signifie que la révision manuelle est mathématiquement impossible à grande échelle. Il n’est plus possible de prétendre que tous les bugs peuvent être détectés. La seule voie viable consiste à supposer que le code est défectueux et à créer des systèmes qui refusent de le laisser casser la machine.
Pour l’ingénieur embarqué en 2025, le travail ne consiste plus seulement à écrire du C. Il consiste à concevoir les champs de confinement qui empêchent ce C de nuire à qui que ce soit.
Annexe mathématique : la probabilité d’exploit
La modélisation de la valeur de LFR nécessite de calculer la probabilité P d’un exploit de chaîne ROP réussi. Une chaîne standard nécessite k gadgets. Dans une carte mémoire statique, la probabilité de trouver le gadget i à un emplacement connu est de 1.
La probabilité d’un exploit statique est effectivement de 100 %.
Avec LFR, s’il y a N emplacements (emplacements) possibles pour une fonction et que l’attaquant a 1 chance sur N de deviner le décalage correct pour chaque gadget indépendant (modèle simplifié), la probabilité chute à peu près à 1 divisé par N à la puissance k.
La probabilité est effectivement nulle.
Même avec une entropie modeste (N=256) et une chaîne courte (k=3), la difficulté monte en flèche, passant de la certitude à un sur 16 millions.
Nos sources (6)
- runsafesecurity.com RunSafe Security Blog
- themanufacturingconnection.com The Manufacturing Connection
- vmblog.com VMblog 2025 Predictions
- runsafesecurity.com Medical Device Cybersecurity Index 2025
- news.mit.edu MIT News: Memory Safety Tipping Point
- appsecengineer.com Defending Memory Corruption
🦋 Discussion sur Bluesky
Discuter sur Bluesky