Qu'est-ce qu'une nomenclature logicielle (SBOM) ?

SBOM dans la chaîne d'approvisionnement logicielle : leçons tirées de la porte dérobée XZ Utils

Le cas de porte dérobée XZ Utils, identifié comme CVE-2024-3094, impliquait une porte dérobée malveillante insérée dans un utilitaire Linux largement utilisé. Cette vulnérabilité a été découverte par Andres Freund juste avant son intégration dans les principales distributions Linux, mettant en danger des millions de serveurs. Le chercheur a découvert cette vulnérabilité avant la mise en production, évitant ainsi tout dommage réel. Bien que les SBOM n'aient pas joué de rôle dans ce cas spécifique, ils seraient cruciaux si la vulnérabilité s'était répandue, comme cela a été le cas avec Log4j en 2021. Dans une vulnérabilité répandue comme Log4j, les plates-formes SBOM pourraient efficacement aider à comprendre le rayon d'explosion. et mener une analyse d’impact. Si la vulnérabilité XZ Utils avait été déployée, des outils comme Scribe Hub auraient pu jouer un rôle déterminant en alertant les entreprises, leur permettant de rechercher dans leur inventaire logiciel, de bloquer le déploiement de versions compromises et d'améliorer leur posture de sécurité globale.

Définition de la nomenclature logicielle

La nomenclature logicielle (SBOM) répertorie tous les composants et dépendances logicielles impliqués dans le développement et la livraison d'une application. Les SBOM sont similaires aux nomenclatures (BOM) utilisées dans les chaînes d'approvisionnement et la fabrication. Il n'existe pas de fonctionnalité commune à tous les fournisseurs du secteur informatique pour décrire avec précision les composants de code fondamentaux sur lesquels une application est construite.

Le SBOM typique comprend des informations sur les licences, les numéros de version, les détails des composants et les fournisseurs. Une liste formelle de tous les faits réduit les risques tant pour le fabricant que pour l'utilisateur en permettant aux autres de comprendre le contenu de leur logiciel et d'agir en conséquence. Les SBOM ne sont pas nouveaux dans l'industrie du logiciel, mais ils deviennent de plus en plus essentiels à mesure que le développement devient plus sophistiqué et plus coûteux. Ils sont récemment devenus une exigence de base dans un certain nombre d'entreprises.

Sécuriser les applications cloud natives : la puissance des SBOM améliorés

La montée en puissance des applications cloud natives a introduit une complexité accrue dans la sécurisation des environnements logiciels modernes. Ces applications, caractérisées par leur nature dynamique et distribuée, constituées de microservices interconnectés et de composants externes, augmentent la surface d'attaque. L'amélioration des SBOM devient essentielle dans ce contexte, car ils offrent une visibilité détaillée sur tous les composants et dépendances au sein d'une architecture cloud native. Un SBOM efficace aide à identifier les vulnérabilités, garantit le respect des normes de sécurité et facilite une réponse rapide aux incidents. En tirant parti de SBOM robustes, les organisations peuvent maintenir un inventaire complet de leurs actifs logiciels, suivre les modifications et détecter rapidement les risques de sécurité potentiels. À l’ère des applications cloud natives, l’amélioration des pratiques SBOM est indispensable pour renforcer la sécurité et maintenir l’intégrité des écosystèmes logiciels complexes.

Avantages du SBOM

Traite des menaces à l’intégrité

Les attaques peuvent survenir à n'importe quel stade de la chaîne d'approvisionnement logicielle normale, et ces attaques deviennent de plus en plus visibles, perturbatrices et coûteuses dans le monde d'aujourd'hui. L'intégrité peut être maintenue à l'aide d'un SBOM en vérifiant que les composants et les fichiers qui y apparaissent sont les mêmes que ceux prévus. Par exemple, l'un des composants du format CycloneDX est une valeur de hachage qui peut être utilisée pour la correspondance exacte des fichiers et des composants. Comme un SBOM n'est pas un document statique, il doit être mis à jour à chaque fois qu'un changement survient dans le logiciel décrit ou ses composants.

Permet la visibilité des composants du produit

Les entreprises doivent créer la confiance des clients pour les fidéliser et promouvoir les achats répétés. Plutôt que des assurances ou des promesses, les SBOM partagés offrent une meilleure visibilité sur la qualité des technologies qu'ils utilisent.

Permet une analyse plus facile des vulnérabilités

