La sécurité et la sûreté des logiciels automobiles doivent encore être améliorées

Temps de lecture : 5 minutes

Un récent article de blog, « Automotive Software defects », de Phil Koopman, professeur à Carnegie Mellon et auteur de « Better Embedded Software », parle du nombre croissant de défauts dans les logiciels automobiles qui constituent des risques importants pour la sécurité. Si cet article pointe l’augmentation des défauts logiciels potentiellement mortels, il existe néanmoins une résistance générale dans l'industrie à la gestion de la qualité, de la sûreté et de la sécurité du logiciel.

Comme le souligne Koopman, « ... au moins certains de ces rappels semblent liés à des erreurs qui ne devraient tout simplement pas se produire dans les logiciels critiques. » Dans cet article sont répertoriés des récents rappels de sécurité de la NHTSA liés à des défauts logiciels. Mais le but de Koopman est clair, il ne s’agit pas de faire honte à un fabricant en particulier, mais plutôt insister sur « … le fait est que les défauts logiciels critiques pour la sécurité sont à la fois omniprésents et persistants dans l'industrie automobile… les États-Unis n’étant tenus de suivre les normes internationales de sécurité des logiciels. »

Koopman présente également dans son blog une liste assez longue de problèmes identifiés qui sont devenus des rappels de la NHTSA, ce qui signifie que ces problèmes représentaient un danger suffisamment important pour la sécurité pour justifier un rappel. Voici quelques exemples directement liés à un logiciel défectueux :

• L'ABS et le contrôle dynamique de stabilité (DSC) sont désactivés en raison d'un défaut dans le contrôle de diagnostic au démarrage, désactivant les deux systèmes. (Rappel NHTSA 21V-167)
• Des vulnérabilités de sécurité des logiciels radio qui peuvent être exploitées pour donner un contrôle à distance non autorisé de certains systèmes du véhicule, augmentant le risque d'accident. (Rappel NHTSA 15V-461, 15V-508)
• Le programme de stabilité électronique (ESP) fait tirer le véhicule d'un côté de manière inattendue lors d'une manœuvre d'évitement. (Rappel NTSA 21V-071)
• Le système de freinage électronique intégré peut détecter un signal de capteur anormal diminuant les performances de freinage. Ce défaut a été identifié comme un manque de logique de sécurité appropriée dans le logiciel de contrôle. (Rappel NHTSA 20V-748)
• Problème du programme de gestion de la stabilité causant une intervention incorrecte en raison de défauts dans le logiciel du capteur de lacet, en particulier avec les procédures de diagnostic. La dérive du capteur dans ce cas peut augmenter le risque d'accident.
• Le freinage d'urgence automatique peut ne pas s'activer en raison d'un code logiciel manquant et d'incompatibilités avec le nouveau matériel utilisé.

Cette liste n’est pas exhaustive, Il y a bon nombre d'autres exemples, mais elle est représentative. Il existe de nombreux autres rappels comme ceux-ci, liés à des défauts logiciels et matériels, qui affectent des organes critiques pour la sécurité tels que la stabilité, le freinage et le contrôle du moteur.

De toute évidence, la sûreté et la sécurité des logiciels automobiles sont un problème systémique indiquant le besoin de changements dans la culture d'entreprise, les processus et la technologie. Il y a aussi des problèmes lié au principe de l'auto-certification et il n'y a pas d'adoption universelle de normes telle que ISO 26262, du moins concernant les fabricants américains. Comme il s'agit d'un sujet trop vaste pour être traité dans un seul article, concentrons-nous sur certains des processus et procédures qui peuvent être améliorés grâce aux outils de Test Statique de Sécurité des Applications (SAST) et l'Analyse de la Composition Logicielle (SCA.) 

La puissance de la technique SAST est qu'elle ne s'appuie pas sur des cas de test pour trouver des erreurs, ni n'exige qu'une erreur ou un échec soit reproduit. Un outil SAST avancé, comme GrammaTech CodeSonar, peut déduire le comportement d'exécution d'un programme sans réellement l’exécuter. De plus, lorsqu'il identifie un problème, il identifie également les emplacements (chemins) dans le code qui provoquent le problème, rendant ainsi le travail de débogage beaucoup plus simple.

