Développer un système Sûr & Secure : CERT-C vs MISRA-C :2012 : AMD1

Le cycle de développement traditionnel dans les marchés de la sécurité (au sens anglais Security) est en grande partie réactif, et le codage est réalisé principalement sur une base Agile informelle, sans atténuation des risques et sans directives de codage formelles. Les exécutables qui en résultent sont ensuite soumis à des tests de performances, de pénétration, de charge et fonctionnels pour tenter de trouver les disfonctionnements et les vulnérabilités qui en résultent. L'espoir, plutôt que l'attente, est que tous les problèmes seront trouvés et correctement solutionnés sans entrainer l’occurrence de nouvelles failles.

En revanche, dans les industries critiques en termes de sécurité fonctionnelle (au sens anglais Safety) telles que l'avionique, l'automobile, le ferroviaire ou le médical, pour ne citer que ceux-là, la pratique acceptée, voire recommandée ou imposée, consiste à appliquer un processus de développement de logiciel formalisé. L'utilisation de règles de codage (« sous-ensembles » du langage de programmation utilisé) en fait partie intégrante, car il est prouvé que pour les développeurs C et C++, environ 80% des défauts logiciels sont causés par l'utilisation incorrecte d'environ 20% des constructions qu’offrent ces langages. Restreindre l'utilisation de ces instructions ou constructions problématiques de ces langages réduit le nombre de défauts associés et améliore ainsi la qualité globale du logiciel.

Pour traiter les problèmes de sécurité inhérents aux langages de programmation, de nombreuses organisations intervenant dans les systèmes critiques ont étendu leurs modèles formels de développement orientés sécurité fonctionnelle, afin de traiter les problématiques de sécurité. Pour ce faire, ils utilisent des règles de codage telles que MISRA ou CERT pour minimiser les vulnérabilités. Il est donc utile de comparer la manière dont les principes des règles de codage du SEI CERT C et les directives MISRA-C:2012 avec la version MISRA-C:2012:Amendement 1 [3]" et de voir si elles correspondent aux exigences des cycles de développement ainsi qu’aux demandes formelles de ces secteurs industriels.

Adoption rétrospective
Un premier exemple de différence entre le CERT-C et MISRA est l'adoption rétrospective.

MISRA-C:2012 stipule que « le standard MISRA-C devrait être adopté dès le début d'un projet. Si un projet s'appuie sur un code existant qui a fait ses preuves, les avantages de la conformité à MISRA-C peuvent être contrebalancés par les risques d'introduire un défaut lors de la mise en conformité du code ». En d'autres termes, MISRA déconseille l'adoption rétrospective du standard.

Cela contraste avec l'affirmation dans le CERT-C que bien que « la priorité de cette norme soit de soutenir le développement de nouveaux codes ... Une seconde priorité est de prendre en charge la correction de l'ancien code ».

Certes, une application rétrospective du standard sur un sous-ensemble vaut toujours mieux que de ne rien corriger, mais elle ne représente pas les meilleures pratiques - et n'est pas quelque chose à préconiser lorsque la sécurité et la sûreté sont primordiales.

Pertinence pour les systèmes de sécurité, de haute intégrité et de haute fiabilité
Les normes diffèrent également de manière significative sur ce point. Le standard MISRA-C:2012 affirme qu'il peut être « ... utilisé pour développer toute application ayant des exigences de haute intégrité ou de haute fiabilité ». Le résultat est que MISRA-C:2012 a toujours été approprié pour le développement d’applications critiques sûres et sécurisées, et ce, avant même les améliorations de sécurité apporté par son amendement 1.

Le CERT-C tente d'être plus complet, couvrant la programmation d'applications comme POSIX en plus du langage C lui-même. Cela peut s’expliquer par le fait que le CERT-C considère que « les systèmes critiques ont généralement des exigences plus strictes que celles imposées par cette norme ».

Décidabilité
L'objectif principal d'un processus de développement de logiciels axé sur les exigences tel qu'indiqué par la norme ISO 26262 - une norme de sécurité fonctionnelle pour les applications automobiles - est de contrôler le processus de développement aussi étroitement que possible afin de minimiser les erreurs ou les incohérences. Bien que cela soit théoriquement possible par des moyens manuels, il sera généralement beaucoup plus efficace d’utilisés des outils pour automatiser le processus.

Les outils d'analyse statique exigent que les règles de codage puissent être vérifiées de manière algorithmique. Si on compare par exemple les extraits illustrés figure 1, qui traitent tous les deux du même problème, l'approche adoptée par MISRA est d'empêcher le problème en interdisant l'inclusion de la construction. Le CERT-C affirme lui que le développeur devrait « en être conscient ».

L'approche CERT-C est clairement plus flexible, ce qui est un avantage pour appliquer les règles rétrospectivement. MISRA-C:2012 est plus draconien, mais en évitant les effets secondaires, le code résultant sera vérifiable par un outil d'analyse statique (et, accessoirement, plus portable). Il n’est pas possible pour un outil de vérifier si un développeur est « conscient » des effets secondaires, et encore moins si la « sensibilisation » équivaut à la « compréhension ».

Les règles de codage spécifiées par le CERT-C et MISRA-C:2012+AMD 1 sont conçues pour être utilisées dans le développement de logiciels sécurisés, et l'application correcte de l'une ou l'autre aboutira à un code plus sûr que si aucun de ces standards n’est appliqué. Cependant, l'objectif déclaré de MISRA de « fournir des lignes directrices de bonnes pratiques utilisable à l’échelle mondiale pour le développement d’applications logicielles sûres et sécurisées, que ce soit pour la conception de systèmes embarqués ou la conception de logiciels autonomes ». Cela contraste avec la mission élargie du CERT-C, et c'est peut-être pourquoi MISRA-C:2012 se prête mieux aux applications critiques, et pourquoi un grand nombre de ses règles sont conçues pour être détectables et décidables par des outils d'analyse statique.

Inversement, il existe un argument en faveur de l'utilisation de la norme CERT-C, car elle est plus tolérante. Dans le cas d’une application non critique ou moins critique mais qui doit être connectée à Internet pour la première fois, la possibilité d’appliquer rétrospectivement les règles CERT-C peut être un choix pragmatique à faire.

En vérité, il n'y a pas de meilleur choix dans la comparaison de ces deux standards. Il y a de fortes chances qu'aucune norme de codage « sur étagère » ne convienne parfaitement à votre organisation et à vos processus. Il est même fort probable, que c’est une combinaison de règles de ces deux standards, voire d’autres qui pourra convenir au mieux à vos objectifs et exigences.

Dès lors, la meilleure stratégie pourrait consister à ne pas sélectionner un standard mais à sélectionner l’outil d’analyse statique capable de fusionner les meilleures règles fondamentales des différents standards de règles de codage.

A noter qu’ISIT, pour répondre à la problématique du choix de règles de codage, et au départ à la justification d’adopter des règles de codage pour un projet, propose une formation « Règles de codage » sur 2 jours. L’objectif n’est pas de former les utilisateurs sur un standard particulier, mais d’aborder les grands principes, de comprendre les différentes normes, leurs avantages et inconvénients, et de permettre ainsi aux développeurs un choix éclairé.