Security Vulnerabilities in Software Supply Chain for Autonomous Vehicles

Les véhicules autonomes ne sont pas de simples voitures dotées de moteurs perfectionnés ; ce sont des ordinateurs sur roues, où la sécurité des passagers et des piétons dépend entièrement de lignes de code. Ces machines reposent sur une chaîne d'approvisionnement logicielle complexe, un vaste réseau d'ingrédients numériques que les développeurs assemblent pour permettre à la voiture de voir, de réfléchir et de se déplacer. Cette chaîne comprend le code original écrit par le fabricant du véhicule, mais elle dépend également fortement de logiciels open-source — des blocs de construction librement disponibles, créés par des communautés de programmeurs à travers le monde. Bien que cette approche partagée accélère l'innovation et permette un test rapide de nouvelles idées, elle introduit un danger unique : si une seule pièce de ce logiciel partagé contient une faille cachée, cette faiblesse peut se propager à l'ensemble du système, provoquant potentiellement une mauvaise interprétation de l'environnement par le véhicule ou un échec de freinage. À mesure que ces véhicules passent des laboratoires de recherche aux routes publiques, garantir l'intégrité de chaque composant numérique devient une question de vie ou de mort.

Des chercheurs de l'Université de l'Alabama ont entrepris d'examiner la santé de ce fondement numérique en examinant directement le code de trois des plateformes de véhicules autonomes open-source les plus éminentes : Autoware, Apollo et openpilot. Ces projets représentent la pointe de la technologie de conduite autonome, Autoware et Apollo visant des niveaux élevés d'automatisation où la voiture se conduit elle-même, tandis qu'openpilot se concentre sur les systèmes d'aide à la conduite qui aident les humains à garder le contrôle. L'équipe a traité ces dépôts de logiciels comme un mécanicien inspectant un moteur complexe, mais au lieu de chercher des boulons rouillés, ils ont utilisé des outils de balayage spécialisés pour traquer les fissures numériques. Ils se sont concentrés sur deux domaines principaux : le code écrit par les équipes des projets eux-mêmes, et les bibliothèques tierces — des fragments de code pré-écrits empruntés à d'autres sources — dont ces projets dépendent pour fonctionner.

L'enquête a révélé que, bien que ces plateformes soient puissantes, elles ne sont pas immunisées contre les erreurs courantes qui frappent tout logiciel. Les chercheurs ont découvert que le code contenait des schémas de faiblesse récurrents connus sous le nom d'énumérations de faiblesses communes. Dans le code écrit en C et C++, des langages souvent utilisés pour les tâches de conduite les plus lourdes, les analyses ont identifié des problèmes liés à la gestion de la mémoire, tels que les dépassements de tampon (buffer overflows), où les données débordent de l'espace de stockage prévu et peuvent corrompre le système. Dans le code Python, souvent utilisé pour la planification de haut niveau et les outils, les analyses ont mis au jour des problèmes de gestion des situations et des entrées inattendues. L'un des problèmes les plus fréquents trouvés dans les trois projets était la gestion incorrecte des conditions exceptionnelles, ce qui signifie que le logiciel échouait parfois à réagir correctement lorsque des imprévus survenaient. Une autre découverte majeure était la présence de failles d'injection de commandes, où un acteur malveillant pourrait potentiellement tromper le système pour lui faire exécuter des commandes non autorisées.

L'étude s'est également plongée dans la chaîne d'approvisionnement, examinant les milliers de paquets externes dont dépendent ces véhicules. Les résultats ici étaient radicalement différents selon le projet. La plateforme Apollo, conçue pour une production à grande échelle, s'est avérée posséder un nombre immense de dépendances, et l'analyse a identifié 91 de ces composants externes comme présentant des vulnérabilités de sécurité connues. Parmi celles-ci figuraient des failles critiques dans des paquets utilisés pour la manipulation de fichiers et le rendu web, dont certains pourraient permettre à un attaquant de prendre le contrôle du système ou d'accéder à des données sensibles. En revanche, le projet openpilot, qui a un champ d'application plus restreint, présentait beaucoup moins de problèmes avec ses dépendances externes, avec un seul composant vulnérable détecté. Le projet Autoware présentait le moins de difficultés dans ce domaine, les analyses n'ayant trouvé aucune vulnérabilité connue dans ses bibliothèques tierces au moment de l'étude.

Malgré les différences dans le nombre de failles trouvées, le message central de la recherche est clair : le logiciel qui alimente ces véhicules est actuellement exposé à des risques importants. Les chercheurs ont noté que près de la moitié de toutes les cyberattaques dans le secteur automobile exploitent déjà des faiblesses dans les systèmes logiciels, et leur analyse confirme que ces vulnérabilités existent dans le code même censé protéger les personnes. L'étude n'a pas conclu que les systèmes sont irréparables, mais plutôt qu'ils reposent sur un fondement qui exige une vigilance constante. Les auteurs suggèrent que la sécurité ne peut être une réflexion après coup ; elle doit être tissée dans le processus de développement dès le début. En utilisant des outils automatisés pour vérifier continuellement ces failles et en gérant soigneusement les composants logiciels intégrés au système, les développeurs peuvent réduire le risque de défaillances catastrophiques. Ce travail rappelle que, dans un monde de plus en plus automatisé, la sécurité de la machine dépend de la sécurité de son code.