Conformité logicielle DO-178C pour l'aérospatiale et la défense

L'analyse de code statique est l'analyse de code sans exécution de code réelle. Analyse statique expose les vulnérabilités de sécurité et de sûreté du code en appliquant un ensemble complet de techniques d'analyse de code, notamment :

• Analyse basée sur des modèles
• Analyse des flux de données
• Analyse du flux de contrôle
• Interprétation abstraite
• Métriques de code et plus

Ces méthodes identifient les dépassements de mémoire tampon, la division par zéro, l'utilisation de bibliothèques non sécurisées, les règles de codage de l'organisation, les violations de directives, etc.

Dans la norme D0-178C, les objectifs de l'analyse statique relèvent de la section 6 relative aux processus de vérification des logiciels. Les objectifs de l'analyse statique visent à garantir que le code logiciel est exempt de certains types de défauts et qu'il respecte les bonnes pratiques de codage.

Par exemple, la section 6.3.4 Examen et analyse du code source fournit un aperçu des activités de vérification du logiciel nécessaires pour examiner le code en termes de conformité, de vérifiabilité et de traçabilité. Cependant, cette section précise également la nécessité d'inspecter le code pour vérifier sa conformité aux normes, son exactitude et sa cohérence, qui sont toutes de bonnes applications pour l'analyse statique.

Bien que la norme D0-178C ne comporte pas d'exigence spécifique en matière d'analyse statique, les lignes directrices et les objectifs liés à l'analyse statique sont répartis dans plusieurs sections du chapitre 6. Il est essentiel d'interpréter et d'appliquer ces lignes directrices de manière appropriée dans le contexte du projet afin de garantir la conformité avec la norme D0-178C pour la certification des logiciels embarqués.

Exigences de la norme DO-178C

Certaines exigences typiques pour l’analyse statique dans D0-178C peuvent inclure les suivantes.

La plupart de ces activités de vérification sont prises en charge par l'automatisation de l'analyse statique à l'aide d'outils avancés modernes tels que Parasoft C/C++test. De plus, Parasoft fournit des mesures de code sur la maintenabilité, la clarté, la testabilité, la portabilité, la robustesse, la réutilisabilité, la complexité et la prise en charge des révisions de code par les pairs. L'analyse dynamique, les tests unitaires et d'autres détections d'erreurs d'exécution sont également fournis.

Détection précoce des défauts

La détection précoce des défauts à l'aide d'outils d'analyse statique peut améliorer considérablement la conformité à la norme D0-178C en abordant les problèmes de codage et les vulnérabilités potentiels dans le processus de développement logiciel. L'analyse statique analyse le code source sans l'exécuter, en identifiant les défauts et les problèmes potentiels en fonction de règles prédéfinies.

Les outils d'analyse statique permettent de détecter les erreurs de codage et les bugs dans le code source dès le début du processus de développement. En identifiant et en corrigeant ces erreurs dès le début, l'équipe de développement peut empêcher que ces défauts ne se propagent aux étapes ultérieures du développement, où ils pourraient être plus difficiles et plus coûteux à corriger.

Les logiciels critiques pour la sécurité utilisés dans les systèmes embarqués doivent être protégés contre les vulnérabilités potentielles en matière de sécurité. Les outils d'analyse statique peuvent identifier les faiblesses potentielles de sécurité dans le code, telles que les dépassements de mémoire tampon, les problèmes de validation des entrées et d'autres défauts liés à la sécurité. Le traitement de ces vulnérabilités dès le début du processus de développement améliore la sécurité du logiciel.

La norme D0-178C exige des activités de vérification complètes tout au long du cycle de vie du développement logiciel (chapitre 6). L'analyse statique, étant une forme de vérification statique, permet une vérification précoce du code source. En trouvant et en traitant les défauts dès le début, le logiciel peut progresser dans les étapes de vérification ultérieures avec plus de confiance, économisant ainsi du temps et des efforts à long terme.

En adoptant l'analyse statique dès le début du processus de développement logiciel, en conjonction avec d'autres méthodes de vérification et de validation, les équipes peuvent traiter de manière proactive les défauts et les vulnérabilités de sécurité. Cela conduit à un processus de certification plus rationalisé et à une plus grande probabilité de produire des logiciels fiables et sûrs pour une utilisation dans les systèmes aéroportés.

Certains des types courants de défauts que l'analyse statique du test Parasoft C++ peut détecter incluent :

Ce ne sont là que quelques exemples des types de défauts que l'analyse statique de Parasoft C++test peut détecter. De plus, les outils d'analyse statique comme Parasoft C++test peuvent être personnalisés pour inclure ou exclure certains types de contrôles en fonction des exigences spécifiques du projet et des normes de codage.

