Dossier de sécurité logiciel MIL-STD-882 pour systèmes militaires

Un système qui opère sans dossier de sécurité logiciel fonctionne sur la confiance — confiance que l'analyse de danger était complète, que les contrôles de conception sont corrects, et que les preuves de vérification sont suffisantes. Pour un produit commercial, cette confiance est défendable. Pour un système militaire dont les modes de défaillance incluent des libérations d'énergie, la perte de la plateforme ou le tir ami, elle ne l'est pas. MIL-STD-882E, la norme du Department of Defense pour la sécurité des systèmes, fournit le processus structuré par lequel cette confiance est remplacée par des preuves documentées, examinées et acceptées. Le dossier de sécurité logiciel est l'artefact qui capture ces preuves et formule l'argument selon lequel le risque résiduel est acceptable.

Cet article est un guide pratique pour construire un dossier de sécurité logiciel selon MIL-STD-882E. Il couvre la structure des tâches de la norme et ses dispositions spécifiques au logiciel, la chaîne d'analyse de danger de l'identification préliminaire à l'analyse de danger logiciel (SwHA), la dérivation des exigences de sécurité logiciel (SSR) à partir des causes de danger, les contrôles de conception qui implémentent ces exigences, les preuves de vérification qui démontrent leur implémentation correcte, et le processus d'acceptation du risque qui clôt le dossier. Les ingénieurs nouveaux dans les programmes de sécurité de défense y trouveront une carte du terrain ; les praticiens expérimentés y trouveront une référence des livrables spécifiques et de la traçabilité attendus par les examinateurs gouvernementaux.

Vue d'ensemble de MIL-STD-882E : sécurité des systèmes du concept à l'élimination

MIL-STD-882E définit la sécurité des systèmes comme une approche planifiée et disciplinée d'identification et de gestion des dangers tout au long du cycle de vie d'un système — de l'exploration du concept à l'élimination. La norme organise ses exigences en tâches regroupées en cinq catégories : pilotage et contrôle du programme, exigences de conception, soutenabilité, formation et évaluations. L'activité contractante sélectionne les tâches appropriées au profil de risque du programme et les spécifie dans l'énoncé des travaux. Le contractant réalise ces tâches et livre les résultats comme éléments de la liste des exigences de données contractuelles.

Pour les systèmes militaires à forte composante logicielle, cinq tâches dominent l'effort d'ingénierie :

• Tâche 205 — analyse des exigences de sécurité logiciel : identification de toutes les fonctions logicielles critiques pour la sécurité et dérivation des exigences de sécurité logiciel pour contrôler les causes de danger identifiées.
• Tâche 206 — analyse de conception de la sécurité logicielle : analyse de la conception logicielle pour vérifier que les exigences de sécurité sont correctement allouées et qu'aucune nouvelle cause de danger n'est introduite par les décisions de conception.
• Tâche 301 — évaluation de sécurité : une évaluation pilotée par les jalons de l'acceptabilité du risque résiduel, documentée dans un rapport d'évaluation de sécurité (SAR).
• Tâche 302 — sécurité des tests et évaluations : veiller à ce que les contrôles de sécurité soient en place avant toute activité de test impliquant une énergie dangereuse ou des modes opérationnels.
• Tâche 303 — revues du programme de sécurité des systèmes : revues formelles au cours desquelles le System Safety Working Group (SSWG) présente l'état des dangers, les points de risque ouverts et les preuves d'efficacité des contrôles au bureau de programme.

La matrice de risque au centre de MIL-STD-882E croise la gravité et la probabilité. La gravité va de Catastrophique (catégorie I : décès, perte du système, dommages environnementaux graves) en passant par Critique (catégorie II : blessure grave, dommages majeurs au système) et Marginale (catégorie III : blessure légère, dommages mineurs au système) jusqu'à Négligeable (catégorie IV : blessure ou dommage moindre). La probabilité va de Fréquente (susceptible de se produire souvent sur la durée de vie du système) en passant par Probable, Occasionnelle, Éloignée et Improbable. Chaque cellule de la matrice 4×5 résultante porte un indice de risque de danger (HRI) qui détermine qui doit accepter le risque résiduel après application des contrôles.

