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

Le logiciel est passé du bureau à presque tout ce que nous touchons. Des thermostats intelligents aux pompes à perfusion en passant par les voitures, le logiciel est omniprésent et en pleine croissance. Les soi-disant «choses» de l'Internet des objets (IoT) portent de plus en plus de logique. Avec elle, un plus grand risque d'échec. Bon nombre de ces dispositifs sont utilisés dans des domaines critiques pour la sécurité tels que le médical et l'automobile, où ils présentent un potentiel de lésions corporelles.

La plupart des entreprises qui construisent des appareils considèrent à juste titre le développement logiciel actuel comme un groupe presque insensé de cow-boys et de chaos. 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 «construire, échouer, réparer» à un cycle «concevoir, construire, livrer» avec une qualité, une sûreté et une sécurité élevées.

Il s'avère que ces mêmes normes offrent également des avantages dans les domaines de la cybersécurité, en faisant un double devoir. Cet article traite:

• Comment ces normes nous aident à passer de la recherche de défauts à la création de logiciels plus robustes.
• Comment éviter les problèmes en premier lieu avec un codage approprié.
• Comment tirer parti des efforts des autres en utilisant des normes industrielles communément acceptées telles que MISRA pour atteindre cet objectif.

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.

Nous appelons fréquemment les développeurs de logiciels par le titre d'ingénieurs logiciels, mais ce n'est pas nécessairement le terme approprié pour la façon dont ils travaillent aujourd'hui. Évoluer vers une bonne pratique de génie logiciel entraîne une baisse des coûts et une augmentation de la qualité. Un élément clé de cela consiste à adopter des normes, en particulier des normes de codage.

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 tirée d'une conférence en 1972, intitulée "L'humble programmeur», écrit par Edsger W Dijkstra. C'est encore très d'actualité aujourd'hui.

Il est important de comprendre l'impact de la qualité sur les coûts de développement de logiciels. Câpres Jones, chercheur, suit cela depuis des décennies et réalise chaque année une enquête sur les coûts des logiciels. Les chiffres ne changent pas beaucoup d'année en année. Les données montrent que le coût typique des logiciels, des exigences au codage en passant par la maintenance, augmente à chaque phase. Cependant, la manière dont les équipes abordent la qualité détermine si leur processus est sain ou «pathologique».

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é de votre logiciel en le testant à la fin du cycle de vie, juste avant sa sortie. Dans le monde de la fabrication, ils comprennent que c'est impossible, mais pour une raison quelconque, nous pensons que nous pouvons tester la qualité et la sécurité "dans" les 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 mot qui a peu de sens. Les normes sont considérées comme un ensemble de règles que le chef d'équipe insiste pour que je suive plutôt que de comprendre que la norme de codage est l'incarnation de la connaissance, de la pratique et de l'expérience. Un ingénieur électricien sait que les normes sont le moyen de construire un produit sûr du premier coup. Un développeur de logiciels pense que les standards sont une contrainte qui les ralentit… un «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 cela, considérez le un article fait par le Software Engineering Institute (SEI) où ils ont constaté, sans surprise, que la sécurité et la fiabilité vont de pair et que la sécurité des logiciels 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 la Motor Industry Software Reliability Association, il décrit un sous-ensemble du langage C ou C++ et des directives pour leur utilisation afin d'améliorer la sûreté et la sécurité de l'application. Bien qu'à l'origine destiné aux applications automobiles, il est utilisé dans toutes les industries, en particulier 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 en cas 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. Les lignes directrices sont divisées en importance par groupes de «règles» et de «recommandations» et sont très complètes et larges et comprennent des métadonnées sur les risques.
• OWASP Top 10. L'Open Web Application Security Project (OWASP), comme son nom l'indique, est une organisation qui s'engage à améliorer la sécurité des applications Web. En tant que tel, leur projet OWASP Top 10 fournit une liste des vulnérabilités de sécurité des applications Web les plus courantes et à fort impact. La dernière version de l'OWASP Top 10 est directement corrélée à des identifiants CWE spécifiques et inclut des métadonnées de risque.
• 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.

Considérons MISRA c, dont j'ai parlé n'est pas seulement pour les applications automobiles. Cependant, c'est une norme qui est utilisée depuis 1998 et qui est bien définie. Il est mis à jour tous les deux ans, ils le parcourent. Au fur et à mesure que les langages C et C++ évoluent, ils font évoluer les normes qui les entourent. Il s'agit d'une norme très flexible qui prend en compte différents niveaux de gravité et il existe une stratégie documentée pour gérer et documenter les écarts.

En tant que technologie capable de détecter les violations des directives standard de codage, telles que l'analyse statique, les versions récentes de MISRA prennent en compte les directives qui sont décidables (détectables avec une grande précision par des outils) et celles qui ne le sont pas. Cela nous amène au sujet de l'adoption et de l'application et à l'importance des outils d'analyse statique dans les normes de 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 un exemple où, lors du test, une erreur de dépassement de mémoire tampon assez complexe est détectée, peut-être avec un outil de sécurité d'application dynamique (DAST). C'est un coup de chance puisque votre test vient d'exécuter le chemin de code qui contient l'erreur. Une fois détecté et débogué, il doit être retesté, et ainsi de suite. L'analyse statique utilisant l'analyse de flux peut également avoir trouvé cette erreur, 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 que vous exécutez. Donc, c'est aussi bon que votre couverture de code de test. Considérez si une norme de codage avait interdit le code qui a permis cette erreur en premier lieu.

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 l'approche consistant à construire un pont puis à le tester en conduisant des camions de plus en plus gros dessus jusqu'à ce qu'il s'effondre, en mesurant le poids du dernier camion réussi et en le reconstruisant pour supporter ce nouveau poids. Cette approche serait pourtant stupide, ce n'est pas très différent de la façon dont nous abordons le développement de logiciels.

Une fois qu'une équipe logicielle adopte une norme de codage et que l'analyse statique est correctement appliquée, elle peut détecter les erreurs rapidement et les prévenir. En d'autres termes, au lieu de trouver un défaut tôt, ce qui est bien, l'équipe change la façon dont ils écrivent le code, ce qui est mieux!

Considérons le Heartbleed vulnérabilité. Il existe maintenant des détecteurs pour cette instance spécifique de vulnérabilité, mais il existe un moyen d'écrire du code afin que Heartbleed ne se soit jamais produit. La prévention est une méthode meilleure et plus sûre.

Résumé

Dykstra a déclaré: "Ceux qui veulent des logiciels vraiment fiables découvriront qu'ils doivent trouver des moyens d'éviter la majorité des bogues pour commencer." Avoir une méthodologie de prévention solide est inférieur au coût de la correction de ces bogues.

Les normes de codage incarnent de solides principes d'ingénierie pour la programmation dans leurs langues respectives et constituent la base de toute approche préventive. Le coût d'un bon logiciel est inférieur au coût d'un mauvais logiciel. Si vous n'utilisez pas l'analyse statique aujourd'hui, ou si vous ne l'utilisez que pour une détection précoce, jetez un œil aux outils d'analyse statique de Parasoft pour C et C ++, Javaet C # et VB.NET avec une riche bibliothèque de vérificateurs pour toutes les normes de sécurité et de sûreté populaires intégrées.