10 règles de codage de la NASA pour la rédaction d'un programme de sécurité critique

Les projets logiciels volumineux et complexes utilisent diverses normes et directives de codage. Ces directives établissent les règles de base qui doivent être suivies lors de l'écriture d'un logiciel. Habituellement, ils déterminent :

a) Comment le code doit-il être structuré ?
b) Quelle fonctionnalité de langue doit ou ne doit pas être utilisée ?

Pour être efficace, l'ensemble de règles doit être petit et suffisamment précis pour être facilement compris et mémorisé.

Les meilleurs programmeurs mondiaux travaillant à la NASA suivent un ensemble de directives pour développer un code critique pour la sécurité. En fait, de nombreuses agences, dont le Jet Propulsion Laboratory (JPL) de la NASA, se concentrent sur le code écrit en langage de programmation C. En effet, il existe une prise en charge étendue d'outils pour ce langage, tels que des extracteurs de modèles logiques, des débogueurs, un compilateur stable, des analyseurs de code source puissants et des outils de métrique.

Dans les cas critiques, il devient nécessaire d'appliquer ces règles, en particulier lorsque la vie humaine peut dépendre de son exactitude et de son efficacité. Par exemple, les logiciels utilisés pour contrôler les avions, les engins spatiaux ou les centrales nucléaires.

Mais savez-vous quelles normes les agences spatiales utilisent pour faire fonctionner leurs machines ? Ci-dessous, nous avons répertorié les 10 règles de codage de la NASA établies par le scientifique principal du JPL, Gerard J. Holzmann. Ils se concentrent tous principalement sur les paramètres de sécurité, et vous pouvez également les appliquer à d'autres langages de programmation.

Règle n° 1 – Flux de contrôle simple

Ecrivez des programmes avec des constructions de flux de contrôle très simples - N'utilisez pas setjmp ou longjmp constructions, aller à déclarations, et récursivité directe ou indirecte .

Raison : Un flux de contrôle simple permet d'améliorer la clarté du code et de renforcer les capacités de vérification. Sans récursivité, il n'y aura pas de graphe d'appel de fonction cyclique. Ainsi, toutes les exécutions censées être bornées le restent en réalité.

Règle n°2 - Limite supérieure fixe pour les boucles

Toutes les boucles doivent avoir une limite supérieure fixe. Il devrait être possible pour un outil de vérification de prouver de manière statique qu'une limite supérieure prédéfinie sur le nombre d'itérations d'une boucle ne peut pas être dépassée.

La règle est considérée comme violée si la boucle liée ne peut pas être prouvée statiquement.

Raison :  La présence de limites de boucle et l'absence de récursivité empêchent le code d'emballement. Cependant, la règle ne s'applique pas aux itérations qui sont censées ne pas se terminer (par exemple, le planificateur de processus). Dans de tels cas, la règle inverse est appliquée - Il doit être statiquement prouvable que l'itération ne peut pas se terminer.

Règle n° 3 – Pas d'allocation dynamique de mémoire

Ne pas utiliser l'allocation dynamique de mémoire après l'initialisation.

Raison : Allocateurs de mémoire comme malloc , et les ramasse-miettes ont souvent un comportement imprévisible qui peut exceptionnellement avoir un impact sur les performances. De plus, des erreurs de mémoire peuvent également survenir à cause d'une erreur de programmeur, ce qui inclut

• Tentative d'allouer plus de mémoire que physiquement disponible
• Oublié de libérer de la mémoire
• Continuer à utiliser la mémoire après sa libération
• Dépassement des limites de la mémoire allouée

Forcer tous les modules à vivre dans une zone de stockage fixe et pré-allouée peut éliminer ces problèmes et faciliter la vérification de l'utilisation de la mémoire.

Une façon de réclamer dynamiquement de la mémoire en l'absence d'allocation de mémoire à partir du tas consiste à utiliser la mémoire de la pile.

Règle n°4 – Pas de grandes fonctions

Aucune fonction ne doit être plus longue que ce qui pourrait être imprimé sur une seule feuille de papier dans un format de référence standard avec une ligne par déclaration et une ligne par déclaration. Cela signifie qu'une fonction ne doit pas contenir plus de 60 lignes de code.

Raison : Des fonctions excessivement longues sont souvent le signe d'une mauvaise structure. Chaque fonction doit être une unité logique à la fois compréhensible et vérifiable. Il est beaucoup plus difficile de comprendre une unité logique qui s'étend sur plusieurs écrans sur un écran d'ordinateur.

Règle n° 5 – Faible densité d'assertion

La densité d'assertions du programme doit être en moyenne d'au moins deux assertions par fonction. Les assertions sont utilisées pour vérifier les conditions anormales qui ne devraient jamais se produire dans les exécutions réelles. Ils doivent être définis comme des tests booléens. Lorsqu'une assertion échoue, une action de récupération explicite doit être entreprise.

Si un outil de vérification statique prouve que l'assertion ne peut jamais échouer ou ne jamais tenir, la règle est considérée comme violée.