Le HRI n'est pas un produit mathématique — c'est un classement ordinal défini par la matrice de risque du programme, que le SSPP établit. Un danger Catastrophique/Fréquent (HRI 1) exige une acceptation par la Milestone Decision Authority ; un danger Négligeable/Improbable (HRI 20) est acceptable au niveau du groupe de travail. La conséquence pratique pour les ingénieurs logiciels est que les produits d'analyse qu'ils produisent — fiches de danger, lignes SwHA, SSR, dossiers de vérification — alimentent directement un processus de gestion des risques avec des niveaux d'autorité définis. Les lacunes dans l'analyse laissent le risque à un niveau indéterminé qu'aucune autorité ne peut accepter.

Analyse préliminaire des dangers : identifier les fonctions logicielles critiques pour la sécurité

L'analyse préliminaire des dangers (PHA) est réalisée tôt dans le développement du système, typiquement avant que les exigences détaillées ne soient finalisées, en utilisant la décomposition fonctionnelle du système et la documentation du concept opérationnel. Son but est d'identifier les dangers au niveau système, d'attribuer des évaluations initiales de gravité et de probabilité, et d'identifier quelles fonctions du système — matérielles, logicielles, humaines ou procédurales — contribuent à chaque danger. La PHA n'exige pas de connaissance détaillée de la conception ; elle opère au niveau de « que peut faire ce système qui pourrait nuire aux personnes, aux équipements ou à l'environnement ? »

Les entrées de la PHA incluent typiquement :

• Concept d'opérations du système (CONOPS) et scénarios opérationnels
• Exigences fonctionnelles du système et architecture de niveau supérieur
• Sources d'énergie et inventaire des matières dangereuses
• Définitions d'interfaces (avec les systèmes adjacents, les opérateurs, l'environnement)
• Données historiques de dangers issues de systèmes similaires

Les sorties de la PHA incluent un journal des dangers rempli avec des identifiants de danger uniques, des descriptions de danger en langage naturel, des évaluations HRI initiales et une liste de fonctions contributives. Pour un système de conduite de tir, la PHA pourrait identifier « libération d'armes non intentionnelle » comme un danger Catastrophique (catégorie I) et lister comme fonctions contributives : le logiciel d'autorisation d'engagement, le canal de commande de libération d'armes, la logique de verrouillage d'armement et l'interface opérateur. Cette liste de fonctions contributives est le point d'entrée de toutes les analyses de sécurité logicielle ultérieures.

La distinction entre un danger et un mode de défaillance importe ici. Un danger est une condition avec un potentiel de nuisance — « libération d'armes non intentionnelle » est un danger. Un mode de défaillance est un mécanisme par lequel un composant peut mal fonctionner — « activation parasite de la sortie FIRE_COMMAND » est un mode de défaillance. La PHA identifie les dangers ; les analyses ultérieures identifient les modes de défaillance qui y contribuent. Confondre les deux dans le journal des dangers est l'erreur structurelle la plus courante dans l'analyse de sécurité en début de programme, et elle se propage dans des tables SwHA difficiles à tracer.

La contribution du logiciel aux dangers système est qualitativement différente de celle du matériel. Un composant matériel a un taux de défaillance physique qui peut être estimé à partir de données de terrain ou d'essais accélérés. Les défauts logiciels sont déterministes : pour des entrées spécifiques, une fonction défectueuse produit toujours la mauvaise sortie. Le logiciel ne s'use pas, et il n'a pas de temps moyen entre défaillances significatif au même sens qu'un relais ou une vanne. La probabilité attribuée à une contribution logicielle à un danger est donc un jugement sur la vraisemblance que le logiciel contienne un défaut pertinent pour ce danger, pondéré par la vraisemblance que les conditions d'entrée spécifiques qui le déclencheraient se produisent en opération. Ce jugement est éclairé par la complexité logicielle, la rigueur du processus de développement et la profondeur des tests — non par des données empiriques de défaillance.

Analyse de danger logiciel : relier le logiciel aux dangers