Les entreprises peuvent utiliser les SBOM pour identifier et éliminer les vulnérabilités avant qu'elles n'atteignent la production. Les nouvelles vulnérabilités des logiciels de production peuvent être corrigées rapidement. En fin de compte, les SBOM aident les ingénieurs à découvrir et à résoudre plus rapidement les failles de sécurité.

Tire parti de la gouvernance des licences pour votre produit

L’adoption de la nomenclature logicielle peut contribuer à améliorer la gouvernance des licences logicielles. Chaque logiciel est accompagné d'une licence qui précise comment il peut être utilisé et distribué légalement. Les éléments constitutifs d’une chaîne d’approvisionnement qui constituent une application complète peuvent avoir diverses licences différentes. Toute entreprise qui utilise le programme est légalement tenue de respecter les licences. Il n'y a peut-être aucun moyen de déterminer ce dont les licences ont besoin ou comment s'y conformer sans une nomenclature logicielle.

Principes d'un SBOM bien formé

Les composants minimaux d'un SBOM bien formé sont divisés en trois catégories :

Champs de données

Le but de ces champs est de fournir une identification adéquate de ces composants. Cela vous permet de les surveiller tout au long de la chaîne d'approvisionnement des logiciels et de les relier à d'autres sources de données utiles, telles que des bases de données de vulnérabilités ou de licences. Quelques exemples de champs de données sont le nom du fournisseur, le nom du composant, la version du composant, d'autres identifiants uniques, la relation de dépendance, l'auteur des données SBOM et l'horodatage.

Prise en charge de l'automatisation

Les organisations qui souhaitent garder un œil attentif sur les données des composants SBOM devront les fournir dans un style cohérent et facile à comprendre. Ceci est abordé dans la section Exigences de base du SBOM sous « Prise en charge de l'automatisation ». Lors de l’envoi de SBOM au-delà des frontières organisationnelles, vous avez le choix entre trois normes :

1. Échange de données sur les progiciels (SPDX)
2. CycloneDX
3. Balises d'identification de logiciel (SWID)

Ceux-ci sont abordés plus en détail un peu plus loin dans cet article.

Pratiques et processus

Enfin, la section « Pratiques et processus » présente six normes indiquant comment et quand les SBOM doivent être mis à jour et fournis. Ils sont les suivants :

• Si le composant logiciel est mis à niveau avec une nouvelle version ou version, de nouveaux SBOM doivent être produits.
• Les auteurs de SBOM doivent inclure les composants de niveau supérieur ainsi que leurs dépendances transitives.
• Si le SBOM ne propose pas un arbre de dépendances complet, l'auteur du SBOM doit expliquer si cela est dû au fait que (a) le composant n'a plus de dépendances, ou (b) l'existence de dépendances est inconnue et incomplète.
• Les SBOM doivent être distribués et livrés « en temps opportun », avec « des droits d’accès et des rôles appropriés en place ».
• Les entreprises qui souhaitent garder secrets certains composants d'un SBOM doivent spécifier des paramètres de contrôle d'accès, qui contiendraient des règles et des procédures spécifiques pour incorporer les informations relatives au SBOM dans le manuel et les outils de l'utilisateur. Pour le dire simplement : s’il y a quelque chose qui doit être gardé secret pour le bien de l’organisation, alors le processus pour garder ce secret est défini dans cette section. 
• Étant donné que les normes contrôlant la génération du SBOM sont nouvelles, il est conseillé aux utilisateurs du SBOM de pardonner les fautes ou omissions (involontaires).

Différents formats SBOM

Bien entendu, vous pouvez générer manuellement une facture SBOM en répertoriant les nombreux composants du logiciel que vous avez produit. Cependant, gérer d’énormes bases de code avec des dizaines, voire des centaines de dépendances et de composants tiers est une tâche fastidieuse et chronophage, en particulier pour les développeurs qui gèrent de grandes bases de code avec plusieurs composants et dépendances tiers. Certains développeurs peuvent avoir inclus des composants tiers dans une application sans la documenter. Par conséquent, les développeurs actuels peuvent ne pas connaître l’intégralité de la base de code.

Pour faire de l’adoption une réalité, les SBOM doivent adhérer aux normes acceptées par l’industrie qui permettent l’interopérabilité entre divers secteurs et organisations. Les organisations disposent déjà de l'architecture nécessaire pour développer, gérer et distribuer les données des composants logiciels, grâce à quelques normes.

SPDX : échange de données de progiciels

