Introduction de la norme de codage MISRA C à une base de code existante

Temps de lecture : 5 minutes

L'intention de la norme de codage C de la Motor Industry Software Reliability Association ( MISRA ) était de définir un sous-ensemble du langage C qui minimise les possibilités d'erreurs. Bien qu'à l'origine destiné aux applications critiques pour la sécurité sur le marché automobile, il est utilisé dans d'autres domaines tels que le médical et l'aérospatiale. Certaines équipes logicielles utilisent également la norme comme moyen d'améliorer la qualité et la sécurité de leur code, mais n'exigent pas nécessairement la norme pour se conformer à une norme de sûreté ou de sécurité. MISRA C est une norme bien connue et respectée et elle se répand sur d'autres marchés.

L'objectif de MISRA est de fournir un meilleur code pendant le processus de développement. Appliquer les règles MISRA à du code déjà écrit, testé et/ou déployé n'est pas une tâche facile. La question est de savoir s'il est logique sur le plan commercial d'apporter des modifications à une base de code existante dont la fiabilité a été prouvée, avec le risque d'introduire de nouveaux problèmes lors des modifications. 
Cet article examine certaines approches pragmatiques pour adopter progressivement MISRA à l'aide d'outils de test de sécurité des applications statiques (SAST) tels que CodeSonar de GrammaTech.

L'approche d'adoption d'une nouvelle norme de codage dépend des exigences du nouveau système.

1. Si l'exigence est d'atteindre une conformité totale à MISRA, alors la base de code existante devra être rendue conforme. CodeSonar peut certainement aider dans cette situation, mais ce n'est pas l'objet de cet article de blog.
2. Si, au lieu de cela, MISRA est utilisé pour fournir un meilleur code à l'avenir, cet article propose une approche intéressante.

Il est important de réaliser que toutes les directives MISRA C ne sont pas égales. Les lignes directrices sont soit des règles, soit des directives, la différence étant que les règles sont complètement décrites dans la norme et que la conformité à une règle peut être vérifiée, généralement automatiquement avec des analyseurs de code statiques. Une directive est moins définie et nécessite des informations supplémentaires, généralement fournies lors d'un audit, pour garantir la conformité. Pour les besoins de cet article, nous parlerons des directives MISRA C en tant que règles standard de codage.

Les normes de codage classent généralement les règles par gravité et MISRA C n'est pas différent. Les règles MISRA C se divisent en trois catégories, obligatoires, requises et consultatives. Comme on pouvait s'y attendre, les règles obligatoires sont les plus critiques et les conseils le sont moins. Si le plan est d'utiliser MISRA C pour éviter les erreurs les plus flagrantes, votre équipe peut décider d'ignorer les règles consultatives, du moins au début.

La première étape de l'adoption de MISRA C consiste à examiner l'ensemble de règles et à sélectionner les règles consultatives les plus applicables à l'application en cours, créant ainsi votre propre sous-ensemble MISRA. Il s'agit d'une approche tout à fait légitime que les nouveaux arrivants négligent, estimant qu'il s'agit d'un ensemble de règles « tout ou rien » et, par conséquent, écrasante. Si votre organisation envisage d'utiliser MSRA C comme base pour votre propre norme de codage personnalisée, sans avoir besoin d'une conformité totale à MISRA C, une sélection supplémentaire est possible.

Bien sûr, appliquer MISRA C à une base de code existante peut être un gros investissement, vous pouvez avoir des milliers de violations à évaluer, ce qui n'est pas toujours utile car votre code est déjà testé et expédié. Changer le code de travail pour le rendre conforme à une norme de codage n'est pas toujours un bon investissement. Ce qui peut être plus viable financièrement, c'est de commencer par s'assurer que votre nouveau code est conforme à MISRA C. 

La façon d'y parvenir avec CodeSonar est d'exécuter une analyse sur l'ensemble de votre base de code source et de mettre en évidence les violations. Vous pouvez ensuite utiliser ces résultats comme base de comparaison. Nous allons plus en détail sur l'adoption de SAST dans un code existant dans cet article. Cette comparaison ne met désormais en évidence que les violations MISRA dans le nouveau code développé après la ligne de base. Ce nouveau code peut être soit dans de nouveaux fichiers, soit même ajouté à des fichiers existants. Les violations des règles MISRA peuvent être transmises au développeur directement dans son IDE, ce qui "arrête le saignement".

Un moyen pour les développeurs de faciliter l'utilisation d'une nouvelle norme de codage signifie une certaine préparation à l'avance afin de réduire le risque que l'équipe soit submergée de rapports. Les étapes suivantes fournissent un résumé rapide des étapes nécessaires :

• Définissez un ensemble de règles pour le projet : Il est possible que vous ayez déjà une norme de codage, et en tant que tel, vous envisagez peut-être MISRA C comme un moyen d'étendre ce que vous avez. Si ce n'est pas le cas, et que la conformité totale n'est pas l'objectif final, c'est une bonne idée de décider quelles règles l'équipe prévoit d'adopter.
• Configurez CodeSonar pour prendre en charge l'ensemble de règles défini par l'équipe. Il est logique, bien sûr, de garder également activées diverses règles de bogue et de vulnérabilité de sécurité.
• Utilisez le filtrage pour vous concentrer sur les violations les plus critiques. Une fois qu'un rapport de base a été généré, CodeSonar dispose de puissantes fonctionnalités de filtrage et de recherche enregistrée pour aider les développeurs à se concentrer d'abord sur les violations les plus critiques. Il est également possible de filtrer uniquement les modifications de la dernière version, d'évaluer les violations par type, gravité ou par fichier.
• Concentrez-vous d'abord sur le nouveau code. Selon l'approche préférée, le rapport de lignes de base peut être filtré en définissant l'état des violations existantes sur "différer" ou simplement filtrer les nouveaux rapports en fonction des deltas entre les versions. Dans les deux cas, l'évaluation se concentre sur les modifications apportées au code ou sur le nouveau code écrit.
• Évaluer et hiérarchiser les violations. Il est important d'évaluer les violations dans le nouveau code au fur et à mesure qu'elles surviennent et nous entendons par là analyser si la violation est réelle, décider si elle doit être corrigée et attribuer une priorité au correctif. Cela ne devrait pas être trop onéreux lorsque vous vous concentrez sur un nouveau code. Cependant, l'équipe peut être dépassée si les violations ne sont pas gérées à chaque itération.
• Évaluez le code existant, si le temps le permet, par ordre de gravité. Si l'équipe décide d'examiner l'état du code existant (avant la ligne de base et avant que nous "arrêtions le saignement"), il est logique de considérer d'abord les violations les plus graves. C'est là que les puissantes capacités de recherche, de tri et de filtrage de CodeSonar sont utiles. Des évaluations peuvent d'abord être effectuées sur les règles obligatoires, par exemple, et des correctifs peuvent être attribués et hiérarchisés.

L'adoption de MISRA C à un projet existant qui ne nécessite pas de conformité officielle peut toujours être une démarche décourageante sans une approche réfléchie. Cette approche pragmatique se concentre sur le nouveau code, initialement, et sur l'évaluation des violations standard de codage par ordre de gravité. CodeSonar prend en charge à la fois MISRA C et les options de configuration, ainsi que les fonctionnalités de filtrage et de recherche qui font de cette approche pragmatique une réalité pour les développeurs de logiciels. 

Pour en savoir plus, nous vous invitons à télécharger et à lire ce livre blanc, « Accélérer la conformité de la sécurité automobile MISRA avec les tests de sécurité des applications statiques ».