Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Blog Parasoft
L'Internet des objets n'a cessé d'évoluer, mais comment s'assurer qu'il respecte les normes de sécurité et de sûreté ? Voici trois façons de vous assurer que vos appareils IoT intégrés répondent aux futures normes de sécurité et de conformité.
Aller à la section
Malgré le potentiel des appareils embarqués dans le contexte de l'IdO, de nombreux appareils ne sont actuellement pas tenus de se conformer aux normes de sûreté ou de sécurité. Mais dans le monde Agile du développement IoT, les exigences de conformité peuvent venir beaucoup plus tard, une fois que le code a déjà été écrit et testé. Alors, comment préparer l'avenir de vos appareils IoT embarqués?
L'Internet des objets (IdO) désigne un système d'appareils, de composants ou de services connectés en réseau qui publient et/ou utilisent des données. Les applications IdO s'intègrent de plus en plus à notre quotidien : des robots industriels et instruments chirurgicaux aux voitures autonomes et drones. Nombre de ces appareils peuvent déjà avoir un impact sur la sécurité et la confidentialité des données de leurs utilisateurs. Dans certains cas, les conséquences d'une défaillance peuvent être mortelles ; il est donc essentiel de les concevoir conformément aux normes en vigueur.
S'il est préférable d'intégrer les activités de conformité dès le début de la conception logicielle, il est bien connu que des processus de développement rigoureux (surtout sans automatisation) peuvent impacter les délais de mise sur le marché. Rares sont les développeurs qui apprécient effectuer des tests supplémentaires et documenter la traçabilité en dehors des heures de travail habituelles. Les équipes pragmatiques, agiles et dynamiques ne peuvent donc souvent pas se permettre de perdre leur élan en intégrant la conformité au planning sous prétexte qu'elles pourraient en avoir besoin ultérieurement. Au lieu de cela, de nombreuses équipes choisissent de « franchir le pas quand elles le pourront ».
Malheureusement, il n'existe pas de solution miracle ni de solution miracle permettant de rendre rétroactivement un code conforme. Ces organisations apprennent à leurs dépens que le coût de la mise en conformité en fin de projet est bien supérieur au coût de développement du produit initial fonctionnel.
Alors, quelles actions à faible impact pouvez-vous prendre aujourd'hui pour vous préparer à satisfaire les exigences de conformité strictes de demain?
Il est important de comprendre où en est votre projet actuellement . La dette technique représente le coût des reprises potentielles dues à la complexité du code, combiné aux violations des normes de codage et de sécurité qui y subsistent. Cette dette est liée aux opérations ultérieures de nettoyage, de correction et de test du code. L'analyse statique de code automatisée est un moyen efficace d'évaluer précisément l'état actuel d'un projet. Elle permet d'analyser la qualité et la sécurité du code et de recenser les violations des normes de codage, le cas échéant.
Malheureusement, de nombreuses équipes développant des applications embarquées en C et C++ s'appuient encore sur leur compilateur ou sur des revues de code manuelles pour détecter les problèmes, au lieu d'adopter l'analyse statique. Certaines équipes peinent à adopter les outils d'analyse statique pour diverses raisons : elles les jugent bruyants et difficiles à utiliser (ce qui ne devrait pas poser de problème si l'on apprend à les maîtriser ), ou elles n'arrivent pas à les intégrer au processus de développement quotidien en raison d'urgences. Une idée reçue (et erronée) courante est que le temps passé à identifier les violations à corriger est supérieur à la valeur de la correction elle-même.
Mais nous constatons que les équipes qui ont adopté un petit ensemble de règles critiques et obligatoires ont passé beaucoup moins de temps à retravailler le code face à des audits de sécurité fonctionnelle plus tard dans le projet. Il est beaucoup plus facile de créer des systèmes sûrs et sécurisés à partir de zéro en intégrant la sécurité en implémentant, par exemple, les directives de codage sécurisé CERT C. Vous pouvez commencer petit. CERT dispose d'un système de hiérarchisation sophistiqué (utilisant la gravité, la probabilité et le coût de la correction, chacun en 3 niveaux, 27 niveaux au total), et si vous utilisez les outils Parasoft, vous pouvez facilement afficher l'état de la conformité dans un tableau de bord préconfiguré.
L'analyse statique aide également les organisations à comprendre leur dette technique en collectant des points de données qui aident la direction à respecter la sûreté et la sécurité. Les gestionnaires peuvent facilement évaluer les questions importantes, telles que:
Certaines normes exigent la mesure de la complexité cyclomatique afin de la maintenir en dessous d'un certain seuil. Les métriques de complexité peuvent également servir à estimer l'effort de test ; par exemple, le nombre de cas de test nécessaires pour démontrer une couverture de 100 % au niveau des branches, conformément à la norme IEC 61508 SIL 2, sera proportionnel à la complexité cyclomatique de McCabe de la fonction.
Voici un exemple tiré d'un tableau de bord illustrant la conformité MISRA d'un projet au sein de Parasoft DTP, la plateforme de reporting et d'analyse de Parasoft :
Et voici la même chose pour CERT C:
La valeur de voir les métriques de code peut aider à exposer des zones plus complexes pour une révision de code supplémentaire et à surveiller dans quelle mesure ces zones sont couvertes par les tests. Voici un exemple de tableau de bord des mesures:
Vous pouvez donc commencer par les bases. Une fois que l'équipe maîtrise la gestion des erreurs les plus critiques, vous pouvez élargir l'étendue des violations des normes. Toutes les règles ne sont pas immuables ; il est donc important de déterminer celles qui sont incluses ou non dans la norme de codage du projet. Au minimum, l'adoption des règles obligatoires de quelques normes de codage clés (par exemple, les règles obligatoires MISRA ou les règles CERT C) facilite l'argumentation future en matière de sûreté et de sécurité d'un appareil connecté.
La plupart des ingénieurs pragmatiques s'accordent à dire que créer systématiquement des tests unitaires pour toutes les fonctions n'offre pas un bon retour sur investissement. Cependant, si votre équipe a accès à un framework de tests unitaires dans le cadre de son environnement de développement, il s'agit d'un investissement judicieux. Les tests unitaires peuvent être utilisés intelligemment lorsque les ingénieurs estiment nécessaire de tester de manière isolée certains algorithmes complexes ou manipulations de données. Le processus de développement des tests unitaires présente également une valeur significative : d'après notre expérience, le simple fait d'écrire et d'exécuter un test unitaire rend le code plus robuste et mieux conçu.
Lorsque des exigences de sécurité ou de conformité se posent, une organisation peut rapidement intensifier l'effort de test unitaire en ajoutant temporairement des membres du personnel. Mais pour faire évoluer rapidement cet effort, le cadre et le processus de test unitaire doivent déjà être compris et documentés au cours du projet. Les caractéristiques communes d'un cadre de test unitaire évolutif en tenant compte de la conformité future sont les suivantes:
La clé à retenir est de déployer toutes les techniques de test requises par une future norme de sécurité, mais à une échelle minimale. Il est plus facile pour cela d'évoluer quand et si un besoin de certification apparaît plutôt que de repartir de zéro.
La conception de systèmes embarqués exige de prendre en compte de nombreuses contraintes : simplicité, portabilité, maintenabilité, évolutivité et fiabilité, tout en trouvant des compromis entre latence, débit, consommation d'énergie et dimensions. Lors de la conception d'un système susceptible d'être connecté à un vaste écosystème IoT, de nombreuses équipes négligent la sécurité au détriment d'autres facteurs de qualité.
Pour faciliter la mise en conformité future en matière de sécurité (et suivre les bonnes pratiques architecturales), vous pouvez séparer les composants dans le temps et l'espace. Par exemple, vous pouvez concevoir un système où toutes les opérations critiques sont exécutées sur un processeur dédié, tandis que toutes les opérations non critiques sont exécutées sur un autre, assurant ainsi une séparation physique. Une autre option consiste à utiliser un hyperviseur à noyau de séparation et les concepts de micro-noyau. D'autres options existent, mais l'essentiel est d'adopter au plus tôt les approches architecturales clés que sont la séparation des préoccupations , la défense en profondeur et la séparation pour les criticité mixte . Ces approches réduisent non seulement la charge de travail nécessaire à la conformité aux normes de sécurité, mais elles améliorent également la qualité et la résilience de l'application. Voici, par exemple, quelques méthodes pour isoler le code critique :
La séparation des fonctions critiques des fonctions non critiques réduit la portée des efforts de vérification futurs pour démontrer la conformité.
De nombreux appareils de périphérie de l'écosystème IoT fournissent des services critiques susceptibles de relever de futures normes de sûreté et de sécurité. Bien entendu, essayer de se conformer aux exigences des normes, sans savoir si c'est nécessaire ou non, n'est pas une stratégie rentable. Pour se préparer à l'avenir, les organisations peuvent adopter des techniques de conception clés, des approches de test unitaire et des outils d'analyse statique, et collecter des mesures pour répondre aux besoins futurs. Les équipes logicielles peuvent adopter ces approches de manière transparente dans leurs processus existants si elles ont été lancées suffisamment tôt. Commencer tôt avec la bonne approche qui peut être mise à l'échelle plus tard pour éviter la nécessité d'un effort presque herculéen pour mettre le code logiciel en conformité lorsqu'il a été développé, testé et déployé.
« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Tous droits réservés.
Blog
8 min de lecture
Blog
12 min de lecture
Blog
7 min de lecture