Normes de codification

En ce qui concerne les normes de codage, la norme D0-178C ne prescrit pas un ensemble spécifique de normes de codage à suivre. Elle fournit plutôt des lignes directrices et des objectifs pour l'établissement et le respect de normes de codage adaptées au développement de logiciels embarqués essentiels à la sécurité.

Les sections pertinentes de la norme D0-178C qui concernent les normes de codage se trouvent principalement dans le chapitre 6 Processus de vérification du logiciel et le chapitre 11 Données du cycle de vie du logiciel. Voici ce que la norme D0-178C exige généralement concernant les normes de codage.

La norme D0-178C reconnaît que différents projets peuvent avoir des normes de codage différentes (par exemple, MISRA C/C++, CERT C/C++, CWE, OWASP, DISA ASD STIG, etc.) en fonction de facteurs tels que la complexité du logiciel, la criticité du système et l'environnement de développement.

Par conséquent, les normes et règles de codage spécifiques sont déterminées par l'équipe de développement tout en satisfaisant aux directives décrites ci-dessus.

Une partie essentielle des preuves de certification requises pour la conformité à la norme D0-178C est la documentation recueillie au cours de ces examens et du processus de vérification. Il est important que la norme de codage prenne en charge les processus d'inspection et de documentation requis.

MISRA C: 2023

MISRA c est un ensemble de directives de codage pour le langage de programmation C, versions C89/C90, C99, C11 et C18. L'objectif de la norme est d'accroître la sécurité des logiciels en empêchant de manière préventive les programmeurs de commettre des erreurs de codage pouvant conduire à des échecs d'exécution (et à d'éventuels problèmes de sécurité) en évitant les constructions problématiques connues dans le langage C.

MISRA C peut contribuer à satisfaire aux exigences de la norme D0-178C, qui est la norme logicielle utilisée pour la certification des systèmes embarqués. Voici comment MISRA C peut répondre à ces exigences.

1. Coche toutes les cases des exigences de la norme de codage énumérées dans la section précédente.
2. Fournit une norme de codage bien définie et largement reconnue qui peut être adoptée par l'équipe de développement pour créer un code cohérent et fiable.
3. Implique des révisions régulières du code pour garantir la conformité à la norme.

L'adoption de la norme MISRA C permet de minimiser le risque d'erreurs et d'ambiguïtés de codage, ce qui améliore la sécurité et la fiabilité du logiciel. L'accent mis par la norme de codage sur la robustesse et l'exactitude du code s'aligne bien avec les objectifs de la norme D0-178C visant à garantir le développement de logiciels à haute intégrité pour les systèmes aéroportés.

Il est important de noter que la norme MISRA C ne garantit pas en elle-même la conformité à la certification. C'est l'un des outils et processus qui contribuent aux activités globales de développement et de vérification des logiciels requises pour la certification D0-178C. De plus, chaque projet peut avoir des exigences et des contraintes spécifiques, de sorte que la norme MISRA C peut devoir être adaptée ou complétée par des règles et des pratiques de codage spécifiques au projet.

Au fil des ans, de nombreux développeurs de systèmes embarqués se sont plaints – et se plaignent encore – que la norme MISRA C était trop stricte et que le coût de l'écriture d'un code entièrement conforme était difficile à justifier. De manière réaliste, étant donné que la norme MISRA C est appliquée aux logiciels critiques pour la sécurité, la valeur de l'application de la norme à un projet dépend de facteurs tels que :

• Risque de dysfonctionnement du système en raison d'une défaillance logicielle
• Coût d'une défaillance du système pour l'entreprise
• Outils de développement et plateforme cible
• Niveau d'expertise du développeur

Les programmeurs doivent trouver un terrain d’entente pratique qui satisfasse l’esprit de la norme tout en revendiquant la conformité MISRA sans gaspiller d’efforts sur des activités sans valeur ajoutée.

Preuve de conformité MISRA

L'un des principaux problèmes rencontrés par les développeurs de logiciels critiques pour la sécurité est de savoir comment démontrer et prouver la conformité à la fin du projet. On a tendance à ajouter dans les rapports plus d'informations que nécessaire. Cela peut devenir un problème controversé entraînant une perte de temps et d'efforts si les critères d'évaluation sont basés sur les opinions subjectives des différentes parties prenantes.

Une approche recommandée pour améliorer l'évaluation de la conformité consiste à utiliser les modèles existants pour le rapport final de conformité et le rapport de qualification des outils. Si les informations ne sont pas requises par la norme, évitez de les ajouter. La combinaison d'informations supplémentaires est non seulement une perte de temps, mais présente également un risque de retarder un processus d'audit. La solution ultime consiste à générer automatiquement la documentation, comme le fait Parasoft.