Votre Échange de données sur les progiciels (SPDX) est le principal standard ouvert pour les formats de nomenclature logicielle développé par la Linux Foundation en 2010. Les composants logiciels, les droits d'auteur, les licences et les références de sécurité sont tous inclus dans les fichiers SPDX. La spécification SPDX est compatible avec la proposition de la NTIA Normes minimales du SBOM et cas d'utilisation. Les organisations peuvent utiliser SPDX Lite pour échanger des données puisqu'il s'agit d'une version condensée de la norme SPDX. Le SPDX a obtenu une norme officielle ISO/IEC 5962 en août 2021.

document SPDX

SWID : marquage d'identification du logiciel

Votre Organisation internationale de normalisation (ISO) a commencé à établir une norme pour le marquage des composants logiciels avec des identifiants lisibles par machine avant la fin de la décennie. Les balises SWID, comme on les appelle maintenant, sont des métadonnées structurées intégrées dans un logiciel qui transmettent des informations telles que le nom du produit logiciel, sa version, les développeurs, les relations, etc. Les balises SWID peuvent aider à automatiser la gestion des correctifs, la validation de l'intégrité des logiciels, la détection des vulnérabilités et à autoriser ou interdire les installations de logiciels, de la même manière que la gestion des actifs logiciels. En 2012, la norme ISO/IEC 19770-2 a été confirmée et modifiée en 2015. Il existe quatre principaux types de balises SWID qui sont utilisées à différentes étapes du cycle de vie du développement logiciel :

1. Balises du corpus : Ceux-ci sont utilisés pour identifier et caractériser les composants logiciels qui ne sont pas prêts à être installés. Les balises Corpus sont « conçues pour être utilisées comme entrées dans les outils et procédures d’installation de logiciels », selon le National Institute of Standards and Technology.
2. Balises principales : Le but principal d'une balise est d'identifier et de contextualiser les éléments logiciels une fois qu'ils ont été installés.
3. Balises de correctif : Les balises de correctif identifient et décrivent le correctif (par opposition au produit principal lui-même). Les balises de correctif peuvent également, et c'est souvent le cas, incorporer des informations contextuelles sur la relation du correctif avec d'autres produits ou correctifs.
4. Balises supplémentaires : Des balises supplémentaires permettent aux utilisateurs de logiciels et aux outils de gestion de logiciels d'ajouter des informations contextuelles utiles sur les utilitaires locaux, telles que les clés de licence et les informations de contact des parties concernées.

Lorsqu’il s’agit de déterminer les balises et les données précises à proposer avec leurs produits, les entreprises disposent d’une marge de manœuvre considérable. En plus des données obligatoires, la norme SWID précise un certain nombre de composants et caractéristiques optionnels. Enfin, seules quelques caractéristiques qui caractérisent le produit logiciel (telles que le nom et l'ID de la balise) et l'entité qui l'a généré sont requises pour une balise de base valide et conforme.

CycloneDX

En 2017, la Fondation OWASP a publié CycloneDX dans le cadre de Dependency-Track, un outil d'analyse de composants logiciels open source. CycloneDX est une norme légère destinée à une utilisation multisectorielle, avec des cas d'utilisation tels que la détection des vulnérabilités, la conformité des licences et l'évaluation des anciens composants. CycloneDX 1.4 a été lancé en janvier 2022. Cyclone DX peut gérer quatre types de données différents :

• Métadonnées du diagramme de flux de matériaux : Il contient des informations sur l'application/le produit lui-même, telles que le fournisseur, le fabricant et les composants décrits dans le SBOM, ainsi que tous les outils utilisés pour créer un SBOM.
• Composants: Il s'agit d'une liste complète des composants propriétaires et open source, ainsi que des informations sur les licences.
• Les services Les URI des points de terminaison, les exigences d'authentification et les traversées des limites de confiance sont tous des exemples d'API externes que les logiciels peuvent utiliser.
• Dépendances inclure à la fois les connexions directes et indirectes.

Source: CycloneDX

À quoi ressemble un SBOM ?

Pour l’identification des risques, un inventaire complet et précis de tous les composants propriétaires et tiers est requis. Tous les composants directs et transitifs, ainsi que les dépendances entre eux, doivent être inclus dans les nomenclatures. Par exemple, les types de composants suivants peuvent être décrits à l'aide de CycloneDX :

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "version": 1, "components": [ { " type": "bibliothèque", "nom": "bibliothèque nacl", "version": "1.0.0" } ] }

Format XML :

 bibliothèque nacl 1.0