L'analyse de danger logiciel (SwHA) est la tâche qui relie le journal des dangers du système aux comportements logiciels spécifiques. Pour chaque danger de la PHA qui liste une fonction logicielle comme contributive, la SwHA pose la question : que doit faire le logiciel incorrectement (ou ne pas faire) pour que ce danger se produise ? La réponse énumère les modes de défaillance logiciels, qui deviennent les chaînes causales que les SSR doivent traiter.

Les modes de défaillance logiciels relèvent de cinq catégories canoniques :

• Sortie incorrecte : la fonction s'exécute et produit une sortie, mais la valeur de sortie est fausse — une commande hors de la plage valide, un drapeau d'état positionné alors qu'il devrait être effacé, ou un résultat de calcul avec une erreur arithmétique.
• Absence de sortie (omission) : la fonction ne produit pas une sortie dont le système dépend — un chien de garde qui cesse de se réinitialiser, un moniteur de santé qui ne signale pas un défaut, un verrouillage de sécurité qui n'active pas le signal d'inhibition.
• Sortie tardive : la fonction produit la sortie correcte, mais pas dans la fenêtre temporelle requise — une violation de contrainte temps réel qui fait que le système procède avec une entrée ancienne ou absente.
• Sortie parasite : la fonction produit une sortie qui n'était pas demandée ou qui survient à un moment où elle n'est pas valide — une commande non sollicitée qui déclenche un actionneur pendant un mode où cette commande est dangereuse.
• Sortie vers la mauvaise destination : la fonction route une sortie valide vers une interface incorrecte — une commande destinée à un sous-système est délivrée à un autre en raison d'une erreur de routage ou d'adressage.

La structure de la fiche SwHA suit un modèle standard. Chaque ligne correspond à un triplet (danger, fonction logicielle, mode de défaillance). Les colonnes enregistrent l'identifiant de danger, la description du danger, le nom de la fonction logicielle, la catégorie de mode de défaillance, l'effet du mode de défaillance sur le danger système, la gravité du dommage résultant, la probabilité (comme évaluation qualitative), le HRI et l'identifiant de SSR dérivé qui traite cette ligne. Une table SwHA pour un système de commande de vol peut comporter plusieurs centaines de lignes ; pour un terminal de commandement et de contrôle plus simple, peut-être de trente à soixante.

La traçabilité est la métrique opérationnelle de la qualité de la SwHA. Chaque danger de la PHA avec une contribution logicielle doit apparaître dans la SwHA. Chaque fonction logicielle listée dans la PHA doit avoir au moins une ligne SwHA. Chaque ligne SwHA doit renvoyer à au moins une SSR. Et chaque SSR doit remonter à au moins une ligne SwHA. Les lacunes de traçabilité découvertes lors des revues de sécurité gouvernementales sont la cause la plus courante de retravail de la SwHA dans le cycle de revue.

La SwHA identifie aussi les exigences logicielles qui servent des fonctions de sécurité non parce qu'elles empêchent directement un danger, mais parce qu'elles permettent à un moniteur de sécurité de détecter un précurseur de danger. Ces exigences de surveillance sont aussi importantes que les exigences de contrôle direct — un moniteur qui échoue silencieusement prive le système de sa capacité à passer à l'état sûr avant qu'un danger ne survienne. Elles exigent la même formulation en SSR et la même rigueur de vérification que les exigences d'inhibition directes. Voir aussi : formal verification for defense software pour les techniques qui peuvent démontrer mathématiquement l'absence de modes de défaillance spécifiques dans les modules critiques pour la sécurité.

Identification des fonctions critiques pour la sécurité et exigences de sécurité logiciel

Une fonction logicielle critique pour la sécurité est toute fonction dont le mode de défaillance apparaît dans la SwHA comme contributif d'un danger Catastrophique ou Critique. L'identification des fonctions critiques pour la sécurité est la condition préalable à l'allocation d'une rigueur de conception supplémentaire : objectifs de couverture de code plus élevés, revue par les pairs obligatoire, vérification indépendante et analyse formelle.