Le document MISRA Compliance: 2020 aide également les organisations à utiliser un langage commun articulant les exigences de conformité en définissant les artefacts suivants :

• Résumé de la conformité aux directives
• Plan d'application des lignes directrices
• Rapport d'écarts
• Plan de recatégorisation des lignes directrices

Les captures d'écran suivantes de Parasoft montrent des rapports générés automatiquement avec des liens vers d'autres enregistrements et/ou une extension des informations sur la page.

SEI/CERT

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. Lancée en 2006 lors d'une réunion du Comité de normalisation C, la première Norme CERT C a été publié en 2008 et est en constante évolution.

Il existe une version livre publiée en 2016, mais elle n'inclut pas les dernières mises à jour. Cette norme n'a pas de versions spécifiques gelées comme CWE Top 25 et OWASP Top 10. La norme est née d'une grande communauté de plus de 3,000 XNUMX personnes axées sur l'ingénierie et la prévention. Les normes de codage sécurisé du CERT se concentrent donc sur la prévention des causes profondes des vulnérabilités de sécurité plutôt que sur le traitement ou la gestion des symptômes en recherchant les vulnérabilités.

Les directives de codage du CERT sont disponibles pour C, C++, Java, Perl et Android. Elles se répartissent en deux catégories principales.

Les règles sont des lignes directrices détectables par les outils d’analyse statique et nécessitent une application stricte, tandis que les recommandations sont des lignes directrices qui ont un impact moindre et sont parfois difficiles à analyser automatiquement.

Le CERT comprend un système d'évaluation des risques qui combine la probabilité d'occurrence, la gravité et la difficulté relative de l'atténuation. Cela aide les développeurs à hiérarchiser les violations des directives qu'il est le plus important d'examiner. L'inclusion de l'effort d'atténuation dans la priorité des directives est un ajout important aux normes de codage sécurisé du CERT, qui manque à de nombreuses autres normes.

Le facteur coût permet de créer le diagramme en forme de cible du CERT dans lequel la cible centrale représente les directives les plus graves, plus difficiles à corriger. L'avantage de cette priorisation est de se concentrer sur les violations les plus critiques qui offrent le meilleur rapport qualité-prix en termes d'amélioration de la sécurité tout en aidant l'équipe de développement à filtrer les avertissements moins importants.

Conformité SEI CERT C/C++

Selon la documentation SEI CERT C, la conformité « exige que le code ne contienne aucune violation des règles spécifiées dans cette norme. Si une condition exceptionnelle est invoquée, l'exception doit correspondre à une condition exceptionnelle prédéfinie et l'application de cette exception doit être documentée dans le code source. »

Bien que la conformité soit moins spécifique que les normes telles que MISRA, les principes restent similaires. Les règles doivent être respectées et les écarts ne doivent se produire que rarement et être bien documentés. Les recommandations doivent être utilisées lorsque cela est possible et celles qui ne sont pas nécessaires doivent être documentées.

Les violations qui persistent dans le code source doivent être documentées. Cependant, aucun écart n'est acceptable en termes de performances ou de facilité d'utilisation et il incombe au développeur de démontrer que l'écart n'entraînera pas de vulnérabilité.

Parasoft C/C++test fournit un tableau de bord et des rapports complets de conformité CERT. Des rapports de conformité individuels sont disponibles à la demande en fonction de la dernière version du logiciel ou de toute version précédente.

Ces rapports peuvent être triés et consultés pour enquêter plus en détail sur les violations. Un plan de test de conformité est disponible pour corréler la directive CERT avec le vérificateur d'analyse statique Parasoft correspondant, qui est un outil important si une documentation de conformité est nécessaire à des fins d'audit. De plus, tous les rapports intéressants, tels que spécifiés par l'équipe, sont regroupés dans un seul PDF disponible en téléchargement pour les auditeurs.

Prise en charge de CERT C/C++ dans le test Parasoft C/C++

Parasoft fournit un support complet pour les normes de codage sécurisé CERT C et CERT C++ avec une couverture complète de toutes les directives CERT C/C++, y compris les règles et recommandations détectables par analyse statique. Les noms des vérificateurs, les tableaux de bord et les rapports utilisent la convention de dénomination CERT pour faciliter la conformité et l'audit. Un tableau de bord de conformité CERT, qui inclut le score de risque CERT, aide les développeurs à se concentrer sur les violations les plus critiques.

CWE