• L'analyse statique n'élimine pas complètement le besoin de tester dynamiquement le logiciel, mais elle complète grandement ces activités, fournissant une technique de validation critique supplémentaire. La réalité est que dans les systèmes logiciels vastes et complexes, il y a tellement d'états possibles, et un nombre si astronomique de chemins d'exécution possibles, qu'il est impossible de tous les tester de manière exhaustive. L'analyse de code statique peut explorer ces chemins et conditions d'état dans l'agrégat, et est capable de trouver des problèmes qui sont manqués par les tests.
• Prévention grâce aux règles de codage : les règles de codage sont une partie importante du développement des logiciels critiques, car elles définissent un sous-ensemble plus sûr d'un langage de programmation. La norme la plus utilisée dans les logiciels automobiles est MISRA C et C++ (avec une mention honorable à la norme connexe AUTOSARC++) Ces normes définissent un sous-ensemble de C ou C++ qui est mieux adapté aux logiciels critiquesdont l'accent est mis sur l'évitement des constructions linguistiques dangereuses connues et des parties du langage avec un comportement potentiellement indéfini. L'application d'une norme de codage sûre et sécurisée plus stricte permet d'éviter de nombreux défauts logiciels en premier lieu.
• La couverture de code : De nombreuses normes de sécurité exigent des niveaux élevés de couverture de code (preuve que les tests ont exécuté la plupart, sinon la totalité, des instructions et des conditions). Bien que cela soit très exhaustif, c'est très coûteux à faire et doit être répété à chaque grande phase de développement (tests unitaires, intégration et système). La criticité du logiciel dicte le niveau de couverture et certains logiciels moins critiques ne nécessitent aucune couverture de test formelle (par exemple, les systèmes d’info-divertissements à bord des avions). Tester la couverture du code est une mesure permettant d'évaluer la qualité du logiciel, mais il y a des cas où elle ne détecte pas tout.
• Vulnérabilités et bogues non détectés par les tests basés sur la couverture : les tests de couverture de code sont intrinsèquement orientés sur les tests unitaires (bien que la couverture soit également évaluée au niveau de l’intégration). Les erreurs de simultanéité et les vulnérabilités de sécurité sont deux exemples clés de défauts qui peuvent être manqués même lors de tests rigoureux. La simultanéité est souvent difficile à programmer correctement et peut générer des erreurs (par exemple, des conditions de concurrence) qui ne sont pas détectées jusqu'à ce que certaines conditions imprévues apparaissent durant le fonctionnement. Les vulnérabilités de sécurité se manifestent par des bogues dans le code - les conditions créant l'erreur sont souvent dues à des types d'entrée non pris en compte lors des tests. L’approche SAST peut détecter ces types erreurs et ce au plus tôt dans le cycle de développement permettant ainsi de ne pas être des obstacles potentiels à la fin du développement.
• Détecter les défauts au plus tôt : des tests rigoureux permettent de découvrir la plupart des défauts des logiciels, mais ils sont coûteux et prennent énormément de temps. La découverte et la correction de ces erreurs durant la phase d'écriture du code permet de réduire considérablement le coût de test que plus tard dans le cycle de développement (la découverte des défauts est exponentiellement plus coûteuse au fil du temps). L'analyse statique peut détecter des erreurs dans le code dès qu'il est écrit dans l’environnement de développement du développeur, réduisant considérablement le coût de correction.
• Analyser le code open source et tiers : L'utilisation de code tiers et de logiciels open source est une réalité dans le développement des logiciels embarqués. Certaines normes de sécurité considèrent tout logiciel qui n'est pas développé selon la norme spécifique comme un logiciel de pedigree inconnu (SOUP) - logiciel qui doit être examiné attentivement pour être intégré dans le système. Les outils d'analyse de composition logicielle, comme GrammaTech CodeSentry, peuvent analyser des binaires tiers pour découvrir les défauts et les vulnérabilités de sécurité ainsi que générer une nomenclature logicielle (SBOM) - un artefact de développement de plus en plus important.

L'intégration d’outils SAST dans n'importe quel processus SDLC (Secure Development Lyfe Cycle) est simple avec les bons outils et peut être effectuée à n'importe quelle étape. De plus, CodeSonar et CodeSentry ne nécessitent aucune modifications des processus de Build ou du Code source.. Une fois installé et configuré, ils s'exécutent de manière transparente à chaque build. Cela permet d’avoir une détection des bugs en continu, au fur et à mesure qu'ils sont introduits, lorsque le coût de leur correction est minimal.

Résumé

Les rappels pour défauts de sécurité de la NHTSA liés aux logiciels sont en augmentation et cela indique que le développement de logiciels automobiles doit encore être amélioré. Cependant, le développement de logiciels embarqués pour les systèmes automobiles nécessite une approche et un engagement rigoureux pour accroître la sûreté et la sécurité. Les changements doivent être effectués, d’une part de haut en bas d’un point de vue culturel dans l’entreprise et dans les processus, et  cela nécessite d’autre part, des changements du bas vers le haut avec de meilleures pratiques, y compris l’adoption de standards de codage et autres méthodes éprouvées pour améliorer la qualité du code.

Des outils d'analyse statique avancés tels que CodeSonar aident à automatiser l'application des règles de codage et prennent en charge les activités de conformité vis-à-vis des normes. Plus important encore, ils jouent un rôle essentiel dans la recherche d’erreurs dans le code qui ne sont pas détectées lors d'autres activités de vérification et de validation et aident les développeurs à comprendre et à corriger les problèmes de leur code. Les outils d'analyse de composition logicielle tels que CodeSentry peuvent vérifier les vulnérabilités connues des logiciels open source et tiers et créer une nomenclature logicielle (SBOM) permettant de contrôler la qualité de la chaine d’approvisionnement des logiciels tiers (partenaires, sous-traitants) permettant de réduire le risque en terme de sûreté et de sécurité.