Une once de prévention: la sûreté et la sécurité grâce aux normes de codage des logiciels

La mise en œuvre et le maintien de la bonne norme de codage pour vos projets de développement sont essentiels pour fournir des solutions logicielles sécurisées. Dans cet article, notre expert explique pourquoi vous devez vous assurer de maintenir la bonne norme de codage et comment vous pouvez le faire.

Les logiciels ont migré des ordinateurs de bureau vers presque tout ce que nous touchons. Des thermostats intelligents aux pompes à perfusion en passant par les voitures, ils sont omniprésents et en pleine expansion. Les « objets » issus de l'Internet des objets (IoT) sont de plus en plus logiques. Ce qui implique un risque accru de défaillance. Nombre de ces appareils sont utilisés dans des domaines critiques pour la sécurité, comme le médical et l'automobile, où ils présentent un risque de blessures corporelles.

La plupart des entreprises qui fabriquent des appareils considèrent à juste titre le développement logiciel actuel comme une entreprise quasi insensée et chaotique. Mais il y a de l'espoir. Le logiciel PEUT et DOIT être traité comme une pratique d'ingénierie. Les normes de codage, qui font partie intégrante des bonnes pratiques d'ingénierie logicielle, nous font passer du cycle « créer, échouer, corriger » à un cycle « concevoir, construire, livrer » garantissant une qualité, une sécurité et une sûreté élevées.

Il s’avère que ces mêmes normes offrent également des avantages dans le domaine de la cybersécurité, remplissant une double fonction.

Du développement logiciel au génie logiciel

L'impact du logiciel sur le monde réel est souvent ignoré. L'un de mes principaux thèmes dont je discute continuellement en tant qu'évangéliste chez Parasoft, est que le développement logiciel devrait vraiment être l'ingénierie.

On les appelle ingénieurs logiciels, mais le titre est loin de la réalité. Le codage devient ingénierie lorsque le travail est régi par une norme – une norme de codage – appliquée dès l'écriture du code et contrôlée par des vérifications. C'est ce qui permet de réduire les coûts et d'améliorer la qualité.

L'ère des véhicules définis par logiciel, de l'IoT médical et industriel et des appareils perpétuellement connectés est arrivée. Les logiciels se glissent dans les produits, les appareils et d'autres endroits auxquels nous n'avions jamais pensé. Nous devons maintenant réfléchir sérieusement au logiciel de ces produits et à ses ramifications.

Le coût d'une mauvaise qualité

L'une des choses intéressantes que j'essaie d'expliquer est que la construction d'un bon logiciel est différente de la construction de quelque chose comme une voiture. Si j'essaie de construire une voiture de haute qualité, je dois passer plus de temps sur les matériaux et plus de temps pour la construire. Il s'avère que dans les logiciels, vous ne dépensez pas plus pour créer des logiciels de haute qualité. Vous dépensez plus pour créer des logiciels de mauvaise qualité.

Il faut comprendre que dans le logiciel, la plupart des défauts proviennent du programmeur, qui les met dans le produit. Si nous pouvons arrêter d'introduire des défauts au fur et à mesure que nous développons le logiciel, nous pouvons avoir un logiciel bien meilleur, à un prix inférieur.

Cette citation est extraite d'une conférence de 1972, intitulée « Le programmeur humble », écrite par Edsger W. Dijkstra. Elle reste très pertinente aujourd'hui.

Il est essentiel de comprendre l'impact de la qualité sur les coûts de développement logiciel. Capers Jones , chercheur, étudie cette question depuis des décennies et réalise chaque année une enquête sur les coûts logiciels. Les chiffres restent relativement stables d'une année sur l'autre. Les données montrent que le coût moyen d'un logiciel, des spécifications à la maintenance en passant par le codage, augmente à chaque étape. Cependant, la manière dont les équipes abordent la qualité détermine si leur processus est sain ou dysfonctionnel.

Pourquoi nous devons corriger rapidement les défauts

Il est logique que si nous trouvons un défaut juste au moment où le code est écrit, le coût est relativement peu élevé - quelques minutes du temps d'un développeur, par exemple. S'il est possible d'éliminer 85 % des défauts en phase de développement, cela a un gros impact sur les coûts. Considérez le graphique désormais célèbre de Capers Jones montrant le coût moyen de la correction des défauts à chaque étape du développement :