Pourquoi signer votre SBOM ?

Qu'est-ce qu'une signature numérique ?

A signature numérique est exactement ce à quoi cela ressemble : une version électronique de la signature traditionnelle sur papier et au stylo. Il vérifie la validité et l'intégrité des communications et des documents numériques à l'aide d'une approche mathématique sophistiquée. Il garantit que le contenu d'un message n'est pas altéré pendant son transit, nous aidant ainsi à surmonter le problème de l'usurpation d'identité et de la falsification dans les communications numériques. Les signatures numériques ont gagné en popularité au fil du temps et constituent une norme cryptographique. 

Comment fonctionnent les signatures numériques

Les signatures numériques sont créées à l'aide de la cryptographie à clé publique, également appelée cryptographie asymétrique. Une approche à clé publique telle que RSA (Rivest-Shamir-Adleman) génère deux clés, une privée et une publique, menant à une paire de clés mathématiquement liées. L’un des principaux mécanismes derrière les signatures numériques est le hachage. Il transforme efficacement les données en une sortie de taille fixe, quelle que soit la taille de l'entrée. Cela se fait via des fonctions de hachage qui sont essentiellement des algorithmes, et le résultat qu'elles produisent est appelé valeur de hachage. Les fonctions de hachage cryptographique génèrent une valeur de hachage qui agit comme une empreinte numérique, la rendant unique pour chacun. Tout comme l'empreinte digitale de chacun est différente, différents messages d'entrée généreront différentes valeurs de hachage. Les deux clés cryptographiques à authentification mutuelle de la cryptographie à clé publique (PKC) sont principalement utilisées pour les signatures numériques. Le créateur de la signature numérique utilise une clé privée pour crypter les données liées à la signature, et ces données ne peuvent être décodées qu'à l'aide de la clé publique du signataire. C'est ainsi qu'un destinataire sait que l'expéditeur n'est pas compromis et que les données reçues sont correctes. Actuellement, gérer l'infrastructure à clé publique est coûteux et compliqué car les gens perdre leurs clés privées comme si on perdait ses clés physiques. Les autorités de certification (AC) agissent en tant que tiers de confiance et émettent des signatures numériques en acceptant, vérifiant, délivrant et conservant les certificats numériques. Les autorités de certification aident à empêcher la création de faux certificats numériques. Il valide également le fournisseur de services de confiance (TSP). Un TSP est une personne physique ou morale qui valide les signatures numériques pour le compte d'une entreprise et communique les résultats de la validation.

Avantages d'un SBOM signé numériquement

Un SBOM signé fournit une somme de contrôle, qui est une longue chaîne de lettres et de chiffres qui représentent la somme des chiffres précis d'une donnée numérique et qui peuvent être comparés pour trouver des défauts ou des modifications. Une somme de contrôle est similaire à une empreinte digitale numérique. Il vérifie régulièrement la redondance (CRC). Les modifications apportées aux données brutes dans les réseaux numériques et les périphériques de stockage sont détectées à l'aide d'un code de détection d'erreurs et d'une fonction de vérification. Étant donné qu’une signature numérique est censée servir de moyen validé et sécurisé de prouver l’authenticité des transactions – c’est-à-dire qu’une fois signée, une personne ne peut prétendre autrement – ​​elle oblige tous les signataires à respecter les procédures et actions énoncées dans le projet de loi. 

Problèmes avec un SBOM non signé

L’un des objectifs principaux des signatures numériques étant la vérification, un SBOM non signé n’est pas vérifiable. Considérez-le comme un contrat : si un contrat n’a pas été signé par les parties participantes, il n’existe aucun moyen réel de le faire respecter. De même, un SBOM non signé n'est qu'un document non signé : votre client ne peut pas vous tenir responsable.  Cela peut également entraîner d'autres problèmes à l'avenir, car un SBOM non signé peut également présenter des risques pour la sécurité de votre organisation. Tout ce qui aurait autrement pu être protégé par un SBOM signé n'est plus protégé et les données et informations peuvent donc être envoyées ou répliquées n'importe où. L'un des principaux objectifs des SBOM signés – la responsabilité – est perdu lorsqu'un SBOM n'est pas signé, car des modifications peuvent alors y être apportées sans conséquences de la part du créateur ou du client. 

Utiliser SBOM pour améliorer la cybersécurité