CWE (Common Weakness Enumeration) est une liste de faiblesses logicielles découvertes basée sur l'analyse des vulnérabilités signalées (CVE). La collecte des CVE et des CWE est une initiative financée par le gouvernement américain, développée par la communauté des logiciels et gérée par l'organisation MITRE. Dans son intégralité, la liste CWE contient plus de 900 problèmes de qualité et de sécurité différents en matière de logiciels et de matériel.

Ces 900+ éléments sont organisés en listes plus exploitables telles que le célèbre Top 25 du CWE. Le Top 25 répertorie les faiblesses de sécurité les plus courantes et les plus dangereuses, qui sont toutes des exploits qui ont une forte probabilité de se produire et dont l'impact de l'exploitation de la faiblesse est important. Les faiblesses logicielles documentées par un CWE sont les logiciels impliqués dans un ensemble de vulnérabilités découvertes (documentées sous le nom de CVE) lors de l'analyse effectuée pour découvrir la cause première. Les CVE sont des vulnérabilités spécifiques observées dans des produits logiciels qui ont une définition exacte de la manière de les exploiter.

La version actuelle du Top 25 CWE date de 2023 et est présentée dans le tableau ci-dessous. Une mise à jour du Top 25 est actuellement en cours, avec des liens améliorés vers les CVE et la NVD. Le classement prend en compte les informations du monde réel afin de représenter véritablement les 25 principaux problèmes de sécurité des applications actuels. Dès sa sortie, Parasoft proposera un support mis à jour pour la dernière version.

Pour les équipes de développement qui maîtrisent bien le Top 25, il existe un autre groupe de vulnérabilités les plus courantes et les plus impactantes, appelé CWE CUSP. Une autre façon de les considérer est le Top 25 des mentions honorables.

Le CWE utilise une méthode de notation des risques pour classer les 25 premiers et le CUSP. Ce score prend en compte l'impact technique d'une faiblesse logicielle (la dangerosité d'une exploitation de la faiblesse dans le monde réel) tel que mesuré par le CWSS (Common Weakness Scoring System).

Voici quelques exemples d’impacts techniques dus aux vulnérabilités :

• Déni de service (DoS)
• Déni de service distribué (DDoS)
• Accès en lecture ou en écriture aux informations protégées
• Accès non autorisé et plus

Les détails de ces méthodes ne sont pas très importants, mais la liste triée est utile pour comprendre les vulnérabilités qui doivent être les plus préoccupantes. Par exemple, il est possible que votre application soit purement interne et que les problèmes de déni de service ne soient pas critiques pour vous. Être capable de hiérarchiser les faiblesses les plus importantes pour votre propre application peut vous aider à surmonter la surcharge de travail liée aux violations d'analyse statique.

Top 25 de la CWE et sur le point d'atteindre la conformité

L'introduction du processus de conformité aux normes de codage dans le flux de travail de développement de l'équipe n'est pas une tâche facile. Il est donc important de sélectionner un outil qui aidera à atteindre la conformité sans imposer trop de frais généraux et sans nécessiter de procédures manuelles supplémentaires. Les points suivants sont des facteurs de décision importants lors de la sélection de la solution pour l'analyse statique.

Le CWE Top 25 et son homologue moins connu, On the Cusp, ne sont pas des normes de codage à proprement parler, mais une liste de faiblesses à éviter pour améliorer la sécurité. Pour être conforme au CWE, un projet doit être en mesure de prouver qu'il a fait des efforts raisonnables pour détecter et éviter ces faiblesses courantes.

Les outils d'analyse statique avancés de Parasoft pour C, C++, Java et .NET sont officiellement compatibles avec CWE, offrant une détection automatisée des 25 principales faiblesses et des faiblesses à venir, ainsi que de bien d'autres. Les tableaux de bord centrés sur CWE offrent aux utilisateurs un accès rapide aux violations des normes et à l'état actuel du projet. Une configuration CWE Top 25 intégrée est disponible pour C, C++, .NET et Java avec une couverture complète des 25 faiblesses courantes.

Les outils Parasoft incluent des informations provenant du Common Weakness Risk Analysis Framework (CWRAF), telles que l'impact technique, afin que vous puissiez bénéficier du même type de priorisation en fonction du risque, de l'impact technique et des faiblesses trouvées dans votre propre code.

Parasoft prend également en charge les rapports de conformité détaillés pour rationaliser les processus d'audit. Les tableaux de bord Web fournissent le lien vers les rapports de conformité pour une image complète de la situation d'un projet. De plus, le plan de détection des faiblesses CWE met en correspondance l'entrée CWE avec les vérificateurs utilisés pour détecter la faiblesse. Cela permet d'illustrer à un auditeur comment la conformité a été obtenue, et les rapports d'audit peuvent être téléchargés au format PDF pour faciliter la création de rapports.