L'indice de criticité logicielle (SCI) formalise cela. À chaque fonction critique pour la sécurité est attribuée une catégorie de criticité fondée sur la conséquence au pire de sa défaillance : catégorie I (Catastrophique), catégorie II (Critique), catégorie III (Marginale), catégorie IV (Négligeable). Le SCI pilote la sélection des exigences de sécurité logicielle et la profondeur de vérification appliquée à chaque fonction. Une fonction de catégorie I — par exemple, le contrôle d'autorisation final avant une commande de libération d'armes — justifie le traitement le plus rigoureux que le programme puisse appliquer. Une fonction de catégorie IV — un rédacteur de journal de diagnostic — ne justifie aucune rigueur supplémentaire.

Les exigences de sécurité logiciel (SSR) sont dérivées directement des lignes SwHA. Pour chaque mode de défaillance identifié, la SSR spécifie le comportement logiciel qui prévient, détecte ou atténue ce mode de défaillance. Les formes canoniques de SSR sont :

• Contrainte positive : « le logiciel doit activer la sortie SAFE_STATE dans les 50 ms suivant la détection de la perte de battement valide du capteur principal. » (Traite : le mode de défaillance sortie tardive/absente dans la fonction de surveillance des capteurs.)
• Contrainte négative : « le logiciel ne doit pas activer WEAPONS_RELEASE_COMMAND sauf si ARM_CONFIRMED, TARGET_VALIDATED et OPERATOR_AUTHORIZED ont tous été maintenus en continu pendant au moins 500 ms. » (Traite : le mode de défaillance sortie parasite dans la fonction d'autorisation de libération.)
• Contrainte de plage : « la sortie d'azimut commandée doit rester dans ±180 degrés. Toute valeur calculée hors de cette plage doit faire entrer le logiciel dans l'état FAULT_HOLD sans sortir la commande. » (Traite : le mode de défaillance sortie incorrecte dans la fonction de calcul de conduite de tir.)
• Exigence de surveillance : « le logiciel doit comparer la poussée commandée à la poussée mesurée à chaque cycle de 10 ms et positionner THRUST_FAULT_FLAG si la différence dépasse 15 % pendant trois cycles consécutifs. » (Permet la détection des précurseurs de danger.)

Chaque SSR est étiquetée avec un identifiant unique (par exemple, SSR-FC-007), allouée à un composant logiciel spécifique de l'architecture, et saisie dans la matrice de traçabilité la reliant à ses lignes SwHA parentes. Lors de la conception détaillée, chaque SSR doit en outre être allouée à une exigence spécifique de la spécification des exigences logicielles (SRS) ou du document de conception logicielle (SDD). L'exigence SRS/SDD hérite de l'étiquette SSR, permettant aux outils de traçabilité automatisés de propager la désignation de sécurité à travers la hiérarchie des exigences et jusqu'à la sélection des cas de test.

Les SSR qui ne peuvent pas être vérifiés par test ou analyse sont des indicateurs d'un problème d'architecture. Si le comportement de sécurité ne peut pas être confirmé indépendamment, soit l'architecture logicielle n'expose pas l'état pertinent à l'observation, soit la SSR est formulée en des termes non mesurables. Les deux problèmes exigent une résolution avant que la conception ne progresse vers l'implémentation. Une SSR sans méthode de vérification faisable n'est pas un contrôle de sécurité — c'est une déclaration d'intention.

Contrôles de conception logicielle pour la sécurité

Les contrôles de conception sont les modèles architecturaux et d'implémentation qui rendent fiables les comportements logiciels exigés par les SSR en présence de défauts. Chaque contrôle de conception est sélectionné en fonction du mode de défaillance qu'il traite et de la gravité de la conséquence de ce mode de défaillance. Il n'existe pas de modèle universel — le contrôle approprié dépend de l'architecture du système et de la cause de danger spécifique en cours d'atténuation.

Les modèles les plus largement applicables dans le logiciel militaire sont :

Supervision par chien de garde. Un chien de garde matériel ou logiciel indépendant exige que l'application critique pour la sécurité active un signal de réinitialisation à chaque cycle de traitement. L'absence d'activation de la réinitialisation — que ce soit parce que l'application a planté, est entrée dans une boucle infinie ou est devenue autrement non réactive — fait expirer le chien de garde et force une transition vers l'état sûr. L'état sûr est défini par le matériel : mettre hors énergie les sorties, positionner les inhibitions, fermer les vannes. Le chien de garde n'a pas besoin de comprendre pourquoi l'application a échoué ; il a seulement besoin de savoir que le fonctionnement normal a cessé.

Séquences d'armement positif. Les commandes dangereuses exigent que plusieurs conditions d'activation indépendantes soient simultanément satisfaites avant que la commande puisse être émise. Aucun défaut logiciel unique, aucune défaillance de capteur unique, aucune erreur d'opérateur unique ne peut satisfaire toutes les conditions simultanément. L'exemple classique est une séquence d'armement et de libération d'armes : l'armement exige un circuit d'armement matériel séparé, un état d'autorisation logicielle, une condition de proximité ou de ciblage, et une confirmation d'opérateur, le tout dans une fenêtre temporelle. Retirer l'un de ces éléments supprime la capacité à faire feu.

Machines à états à défaillance passive. La logique de contrôle critique pour la sécurité est implémentée comme une machine à états finis explicite avec un état sûr par défaut défini. Toute entrée qui provoquerait une transition d'état invalide est mappée vers l'état sûr plutôt qu'un comportement indéfini. La machine à états est conçue de sorte que la perte d'alimentation, la perte de communications ou la perte de validité des capteurs convergent toutes vers l'état sûr — il n'existe aucun chemin d'une condition de défaut vers une commande dangereuse. Considérez un exemple simplifié pour un contrôleur de verrouillage :

Surveillance de plausibilité. Un processus de surveillance indépendant compare les commandes de sortie aux contraintes physiques. Une accélération commandée qui dépasse la capacité maximale documentée du véhicule est implausible et peut indiquer une erreur de calcul ou une entrée corrompue. Le moniteur intercepte et bloque la commande implausible, journalise l'événement et alerte le système de gestion de santé. La logique de surveillance doit être indépendante de la logique de calcul — si les deux utilisent le même algorithme, un défaut systématique affecte les deux de manière identique et le moniteur n'apporte aucune protection.

Validation défensive des entrées. Chaque fonction critique pour la sécurité valide ses entrées par rapport aux plages valides définies avant de les traiter. Les entrées hors de la plage valide ne provoquent pas de calcul sur des données invalides — elles font que la fonction signale une condition de défaut et emprunte un chemin de gestion d'erreur défini. La logique de validation doit couvrir non seulement les contrôles de plage mais aussi la validité temporelle (s'agit-il de la valeur la plus récemment échantillonnée ou d'une lecture ancienne ?), la validité de la source (cette valeur vient-elle de l'émetteur attendu ?) et la cohérence (cette valeur est-elle cohérente avec les capteurs corroborants dans la tolérance ?).