Les SBOM sont l'un des meilleurs moyens pour les organisations de maintenir la sécurité et l'authenticité de leurs données et procédures. Ils ont également créé un précédent dans l'industrie en augmentant l'ouverture entre les développeurs, les fournisseurs de logiciels et les clients. Les organisations peuvent informer en toute sécurité leurs partenaires des détails opérationnels tout au long du processus de passation de contrats si des normes sont en place. Les organisations réussiront mieux à identifier les failles, les vulnérabilités et les menaces du jour zéro à mesure que les SBOM se généraliseront. L’adoption de la nomenclature logicielle constitue un gain évident pour la sécurité de la chaîne d’approvisionnement logicielle dans le monde entier.

Utiliser VEX pour améliorer la convivialité de votre SBOM

Vulnerability Exploitability eXchange (VEX) est un avis de sécurité visant à exposer l'exploitabilité des vulnérabilités dans le contexte du produit dans lequel elles se trouvent. Lors de l’exécution d’une analyse de vulnérabilité sur la plupart des applications modernes, les résultats peuvent facilement se chiffrer en centaines, voire en milliers de vulnérabilités. Sur le nombre total de vulnérabilités découvertes, seulement 5 % environ sont réellement exploitables. Il est également important de se rappeler que l’exploitabilité n’est presque jamais un problème isolé. Le plus souvent, c'est un cas d'utilisation complexe de bibliothèques open source, de modules et du code qui les utilise travaillant ensemble qui transforme une vulnérabilité en un problème réellement exploitable. Jusqu'à ce que vous modifiiez votre application et exécutiez un nouveau SBOM pour la décrire, l'inventaire décrit dans une nomenclature restera généralement statique. Les informations sur les vulnérabilités sont beaucoup plus dynamiques et susceptibles d’évoluer. Le fait de disposer de vos informations VEX sous forme de liste autonome permet de mettre à jour les données VEX sans avoir à générer et à gérer des nomenclatures supplémentaires. CISA fournit une liste des éléments de données minimum recommandés qui devraient être inclus dans un avis ou un document VEX utile. Ceux-ci sont:

Métadonnées VEX: Identifiant du format VEX, Chaîne d'identifiant du document VEX, Auteur, Rôle Auteur, Horodatage. 

Détails du produit : Identificateur(s) de produit ou identifiant de famille de produits (par exemple, identifiant unique ou une combinaison du nom du fournisseur, du nom du produit et de la chaîne de version, comme indiqué dans les directives SBOM établies3). 

Détails de la vulnérabilité: Identifiant de la vulnérabilité (CVE ou autres identifiants) et description de la vulnérabilité (par exemple description CVE). 

Etat du produit Plus de détails (c'est-à-dire des informations sur l'état d'une vulnérabilité dans ce produit) : 

• NON AFFECTÉ – Aucune correction n’est requise concernant cette vulnérabilité.
• CONCERNÉ – Des actions sont recommandées pour corriger ou résoudre cette vulnérabilité.
• CORRIGÉ – Ces versions du produit contiennent un correctif pour la vulnérabilité. 
• SOUS ENQUÊTE – On ne sait pas encore si ces versions de produits sont affectées par la vulnérabilité. Une mise à jour sera fournie dans une version ultérieure.

Surmonter les défis de l’adoption du SBOM

L'intégration du SBOM dans le cycle de vie du développement logiciel (SDLC) d'une organisation présente plusieurs défis. Premièrement, générer et maintenir des SBOM précis peut prendre du temps et être coûteux, nécessitant des investissements importants dans les outils et les processus. Les défis SBOM incluent également l'intégration de la gestion SBOM avec les pipelines CI/CD existants, ce qui peut impliquer de rationaliser l'intégration des pipelines CI/CD. De plus, garantir l’exhaustivité et l’exactitude des SBOM nécessite un suivi méticuleux de tous les composants logiciels, y compris les dépendances tierces. Un autre obstacle important consiste à favoriser une culture de transparence et de sensibilisation à la sécurité au sein des équipes de développement, ce qui est crucial pour l'adoption réussie des pratiques SBOM. Relever ces défis SBOM nécessite une approche stratégique, combinant des outils robustes, une formation efficace et un engagement organisationnel fort pour améliorer la sécurité de la chaîne d'approvisionnement logicielle.

Résumé

En conclusion, même si les SBOM constituent encore une idée nouvelle pour la plupart des organisations, la capacité à produire des SBOM devrait devenir plus importante à l’avenir. Si vous n'avez pas encore commencé à intégrer la création de SBOM dans votre processus de livraison de logiciels, c'est le moment idéal pour le faire.