La correction des défauts après la publication coûte environ 16,000 15 $ (peut-être beaucoup plus) sur la base de recherches sur de vraies entreprises faisant de vrais logiciels, et non sur un modèle théorique. Si nous examinons les efforts de qualité et de sécurité en fin de cycle tels que les tests de pénétration, les problèmes de sécurité trouvés ici se situent à la fin coûteuse du cycle. C'est probablement XNUMX fois plus cher que de trouver des vulnérabilités par le biais de tests par rapport à des audits de sécurité précoces.

Une approche obsolète et manifestement fausse consiste à améliorer la qualité d'un logiciel en le testant en fin de cycle de vie, juste avant sa sortie. Dans le monde de l'industrie, on comprend que c'est impossible, mais pour une raison inconnue, nous pensons pouvoir tester la qualité et la sécurité « intégrées » aux logiciels.

Les raisons pour lesquelles je dis que le développement logiciel n'est presque jamais de l'ingénierie sont ces caractéristiques communes du développement logiciel actuel:

• Ce que font la plupart des développeurs n'est pas reproductible. Cela signifie que si je confie la même tâche à deux personnes différentes, les résultats ne seront pas les mêmes.
• Manque de bonnes pratiques bien appliquées. Les développeurs de logiciels considèrent les normes de codage comme un terme dénué de sens. Ils les considèrent comme un ensemble de règles que le chef d'équipe m'oblige à suivre, au lieu de comprendre qu'elles incarnent les connaissances, la pratique et l'expérience. Un ingénieur électricien sait que les normes sont la clé pour créer un produit sûr dès la première fois. Un développeur de logiciels les perçoit comme une contrainte qui le ralentit…faux positifs."
• La formation des développeurs est inconnue et incohérente. La formation en développement logiciel n'est pas normalisée comme elle l'est avec les disciplines d'ingénierie. Les normes et les pratiques établies ne font souvent pas partie du programme, l'accent est plutôt mis sur les langages de programmation.

Les normes de codage améliorent la sûreté et la sécurité

L'objectif des normes de codage logiciel est d'inculquer des pratiques de programmation éprouvées qui conduisent à un code sûr, sécurisé, fiable, testable et maintenable. En règle générale, cela signifie éviter les pratiques de codage dangereuses connues ou le code susceptible de provoquer un comportement imprévisible. Cela devient critique dans les langages de programmation comme C et C++ où le potentiel d'écriture de code non sécurisé ou dangereux est élevé.

Cependant, je pense que l'industrie a perdu son chemin avec ces normes de programmation. Au cours de la dernière décennie, les outils (tels que les outils d'analyse statique) sont passés de la détection de code potentiellement problématique qui n'est pas sûr ou d'une faiblesse de langage connue à une concentration sur la recherche de défauts en tant que forme de test précoce, également connue sous le nom de décalage vers la gauche.

Bien que la recherche de défauts soit importante, la création de logiciels sonores est une activité plus productive. Ce que nous devrions faire, c'est élaborer et appliquer des normes pour éviter la situation où des défauts sont introduits en premier lieu - un déplacement encore plus vers la gauche.

Pour étayer cette affirmation, prenons l'exemple des recherches menées par le Software Engineering Institute (SEI), qui ont révélé, sans surprise, que sécurité et fiabilité sont indissociables et que la sécurité d'un logiciel peut être prédite par le nombre et les types de défauts de qualité détectés. De plus, les défauts critiques sont souvent des erreurs de codage qui peuvent être évitées grâce à des inspections et des outils tels que l'analyse statique.

Normes de l'industrie

Cet article n'entre pas dans les détails de chacune de ces normes de codage, mais il existe un travail considérable dans les normes industrielles suivantes. Bien que leur application puisse être spécifique à un type spécifique, ces normes sont adoptées dans de nombreuses industries. Voici quelques exemples de normes de codage établies pour la sûreté et la sécurité.