Chaque contrôle de conception est documenté dans le document de conception logicielle avec une référence croisée explicite vers la SSR qu'il implémente. Le processus de revue de conception inclut une vérification que chaque SSR a un contrôle de conception identifié, et que chaque contrôle de conception est justifié comme adéquat pour le mode de défaillance qu'il traite. Des contrôles adéquats pour des dangers Marginaux peuvent ne pas l'être pour des dangers Critiques — l'argument d'adéquation doit être spécifique à la gravité de la conséquence.

Preuves de vérification de la sécurité

Les preuves de vérification de la sécurité sont l'ensemble des dossiers qui démontrent que chaque SSR est correctement implémentée dans le logiciel livré. La base de preuves doit être suffisante pour qu'un examinateur qualifié — l'ingénieur sécurité gouvernemental, le comité de revue de sécurité ou l'autorité d'acceptation du risque — puisse conclure que le logiciel se comporte comme le dossier de sécurité l'affirme. Une preuve présente mais non traçable à des SSR, ou traçable à des SSR mais insuffisante pour démontrer leur implémentation, ne clôt pas le dossier de sécurité.

Les principaux types de preuves pour la vérification de sécurité logicielle sont :

Cas de test spécifiques à la sécurité. Pour chaque SSR, un ou plusieurs cas de test sont dérivés qui exercent directement le comportement requis. Les cas de test sont construits à partir des modes de défaillance de la SwHA : si la ligne SwHA identifie « activation parasite de FIRE_COMMAND en mode SAFE » comme cause de danger, le cas de test correspondant applique les conditions d'entrée spécifiques qui seraient requises pour déclencher ce comportement et vérifie que la sortie n'est pas activée. Tester l'absence de comportement dangereux est plus exigeant que tester la présence d'un comportement correct — l'ingénieur test doit raisonner sur tous les chemins d'entrée qui pourraient atteindre la fonction de sécurité et confirmer qu'aucun ne produit une sortie dangereuse.

