Une nomenclature logicielle (SBOM) est un moyen de résumer les faits clés concernant le logiciel sur un système. Au cœur de celui-ci, il décrit l’ensemble des composants logiciels et les relations de dépendance entre ces composants qui sont reliés entre eux pour constituer un système.

Les logiciels modernes se composent aujourd’hui de composants modulaires qui sont réutilisés dans différentes configurations. Les composants peuvent être constitués de bibliothèques open source, de code source ou d’autres logiciels externes développés par des tiers. Cette réutilisation permet à l’innovation de nouvelles fonctionnalités de prospérer, d’autant plus qu’un grand pourcentage de ces composants connectés ensemble pour former un système peut être open source. Chacun de ces composants peut avoir des limitations, une infrastructure de support et des niveaux de qualité différents. Certains composants peuvent être des versions obsolètes avec des défauts ou des vulnérabilités connus. Lorsqu’un logiciel exécute un système de sécurité critique, tel que le système de survie, le contrôle du trafic, l’extinction des incendies, l’application de produits chimiques, etc., être en mesure d’avoir une transparence totale sur le logiciel qui fait partie d’un système est une première étape essentielle pour pouvoir faire efficacement analyse des allégations de sécurité.

Pourquoi est-ce important?

Lorsqu’un système intègre une fonctionnalité susceptible d’avoir de graves conséquences sur le bien-être d’une personne ou une perte importante, les détails comptent. Le niveau de transparence et de traçabilité peut devoir se situer à différents niveaux de détails en fonction de la gravité des conséquences.

Source : NTIA Enquête sur les formats et normes SBOM existants

Qu’est-ce que cela a à voir avec le développement critique pour la sécurité ?

Les normes de sécurité, et les réclamations nécessairement faites à leur encontre, se présentent sous différentes formes. Les normes de sécurité elles-mêmes varient principalement en fonction de l’industrie qu’elles ciblent : l’automobile utilise ISO 26262, l’aviation utilise DO 178C pour les logiciels et DO 254 pour le matériel, l’industrie utilise IEC 61508 ou ISO 13849, l’agriculture utilise ISO 25119, etc. D’un point de vue logiciel, toutes ces normes fonctionnent à partir du même principe que tous les détails de tous les logiciels sont connus : le logiciel doit être développé selon une perspective de qualité logicielle, avec des mesures supplémentaires ajoutées pour la sécurité. Dans certains cas, ces mesures de sécurité supplémentaires se présentent sous la forme d’un logiciel FMEA (Failure Modes and Effects Analysis), mais dans chacun d’eux, il existe des métriques de couverture de code spécifiques pour démontrer que la plus grande partie possible du code a été testée et que le code est conforme aux exigences.

Un autre élément que toutes les normes de sécurité ont en commun est l’attente que la configuration du système sera gérée dans le cadre de toute version de produit. La gestion de la configuration (CM) est déjà une attente inhérente aux logiciels, mais avec la sécurité, cela devient encore plus crucial en raison de la nécessité de suivre exactement la configuration d’un système (et de son logiciel) s’il y a un incident ultérieur sur le terrain alors que le système est utilisé. D’un point de vue logiciel, cela signifie que nous avons besoin de plusieurs choses :

• Le code source au moment de la publication
• La documentation qui lui est associée
• La configuration utilisée pour construire le logiciel
• Les versions spécifiques des outils utilisés pour construire le logiciel

L’objectif est donc de pouvoir reconstruire exactement ce qu’était l’exécutable ou le binaire au moment de sa sortie.

D’après ce qui précède, il est intrinsèquement évident de savoir comment le SBOM s’inscrit dans le besoin de CM. Les exigences CM des normes de sécurité, du point de vue du code source et de la configuration, sont grandement simplifiées en suivant un processus SBOM efficace. Un SBOM prend en charge la capture des détails de ce qui se trouve dans une version spécifique et prend en charge la détermination de ce qui n’a pas fonctionné en cas de défaillance.

Étant donné que les logiciels reposent souvent sur des composants logiciels réutilisables écrits par quelqu’un d’autre que l’auteur du système/de l’application principale, les normes de sécurité ont également une attente spécifique et un ensemble donné de critères pour les logiciels que vous finissez par inclure dans votre produit final. Cela peut être quelque chose d’aussi simple qu’une bibliothèque de fonctions d’exécution comme on pourrait s’y attendre à partir d’une bibliothèque d’exécution, à quelque chose d’aussi étendu qu’un middleware qui gère la communication entre les composants. Bien que les normes de sécurité n’exigent pas toujours que le logiciel inclus soit développé conformément à une norme de sécurité, on s’attend toujours à ce que vous puissiez prouver que le logiciel a été développé au moins conformément à un cadre de gestion de la qualité de sorte que vous puissiez démontrer que le le logiciel répond à ses exigences. Ceci est toujours basé sur la condition que vous connaissiez tous les détails sur le composant logiciel et qu’il remplisse son objectif.