• MISRA C/C++. Développé par le Consortium MISRA, il décrit un sous-ensemble du langage C ou C++ et propose des directives d'utilisation pour améliorer la sécurité des applications. Initialement destiné aux applications automobiles, il est utilisé dans tous les secteurs, notamment pour les applications critiques pour la sécurité. « 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.
• CERT SEI / SANS. L'équipe d'intervention d'urgence informatique (CERT) du Software Engineering Institute (SEI) dispose d'un ensemble de directives pour aider les développeurs à créer des logiciels plus sûrs, plus sécurisés et plus fiables. Ces directives, classées par ordre d'importance par groupes de « règles » et de « recommandations », sont très complètes et générales, et incluent des métadonnées sur les risques.
• OWASP Top 10. Le projet de sécurité des applications Web ouvertes (OWASPL'OWASP, comme son nom l'indique, est une organisation qui se consacre à l'amélioration de la sécurité des applications web. À ce titre, son projet OWASP Top 10 fournit une liste des vulnérabilités de sécurité les plus courantes et les plus critiques des applications web. La dernière version de l'OWASP Top 10 est directement liée à des identifiants CWE spécifiques et inclut des métadonnées sur les risques.
• Norme de codage C ++ des véhicules aériens de combat interarmées (JSF AV). Une norme basée sur un sous-ensemble de MISRA C spécifiquement pour le programme JSF.
• CWE - Top 25 de l'énumération des faiblesses communes. CWE est une liste de faiblesses logicielles découvertes basée sur l'analyse des vulnérabilités signalées (CVE). Le Top 25 répertorie les faiblesses de sécurité les plus courantes et les plus dangereuses sélectionnées dans la liste plus large des CWE, qui sont toutes des exploits qui ont de fortes chances de se produire et que leur exploitation a un impact important. CWE inclut également des informations sur les risques sous forme d'impact technique, ce qui permet de comprendre les problèmes les plus importants pour votre organisation.

Prenons l'exemple de MISRA C , qui, comme je l'ai mentionné, ne se limite pas aux applications automobiles. Il s'agit d'une norme bien définie et utilisée depuis 1998. Elle est mise à jour tous les deux ans environ. À mesure que les langages C et C++ évoluent, les normes qui les entourent évoluent également. C'est une norme très flexible qui prend en compte différents niveaux de gravité et qui dispose d'une stratégie documentée pour la gestion et la documentation des écarts.

Les versions récentes de MISRA , qui utilisent des technologies permettant de détecter les violations des normes de codage, tiennent compte des normes qui sont décidables (détectables avec une grande précision par des outils) et de celles qui ne le sont pas. Ceci nous amène à aborder la question de l'adoption et de l'application des normes, ainsi que l'importance des outils d'analyse statique dans le cadre du codage.

Rôle de l'analyse statique

La recherche montre que la suppression inadéquate des défauts est la principale cause de logiciels de mauvaise qualité. Les programmeurs sont efficaces à environ 35 % pour trouver des défauts dans leur propre logiciel. Plus tard dans le cycle de développement, le plus grand nombre de défauts que nous pouvons espérer supprimer après toutes les revues de conception, les revues par les pairs, les tests unitaires et les tests fonctionnels est d'environ 75 %.

L'analyse statique, lorsqu'elle est utilisée correctement en mode préventif, peut augmenter l'élimination des défauts à environ 85%. Cependant, l'utilisation de l'analyse statique pour la plupart des organisations se concentre aujourd'hui sur la détection et la solution rapide.

D'autres avantages sont possibles lorsque des outils d'analyse statique sont utilisés pour éviter en premier lieu les mauvaises pratiques de programmation et les fonctionnalités de langage connues. C'est là que les normes de codage entrent en jeu en tant que directives et sous-ensembles de langage de programmation qui empêchent les défauts courants tels que les débordements de tampon ou l'initialisation manquante d'être écrits dans le code.

Une once de prévention

Prenons l'exemple d'une erreur de dépassement de tampon assez complexe détectée lors des tests, par exemple à l'aide d'un outil d'analyse dynamique des applications (DAST). C'est un coup de chance, car le test a justement exécuté le chemin d'exécution contenant l'erreur. Une fois détectée et corrigée, l'erreur doit être testée à nouveau, et ainsi de suite. Une analyse statique par analyse de flux aurait également pu la détecter, mais cela dépend de la complexité de l'application.

La détection des erreurs d'exécution est précise, mais elle ne vérifie que les lignes de code exécutées. Son efficacité dépend donc de la couverture de votre code de test. Imaginez si une norme de codage avait interdit le code à l'origine de cette erreur.

Les normes de codage comme MISRA C ne décrivent pas comment détecter la mémoire non initialisée, par exemple, mais guident plutôt les programmeurs pour écrire du code qui ne conduira pas à une telle erreur en premier lieu. Je crois qu'il s'agit bien plus d'une approche d'ingénierie : programmer selon des normes bien connues et acceptées. Prenons, par exemple, le génie civil et la construction de ponts.

Nous n'adopterions pas la méthode consistant à construire un pont, puis à le tester en y faisant passer des camions de plus en plus lourds jusqu'à ce qu'il s'effondre, à mesurer le poids du dernier camion ayant réussi à le franchir, et à le reconstruire pour qu'il puisse supporter ce nouveau poids. Cette approche serait absurde, et pourtant, elle n'est pas sans rappeler notre façon d'aborder le développement logiciel.

Construisez-le correctement du premier coup

Une fois qu'une équipe adopte une norme de codage et applique correctement l'analyse statique, la norme cesse d'être un filet à travers lequel on fait passer le code et commence à façonner le code au fur et à mesure de son écriture.

Détecter un défaut tôt est une bonne chose. Ne pas l'écrire du tout est mieux. C'est le principe du « shift left », poussé à l'extrême : non pas repérer les problèmes plus tôt, mais repousser l'échéance de la norme jusqu'à la phase de rédaction du code, afin que le problème ne se manifeste jamais.

C’est aussi là que la question de l’agent de codage trouve sa réponse d’elle-même. De plus en plus de code est généré plutôt que saisi manuellement. Le réflexe est de se demander si les normes sont toujours applicables.

Elles s'appliquent davantage.

Ce qui compte, ce n'est pas qui ou quoi écrit le code. C'est que le code réponde à la norme.

Vérifiez au moment de la rédaction : le code est alors conforme aux normes. Vérifiez par lots ultérieurement : vous obtenez une liste d’éléments à corriger.

Un développeur qui utilise un linter conforme aux normes et qui s'exécute en temps réel se situe du bon côté de la barrière. Il en va de même pour un agent de codage qui intègre l'analyse statique dans sa boucle, rejetant et régénérant le code avant même qu'un humain n'en voie le résultat.

Cela limite le nombre de lignes soumises à la vérification. Cela ne supprime pas la vérification. Même en plaçant la norme devant le générateur, le code renverra toujours des violations. Moins nombreuses qu'avec une simple invite, mais pas nulles.

Il faut donc procéder en deux étapes. Générer le code selon la norme, puis vérifier le résultat. Faire confiance, mais vérifier. La vérification, quant à elle, ne se soucie pas de savoir si la ligne a été écrite par une personne ou un modèle. L'analyse statique lit le code, pas les auteurs.

Prenons l'exemple de la faille Heartbleed . Il existe désormais des détecteurs pour cette vulnérabilité spécifique, mais il est possible de concevoir du code de manière à ce que Heartbleed n'ait jamais pu se produire. La prévention est une méthode plus efficace et plus sûre.

Résumé

Une méthodologie de prévention efficace coûte moins cher que la correction des bugs qu'elle permet d'éviter.

« Ceux qui veulent un logiciel vraiment fiable découvriront qu'ils doivent trouver des moyens d'éviter la majorité des bogues dès le départ. »

—Dijkstra

Les normes de codage sont des principes d'ingénierie rigoureux rendus applicables ; elles incarnent le savoir, la pratique et l'expérience. Ce savoir réside dans la norme elle-même, et non dans l'esprit d'un seul auteur. C'est ce qui distingue le codage du simple codage et relève de l'ingénierie. Le travail est régi par une norme, appliquée dès l'écriture du code et vérifiée à la fin, garantissant ainsi un résultat robuste par conception plutôt que par débogage a posteriori.

L'objectif n'a jamais été de devenir plus performant dans la détection des bugs, mais d'arrêter d'en écrire.
Ne corrigez pas le code. Écrivez un meilleur code.

Que ce code provienne d'un développeur ou d'un générateur, la norme et la vérification restent les mêmes.

Un bon logiciel coûte moins cher qu'un mauvais. Si vous n'utilisez pas l'analyse statique aujourd'hui, ou si vous ne l'utilisez que pour la détection précoce des vulnérabilités, découvrez les outils d'analyse statique de Parasoft pour C et C++ , Java , C# et VB.NET. Ils intègrent une bibliothèque complète de vérificateurs pour toutes les normes de sécurité courantes.