Raison : Selon les statistiques d'effort de codage de l'industrie, les tests unitaires capturent au moins un défaut pour 10 à 100 lignes de code. Les chances d'intercepter les défauts augmentent avec la densité des assertions.

L'utilisation de l'assertion est également importante car elles font partie d'une stratégie de codage défensive forte. Ils sont utilisés pour vérifier les pré et post conditions d'une fonction, un paramètre et la valeur de retour d'une fonction et des invariants de boucle. Les assertions peuvent être désactivées de manière sélective après avoir testé le code critique pour les performances.

Règle n° 6 – Déclarer les objets de données au plus petit niveau de portée

Celui-ci prend en charge le principe de base du masquage des données. Tous les objets de données doivent être déclarés au plus petit niveau de portée possible.

Raison : Si un objet n'est pas dans la portée, sa valeur ne peut pas être référencée ou corrompue. Cette règle décourage la réutilisation de variables à des fins multiples et incompatibles qui peuvent compliquer le diagnostic des pannes.

Lire : 20 plus grands programmeurs informatiques de tous les temps

Règle n° 7 – Vérifier les paramètres et la valeur de retour

La ou les valeurs de retour des fonctions non vides doivent être vérifiées par chaque fonction appelante, et la validité des paramètres doit être vérifiée à l'intérieur de chaque fonction.

Dans sa forme la plus stricte, cette règle signifie même la valeur de retour de printf déclarations et fichier fermer les déclarations doivent être vérifiées.

Raison : Si la réponse à une erreur n'est pas à juste titre différente de la réponse au succès, il faut vérifier explicitement une valeur de retour. C'est généralement le cas des appels à close et printf . Il est acceptable de convertir explicitement la valeur de retour de la fonction en void –  indiquant que le codeur décide explicitement (pas accidentellement) d'ignorer une valeur de retour.

Règle n° 8 – Utilisation limitée du préprocesseur

L'utilisation du préprocesseur doit être limitée à l'inclusion de fichiers d'en-tête et de définitions de macros. Les appels de macro récursifs, le collage de jetons et les listes d'arguments variables ne sont pas autorisés.

Il devrait y avoir une justification pour plus d'une ou deux directives de compilation conditionnelle, même dans les efforts de développement d'applications importants, au-delà du passe-partout standard, ce qui évite l'inclusion multiple du même fichier d'en-tête. Chacune de ces utilisations doit être signalée par un vérificateur basé sur des outils et justifiée dans le code.

Raison : Le préprocesseur C est un outil puissant et ambigu qui peut détruire la clarté du code et dérouter de nombreux vérificateurs textuels. L'effet des constructions dans le code de préprocesseur illimité pourrait être exceptionnellement difficile à déchiffrer, même avec une définition de langage formel en main.

La mise en garde contre la compilation conditionnelle est tout aussi importante :avec seulement 10 directives de compilation conditionnelle, il pourrait y avoir 1024 versions possibles (2^10) du code, ce qui augmenterait l'effort de test requis.

Lire :9 nouveaux langages de programmation à apprendre cette année

Règle n° 9 – Utilisation limitée des pointeurs

L'utilisation de pointeurs doit être restreinte. Un seul niveau de déréférencement est autorisé. Les opérations de déréférencement du pointeur ne doivent pas être masquées dans typedef déclaration ou définitions de macro.

Les pointeurs de fonction ne sont pas non plus autorisés.

Raison : Les pointeurs sont facilement mal utilisés, même par des experts. Ils rendent difficile le suivi ou l'analyse du flux de données dans un programme, en particulier par les analyseurs statiques basés sur des outils.

Les pointeurs de fonction restreignent également le type de contrôles effectués par les analyseurs statiques. Ainsi, ils ne devraient être utilisés que s'il existe une justification solide pour leur mise en œuvre. Si des pointeurs de fonction sont utilisés, il devient presque impossible pour un outil de prouver l'absence de récursivité, des méthodes alternatives doivent donc être fournies pour compenser cette perte de capacités analytiques.

Lire : 14 meilleur logiciel de programmation pour écrire du code

Règle n°10 - Compiler tout le code

Tout le code doit être compilé dès le premier jour de développement. L'avertissement du compilateur doit être activé au paramètre le plus pointu du compilateur. Le code doit compiler avec ces paramètres sans aucun avertissement.

Tout le code doit être vérifié quotidiennement avec au moins un (de préférence plus d'un) analyseur de code source statique à la pointe de la technologie et doit réussir le processus d'analyse sans aucun avertissement.

Raison :Il existe de nombreux analyseurs de code source efficaces disponibles sur le marché ; quelques-uns d'entre eux sont des outils gratuits. Il n'y a absolument aucune excuse pour qu'un codeur ne fasse pas usage de cette technologie facilement disponible. Si le compilateur ou l'analyseur statique est confus, le code provoquant la confusion/l'erreur doit être réécrit afin qu'il devienne plus trivialement valide.

Lisez :30 inventions étonnantes de la NASA que nous utilisons dans notre vie quotidienne

Que dit la NASA à propos de ces règles ?