Les composants logiciels inclus peuvent provenir de :

• Tiers
• Logiciel existant non développé selon une norme de sécurité
• Logiciel développé en interne déjà utilisé

Indépendamment de la source ou de l’utilisation actuelle du logiciel, le SBOM doit décrire tous les logiciels inclus dans la version.

À cette fin, les normes de sécurité prévoient que les éléments suivants soient disponibles pour chaque composant logiciel inclus dans votre projet :

• ID unique, quelque chose pour identifier de manière unique la version du logiciel que vous utilisez. Les variations dans les versions font qu’il est important de pouvoir distinguer la version exacte que vous utilisez. L’ID unique peut être aussi simple que d’utiliser le hachage d’un outil de gestion de configuration, afin que vous sachiez s’il a changé.
• Toutes les exigences de sécurité qui pourraient être violées si le logiciel inclus ne fonctionne pas correctement. Il s’agit spécifiquement de rechercher des défaillances dans le logiciel inclus qui peuvent entraîner un mauvais fonctionnement de la fonction de sécurité. (Ceci est appelé une défaillance en cascade.)
• Exigences pour le composant logiciel
  • Cela devrait inclure les résultats de tout test pour démontrer la couverture des exigences
  • Couverture des conditions de fonctionnement nominales et du comportement en cas de panne
  • Pour les exigences hautement critiques pour la sécurité, la couverture des tests doit être conforme à ce que la spécification attend (par exemple, la couverture du code de niveau Modified Condition/Decision Coverage (MC/DC))
• L’utilisation prévue du composant logiciel
• La configuration de construction du composant (comment il a été construit afin qu’il puisse être dupliqué à l’avenir)
• Toutes les interfaces requises et fournies et les ressources partagées utilisées par le composant logiciel. Un composant peut augmenter la demande de ressources au niveau du système qui pourraient ne pas être prises en compte.
• Manuel d’application (documentation)
• Instructions sur la façon d’intégrer correctement le composant logiciel et de l’invoquer correctement
• Ce que le logiciel pourrait faire dans des conditions de fonctionnement anormales (par exemple, mémoire insuffisante ou CPU disponible faible)
• Toutes les dépendances chaînées qu’un composant peut nécessiter
• Tous les bogues existants et leurs solutions de contournement

Conclusion

Au minimum, le SBOM décrit le composant logiciel, le fournisseur et le numéro de version, avec une énumération des composants dépendants inclus. C’est ce qui est demandé dans la définition minimale viable d’un SBOM pour soutenir la cybersécurité[1] ou logiciel critique pour la sécurité[2].

Disposer d’un niveau minimum d’informations, bien que ce soit mieux que rien, n’est pas suffisant pour le niveau d’analyse auquel s’attendent les allégations de sécurité. Savoir exactement quels fichiers source ont été inclus dans la construction est un meilleur point de départ. Mieux encore, connaître les options de configuration qui ont été utilisées pour créer l’image (et pouvoir la reproduire), et pouvoir vérifier via une forme de contrôle d’intégrité (comme un hachage) que les composants construits n’ont pas changé va être essentiel pour disposer d’une base solide pour le dossier de sûreté. Les SBOM doivent évoluer du minimum au niveau de détail nécessaire pour satisfaire l’analyse de sûreté.

Bien que l’outillage SBOM puisse ne pas être en mesure de remplir toutes ces informations aujourd’hui, les outils continuent d’évoluer afin que les faits nécessaires à l’appui de l’analyse de sécurité puissent être mis à disposition. Une norme internationale ouverte SBOM, comme SPDX[3] peut devenir la base d’une gestion moderne de la configuration et d’une documentation efficace des systèmes critiques pour la sécurité.

Les éléments minimaux pour une nomenclature logicielle (SBOM) de la NTIA

ISO 26262:2018, partie 8, article 12 – Qualification des composants logiciels

ISO/IEC 5962:2021 – Technologies de l’information — Spécification SPDX® V2.2.1

Auteurs

Pierre Brinkresponsable de l’ingénierie de la sécurité fonctionnelle, kVA par UL, Underwriters Laboratories (UL)

Kate Stewartvice-président des systèmes embarqués fiables, The Linux Foundation