Couverture de code pour les modules critiques pour la sécurité. Les métriques de couverture donnent la certitude que la suite de tests exerce les chemins de code qui implémentent les SSR. L'objectif de couverture pour les modules critiques pour la sécurité (fonctions de catégorie I et II selon le SCI) est typiquement 100 % de couverture de branches au minimum, avec la couverture condition/décision modifiée (MC/DC) exigée pour les fonctions qui implémentent une logique d'autorisation multi-conditions. Un rapport de couverture de branches qui montre des branches non testées dans un module critique pour la sécurité est un constat ouvert — soit la branche non testée est du code mort qui doit être retiré, soit un cas de test manque. Des données de couverture sans carte de traçabilité SSR correspondante ne constituent pas des preuves de vérification de la sécurité — la preuve est dans la connexion entre le code couvert et les SSR que ce code implémente. Voir aussi : software testing military systems pour un traitement complet de la méthodologie de test pour les programmes de défense.

FMEA logicielle. Une analyse des modes de défaillance et de leurs effets logicielle applique la méthodologie FMEA aux modules logiciels plutôt qu'aux composants matériels. Pour chaque fonction d'un module critique pour la sécurité, la FMEA enregistre : le but de la fonction, les modes de défaillance (en utilisant les cinq catégories canoniques de la SwHA), l'effet de chaque mode de défaillance sur la sortie logicielle, l'effet sur le danger système, le mécanisme de détection (chien de garde, moniteur, test, observation d'opérateur) et le contrôle compensatoire dans la conception. La FMEA logicielle est la plus précieuse comme contrôle croisé de la SwHA — si la FMEA identifie un mode de défaillance aux conséquences dangereuses qui n'apparaît pas dans la SwHA, soit la SwHA a une lacune, soit la FMEA a un faux positif qui doit être arbitré. Les deux résultats améliorent le dossier de sécurité.

Dossiers de revue de code. La revue par les pairs du code critique pour la sécurité utilisant une liste de contrôle spécifique à la sécurité génère des preuves que des ingénieurs qualifiés ont examiné l'implémentation pour sa conformité aux SSR et aux contrôles de conception. Les éléments de la liste de contrôle devraient correspondre directement aux modèles de conception requis — « réinitialisation du chien de garde appelée à chaque cycle », « toutes les entrées validées avant utilisation », « la machine à états n'a aucune transition indéfinie ». Les dossiers de revue identifient les défauts trouvés et leurs suites ; une revue sans aucun constat sur un module critique pour la sécurité complexe est soit l'indication d'une implémentation exceptionnellement propre, soit celle d'un processus de revue insuffisamment rigoureux, et l'ingénieur sécurité du programme devrait pouvoir distinguer les deux.

Intégrer ces types de preuves dans les DevSecOps for defense pipelines exige que les cas de test critiques pour la sécurité, les outils de couverture et les fiches FMEA soient sous contrôle de configuration aux côtés du code source qu'ils vérifient. Un résultat de test sans ligne de base de configuration identifiant exactement quelle version du logiciel a été testée n'est pas une preuve reproductible et ne peut pas être soumis dans un Safety Data Package. Chaque artefact de preuve exige un numéro de document, une révision, une date et un lien vers la ligne de base de l'élément de configuration logicielle qu'il couvre.

Assemblage du dossier de sécurité et acceptation du risque résiduel

Le dossier de sécurité est un argument structuré selon lequel le système logiciel livré est suffisamment sûr pour l'emploi prévu. Il n'affirme pas que le logiciel est exempt de défauts ni que tout risque a été éliminé — de telles affirmations ne sont pas atteignables et ne sont pas ce qu'exige MIL-STD-882E. Il affirme que : tous les dangers raisonnablement prévisibles ont été identifiés ; des contrôles ont été appliqués qui réduisent chaque danger à un niveau de risque acceptable ; les contrôles ont été vérifiés comme correctement implémentés ; et les risques résiduels qui subsistent après application des contrôles ont été examinés et acceptés par l'autorité appropriée.

La structure du document de dossier de sécurité suit une hiérarchie affirmation-argument-preuves. La Goal Structuring Notation (GSN) est couramment utilisée pour visualiser cette hiérarchie, bien que la notation ne soit pas exigée — la structure doit être présente qu'elle soit ou non exprimée en forme GSN. Une structure de niveau supérieur typique pour un dossier de sécurité logiciel de système de conduite de tir :

Le Safety Data Package (SDP) est la collection d'artefacts livrés au bureau de programme comme preuves du dossier de sécurité. Son contenu est spécifié dans le plan de programme de sécurité des systèmes comme une liste de CDRL avec des dates de livraison liées aux jalons du programme. Contenu typique du SDP :

• Plan de programme de sécurité des systèmes (SSPP)
• Rapport d'analyse préliminaire des dangers (PHA)
• Rapports d'analyse de danger des sous-systèmes (SSHA)
• Fiches d'analyse de danger logiciel (SwHA)
• Liste des exigences de sécurité logiciel (SSR) et matrice de traçabilité
• Rapports d'analyse de conception de la sécurité logicielle (tâche 206)
• Fiches FMEA logicielles
• Cas de test et résultats de test du logiciel critique pour la sécurité
• Rapports de couverture de code pour les modules critiques pour la sécurité
• Dossiers de revue de code pour les modules critiques pour la sécurité
• Rapports de décision sur le risque de danger (HRDR) pour les risques résiduels acceptés
• Rapport d'évaluation de sécurité (SAR)

L'acceptation du risque résiduel est l'acte formel par lequel l'autorité d'acceptation du risque reconnaît qu'un danger a été contrôlé à un niveau qui reste au-dessus du seuil acceptable du programme, examine les preuves que les contrôles sont adéquats et correctement implémentés, et accepte la responsabilité du risque restant. Le Hazard Risk Decision Report est l'instrument de cet acte. Le HRDR décrit le danger, les contrôles appliqués, le HRI résiduel après contrôles, les preuves soutenant l'évaluation du HRI résiduel et une recommandation. L'autorité appropriée signe le HRDR, le transformant d'une recommandation en enregistrement formel d'acceptation du risque.

Le dossier de sécurité est un document vivant. À chaque modification du logiciel — changement d'exigences, correction de défauts, évolution des interfaces — le dossier de sécurité doit être revu pour déterminer si la modification affecte un danger, une exigence de sécurité logicielle (SSR), un contrôle de conception ou un élément de preuve. Une modification qui augmente la probabilité ou la gravité d'un risque résiduel accepté exige un nouveau HRDR signé par l'autorité compétente. Une modification qui introduit une nouvelle cause de danger exige une mise à jour de la SwHA et potentiellement une nouvelle SSR. La gestion de configuration des artefacts du dossier de sécurité est donc aussi importante que celle du code source — un dossier de sécurité obsolète qui ne reflète pas la ligne de base logicielle actuelle n'est pas un dossier de sécurité.

Le mode de défaillance le plus courant des programmes de sécurité logicielle n'est pas une analyse insuffisante — c'est un suivi insuffisant. La SwHA est réalisée, les SSR sont rédigées, les contrôles de conception sont mis en œuvre, puis la planification des tests se poursuit sans lien systématique entre les SSR et les cas de test. Les données de couverture sont collectées sans carte des modules critiques pour la sécurité. La FMEA est rédigée après la revue de code plutôt qu'avant. Le résultat est un ensemble d'artefacts individuellement plausibles qui ne composent pas un argument cohérent. La tâche d'assemblage du dossier de sécurité est l'endroit où ces déconnexions deviennent visibles — et les traiter avant les revues de programme plutôt que pendant celles-ci fait la différence entre un programme de sécurité défendable et un cycle de retravail coûteux.