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

Les équipes de développement logiciel ont commencé à utiliser des SBOM (Software Bills of Materials ou nomenclatures logicielles) il y a plus de dix ans pour gérer les bibliothèques open source et les dépôts tiers. Les préoccupations en matière de cybersécurité ont placé les SBOM au premier plan après que de grandes attaques sur la chaîne d’approvisionnement ont révélé des failles critiques. La faille SolarWinds de 2020 a vu des attaquants insérer du code malveillant dans des mises à jour logicielles de confiance, affectant 18 000 organisations, dont plusieurs agences gouvernementales. Peu après, la vulnérabilité Log4j de 2021 a été dévoilée, affectant des centaines de millions d’appareils dans le monde et révélant davantage comment des composants compromis peuvent menacer des systèmes entiers.

Ces cyberattaques ont mis en lumière une dure réalité : les organisations, y compris les agences fédérales, manquaient de visibilité sur les composants et les dépendances de leurs systèmes logiciels. Ce manque de visibilité complique l’évaluation des risques cyber et rend la réponse aux menaces peu efficace. L’urgence de la menace a incité la Maison-Blanche à prendre des mesures décisives. Le décret 14028 a imposé des SBOM pour tout achat de logiciels fédéraux en mai 2021.

La National Telecommunications and Information Administration (NTIA) a établi les éléments minimum pour les SBOM que les fournisseurs de logiciels doivent respecter lorsqu’ils vendent à des entités de gouvernement. En septembre 2024, le CISA a publié un document intitulé « Framing Software Component Transparency », qui développe ces exigences minimales et fournit des conseils plus détaillés sur la mise en œuvre et la gestion du SBOM dans l’écosystème logiciel.

Cette directive fédérale sert désormais de modèle pour la transparence des logiciels dans tous les secteurs d’activité. Par exemple, dans le secteur des services financiers, la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS) version 4.0 inclut des exigences en matière de gestion des stocks de logiciels pour protéger les systèmes de paiement et remédier aux vulnérabilités. Dans le domaine de la santé, la FDA exige des SBOM  pour les dispositifs médicaux, tandis que l’International Medical Device Regulators Forum (IMDRF) recommande leur utilisation  pour protéger les dispositifs médicaux et les systèmes de données des patients.

Ces recommandations et lignes directrices reflètent une tendance plus large vers l’adoption des SBOM dans le secteur privé. Gartner prévoit qu’en 2025, 60 % des organisations développant ou achetant des logiciels d’infrastructure critique exigeront des SBOM, contre moins de 20 % en 2022. Cette adoption est poussée par la nécessité : une analyse récente montre que plus de 90 % des applications logicielles modernes contiennent des dépendances open source, et que 74 % d’entre elles incluent des dépendances à haut risque. Les entreprises utilisent de plus en plus les SBOM pour satisfaire aux exigences de conformité, valider les composants tiers et traiter les vulnérabilités de sécurité dès leur découverte.

À l’image des étiquettes alimentaires détaillant les ingrédients et leurs origines, les SBOM fournissent une documentation structurée sur les composants logiciels, leurs fournisseurs et les relations entre les dépendances.

Les exigences du SBOM ont considérablement évolué depuis leur introduction dans le décret présidentiel 14028 (2021). Ce qui était au départ des exigences minimales de la NTIA s’est élargi grâce à l’adoption par les secteurs et à l’affinement de la réglementation. Le cadre actuel des exigences, publié par la CISA en septembre 2024, s’appuie sur ces fondations et fournit des orientations plus précises pour une mise en œuvre plus large.

Les obligations des entreprises en matière de SBOM varient selon leur secteur d’activité et leurs relations avec le gouvernement. Les sous-traitants de l’administration américaine, les fournisseurs d’infrastructures critiques et les entreprises issues de secteurs réglementés doivent se conformer à des exigences SBOM bien spécifiques. Alors que le gouvernement impose l’adoption du SBOM à ses fournisseurs, pour les entreprises du secteur privé hors marché conclu avec l’État, l’adoption n’est pas obligatoire. Néanmoins, mettre en œuvre les pratiques SBOM devient essentiel pour assurer la sécurité des chaînes d’approvisionnement et gagner la confiance des clients.

Le cadre des exigences 2024 de CISA introduit un modèle de maturité à trois niveaux qui aide les entreprises à améliorer progressivement leurs pratiques SBOM :

• Attendu minimum : éléments essentiels requis pour assurer la fonctionnalité de base et la conformité d’un SBOM
  
  
• Pratique recommandée : documentation enrichie pour soutenir des cas d’utilisation élargis en matière de sécurité et de conformité
  
  
• Objectif ambitieux : fonctionnalités de Advanced qui permet une visibilité complète de la chaîne d’approvisionnement

Les attributs suivants représentent les éléments essentiels requis dans un SBOM complet :

• Méta-information SBOM : données de base du document SBOM lui-même, y compris l’auteur des données SBOM, l’horodatage de sa création et le composant principal documenté
  
  
• Nom du fournisseur : l’entité qui crée, définit et fabrique le composant logiciel
  
  
• Nom du composant : nom désigné du composant logiciel, attribué par le fournisseur d’origine
  
  
• Version du composant : capture les changements spécifiques à la version pour suivre avec précision les mises à jour et les modifications
  
  
• Autres identificateurs uniques : inclut des types de référence tels que l’énumération commune de plateforme (CPE), les balises SWID ou les URL de package (PURL) pour un suivi précis des composants
  
  
• Hachage cryptographique : une signature unique pour chaque composant, permettant de vérifier son intégrité et de l’identifier précisément
  
  
• Relation de dépendance : une carte structurée montrant comment les composants sont interconnectés, couvrant à la fois les dépendances directes et transitives
  
  
• Informations sur la licence : documentation sur les termes légaux du composant logiciel fourni
  
  
• Avis de droit d’auteur : entité détenant les droits exclusifs et juridiques sur le composant répertorié

Les dépendances logicielles créent des interconnexions complexes au sein des applications modernes. Un SBOM doit capturer clairement ces relations, en distinguant les dépendances directes (composants explicitement inclus dans le logiciel) et les dépendances transitives (composants attirés par d’autres dépendances).

Lorsqu’elles documentent les dépendances, les entreprises doivent indiquer explicitement l’exhaustivité de leurs connaissances. L’hypothèse par défaut est que les informations sur les dépendances peuvent être incomplètes, sauf indication contraire explicite. Cette transparence aide les utilisateurs en aval à comprendre les points faibles potentiels de la chaîne d’approvisionnement de leur logiciel.

Les entreprises doivent également tenir compte des dépendances dynamiques chargées à l’exécution et des dépendances distantes appelées par des services externes. Même si ces relations ne font pas partie de la conception traditionnelle des logiciels, leur compréhension est essentielle pour une évaluation complète de la sécurité.

Dans les implémentations réelles, une connaissance complète de tous les composants logiciels n’est pas toujours possible. Les entreprises doivent gérer ces lacunes de manière transparente en documentant explicitement les dépendances inconnues et les informations incomplètes. Lorsque certains composants ne peuvent être entièrement documentés en raison d’obligations contractuelles ou d’autres contraintes, le SBOM doit indiquer ces expurgations tout en préservant la structure de dépendance globale.

Plutôt que d’omettre les informations incertaines, les organisations devraient explicitement les marquer comme « inconnues » ou « incomplètes ». Cette approche permet aux utilisateurs en aval de prendre des décisions éclairées en matière de gestion des risques et de déterminer si des enquêtes complémentaires sont nécessaires. Concernant les composants expurgés, les organisations devraient maintenir à la fois des SBOM internes complets et des versions expurgées adaptées au partage externe.

Le processus de création et de maintien des SBOM implique plusieurs parties prenantes tout au long du cycle de vie du développement logiciel (SDLC). Les organisations devraient générer des SBOM tant pour les composants logiciels propriétaires que pour ceux en open source (OSS). Les éditeurs de logiciels et les développeurs sont principalement responsables de la génération initiale des SBOM dès les premières étapes du développement. Ces SBOM offrent une vue d’ensemble complète de tous les composants du code source. Les acheteurs de logiciels jouent un rôle clé dans la validation et la maintenance de ces documents pour les applications qu’ils déploient.

Les équipes de développement logiciel intègrent la génération de SBOM directement dans leurs pipelines d’intégration et de distribution continues (CI/CD). Pendant le processus de compilation (build), des outils d’analyse automatisés scannent le code source pour inventorier tous les composants, en capturant à la fois les dépendances directes et transitives. Ces outils génèrent des fichiers SBOM normalisés dans des formats tels que SPDX ou CycloneDX. (Les balises SWID sont une option moins répandue, mais toujours valide.) Ils documentent les métadonnées de chaque composant, les informations de version et les détails de licence.

Les systèmes de contrôle de version conservent des traces historiques des modifications apportées aux SBOM, permettant de suivre l’évolution de la composition logicielle dans le temps. Les entreprises peuvent ainsi suivre les changements de version et les correctifs de sécurité appliqués aux composants logiciels pour chaque version publiée, ce qui est essentiel pour la gestion des vulnérabilités et la réponse aux incidents de sécurité.

Les équipes de développement configurent généralement leurs pipelines pour déclencher des mises à jour SBOM en fonction d’événements spécifiques : lorsque de nouvelles dépendances sont ajoutées, lorsque des composants existants sont mis à jour ou lorsque des correctifs de sécurité sont appliqués. Ce processus de mise à jour continue maintient l’alignement entre la composition réelle du logiciel et sa documentation.

Les points de contrôle de la qualité tout au long du pipeline de développement valident l’exhaustivité et la précision des SBOM. Ces étapes de validation permettent de vérifier que chaque SBOM répond aux normes requises et contient toutes les informations nécessaires avant la mise à disposition du logiciel. La validation automatisée réduit les lacunes de la documentation et améliore la cohérence entre les versions.

L’écosystème d’outils soutenant la création de SBOM continue de se développer. Les générateurs de SBOM constituent la base : ils analysent automatiquement le code source pour identifier les composants et leurs relations. Des outils de validation vérifient ensuite les SBOM générés en les comparant aux normes et spécifications établies, signalant les informations manquantes ou incorrectes. La réussite de l’automatisation des SBOM repose sur des bonnes pratiques reconnues : standardisation des formats entre équipes, mise en place de conventions de nommage cohérentes, documentation claire des règles d’automatisation et création de boucles de rétroaction pour une amélioration continue.

Les plateformes de gestion s’appuient sur ces capacités de base en proposant des fonctionnalités de stockage, d’analyse et de distribution des SBOM à l’échelle de l’organisation. Les plateformes les plus avancées vont plus loin en intégrant les données des SBOM dans des workflows plus larges de gestion des risques et de la conformité.

Par exemple, des outils d’automatisation peuvent mapper les vulnérabilités aux composants logiciels concernés, hiérarchiser les efforts de résolution en fonction de leur gravité, et suivre l’évolution des risques pour identifier ceux nouvellement introduits. En consolidant les données et en fournissant des informations en temps réel, ces outils permettent aux équipes de développement, de sécurité et de conformité de collaborer plus efficacement.

Il est crucial de sélectionner le bon format SBOM pour une mise en œuvre efficace. Les SBOM doivent permettre la génération automatisée et le dimensionnement de la lisibilité machine à travers l’écosystème logiciel. L’automatisation des processus SBOM élimine les erreurs de saisie manuelle lors de la création et permet une intégration transparente avec les outils de sécurité et de développement.

Plusieurs formats normalisés sont utilisés pour permettre la génération, la validation et la consommation automatisées des données SBOM, tout en favorisant l’intégration avec les outils de sécurité et de développement existants. Les entreprises doivent mettre en œuvre la génération automatisée de SBOM dans leurs pipelines CI/CD pour s’assurer que la documentation reste à jour avec les modifications logicielles.

Le cadre actuel de la CISA reconnaît principalement deux formats : SPDX et CycloneDX. Chacun aborde la documentation des composants logiciels de manière différente, avec des niveaux de détail variables et des cas d’utilisation spécifiques dans le cycle de vie du développement logiciel.

Le Software Package Data Exchange (SPDX) a été développé par la Linux Foundation et a été largement adopté par l’écosystème open source et par les éditeurs de logiciels commerciaux. Le format prend en charge la vérification cryptographique des formules et offre plusieurs options de format lisibles par machine, notamment JSON, RDF, XML et YAML. La richesse de ses métadonnées permet d’assurer un suivi détaillé de la sécurité et de la provenance tout au long de la chaîne d’approvisionnement du logiciel.

SPDX excelle dans les scénarios de conformité open source. Il fournit des informations détaillées sur les licences et aide les entreprises à gérer efficacement l’utilisation de composants open source. De grands éditeurs de logiciels et fournisseurs de services cloud ont adopté SPDX pour la robustesse de sa spécification et la prise en charge étendue de son écosystème.

CycloneDX, développé par la fondation OWASP, est conçu spécifiquement pour la sécurité des applications et la gestion des risques liés à la chaîne d’approvisionnement logicielle. Il offre des fonctionnalités essentielles pour la gestion des vulnérabilités, le suivi des composants et la sécurité de la chaîne d’approvisionnement, avec un accent fort sur l’intégration VEX et la prise en charge de l’analyse des conteneurs.

Les éléments du format axés sur la sécurité le rendent particulièrement adapté aux entreprises qui mettent en œuvre des programmes complets de sécurité de la chaîne d’approvisionnement en logiciels. Sa prise en charge native des cas d’utilisation a favorisé l’adoption par les équipes de sécurité et les workflows de gestion des vulnérabilités.

Les balises SWID (Software Identification) fournissent un mécanisme standardisé pour l’identification et la gestion des logiciels. Le format permet un suivi complet des actifs logiciels avec des fonctionnalités de gestion du cycle de vie, de suivi des correctifs et de contrôle des stocks dans les environnements d’entreprise. Notamment, les balises SWID ne sont plus répertoriées comme format pris en charge dans les directives 2024 pour le mappage des attributs, mais elles restent une option valide en tant qu’identifiant unique au sein des SBOM.

L’analyse de la composition des logiciels (SCA) est un processus actif de cybersécurité (avec les outils associés) qui recherche les vulnérabilités dans le code, tandis qu’une nomenclature des logiciels (SBOM) fournit un stock normalisé de tous les logiciels composant un produit. Bien que les deux prennent en charge la sécurité de la chaîne d’approvisionnement des logiciels, ils ont des objectifs distincts dans les environnements de développement modernes.

Bien que les deux formats soient centrés sur les composants logiciels, les outils SCA (Software Composition Analysis) scannent et analysent activement le code pendant le développement, en se concentrant principalement sur les composants open source et les dépendances tierces. Ces outils fournissent des informations en temps réel pour la détection de vulnérabilités, la conformité des licences et l’application des politiques de sécurité.

Un SBOM fonctionne comme un inventaire standardisé capturant tous les composants logiciels, y compris le code propriétaire. Les SBOM offrent une transparence sur la composition logicielle grâce à des formats structurés comme SPDX et CycloneDX, mais n’incluent pas intrinsèquement de capacités d’analyse. Tandis que les outils SCA soutiennent généralement les pratiques de sécurité internes, les SBOM sont de plus en plus exigés par les réglementations et les normes industrielles.

Les entreprises mettent généralement en œuvre les deux solutions conjointement : les outils SCA surveillent activement la sécurité durant le développement, et les SBOM sont maintenus pour répondre aux exigences de conformité et assurer la visibilité sur la chaîne d’approvisionnement. Les outils SCA génèrent et valident souvent les SBOM automatiquement, tandis que la documentation SBOM vient alimenter les politiques d’analyse.

La complexité des chaînes d’approvisionnement logicielles modernes rend l’adoption des SBOM essentielle pour une gestion globale des risques et une garantie de sécurité efficace. Les organisations utilisent de plus en plus des plateformes automatisées capables de consolider les données SBOM avec d’autres informations de sécurité et de conformité afin de faciliter la prise de décision.

Les équipes de sécurité intègrent les données SBOM dans leurs stratégies globales de gestion des risques applicatifs via des plateformes automatisées permettant la détection et la réponse aux vulnérabilités en temps réel. Lorsque de nouvelles vulnérabilités et expositions courantes (CVE) sont révélées, ces plateformes peuvent immédiatement les associer aux composants affectés dans l’ensemble du portefeuille logiciel en s’appuyant sur les inventaires SBOM. Cela aide les entreprises à maintenir des pratiques de développement logiciel sécurisées.

Cette intégration permet d’obtenir des informations pilotées par l’IA pour la hiérarchisation des risques, aidant ainsi les équipes à traiter les CVE les plus critiques en premier. Lors de la réponse aux incidents, les données détaillées sur les composants des SBOM fournissent des renseignements essentiels sur les composants potentiellement compromis. Cela permet de cibler les efforts de remédiation et d’évaluer les risques de manière plus précise.

Les SBOM jouent un rôle important dans la gestion des vulnérabilités en fournissant un stock complet des composants logiciels et en permettant une identification rapide des systèmes affectés lorsque de nouvelles vulnérabilités sont découvertes.

Cependant, toutes les vulnérabilités ne présentent pas le même risque et la détermination de l’exploitabilité peut s’avérer difficile. C’est là qu’intervient le Vulnerability Exploitability eXchange (VEX). VEX est un cadre des exigences de sécurité qui renforce la fonctionnalité SBOM en fournissant un contexte essentiel sur les vulnérabilités connues. Bien qu’un SBOM identifie tous les composants d’un produit logiciel, il n’indique pas si les vulnérabilités découvertes sont exploitables. VEX comble cette lacune en clarifiant l’impact réel des vulnérabilités.

VEX (Vulnerability Exploitability eXchange) informe les équipes chargées de la réponse aux incidents de sécurité (PSIRT) et les autres équipes de sécurité sur l’effet réel de certaines vulnérabilités sur leurs environnements logiciels. En utilisant le Common Security Advisory Framework (CSAF), VEX fournit des mises à jour lisibles par machine sur l’impact des vulnérabilités. Grâce à ces informations, les équipes de sécurité peuvent prendre des décisions plus rapides et mieux éclairées.

En intégrant les données VEX aux SBOM, les entreprises peuvent réduire les faux positifs, hiérarchiser les risques réels et rationaliser les workflows de gestion des vulnérabilités. Cette approche combinée marque une avancée significative dans l’évaluation automatisée des risques de sécurité et la correction ciblée.

À mesure que les exigences réglementaires évoluent, les entreprises ont besoin de capacités de gestion de la conformité sophistiquées capables de gérer des exigences SBOM complexes. Les SBOM agissent comme une forme d’attestation, fournissant une documentation vérifiable attestant que les composants logiciels sont conformes à des normes telles que les directives du NIST et le décret 14028. En proposant des enregistrements transparents sur la composition et la sécurité des logiciels, les SBOM simplifient les audits et démontrent l’alignement des réglementations dans tous les secteurs.

Les agences fédérales et les secteurs réglementés doivent démontrer qu’ils se conforment à divers cadres d’exigences, notamment les lignes directrices du NIST et l’Executive Order 14028. Les plateformes de conformité Advanced peuvent vérifier automatiquement que les composants respectent les normes de sécurité, suivre l’état de la conformité dans plusieurs cadres des exigences et fournir des alertes en temps réel lorsque des composants s’écartent des exigences. Ces capacités peuvent aider les entreprises à maintenir une conformité continue tout en réduisant la surveillance manuelle.

Les environnements cloud natifs et conteneurisés posent des défis uniques en matière de gestion des SBOM. La nature dynamique de ces environnements nécessite des approches spécialisées pour gérer des architectures de microservice complexes, des images de conteneur qui changent fréquemment et des déploiements couvrant de nombreux fournisseurs de cloud et plateformes.

Les entreprises abordent ces défis grâce à des outils SBOM spécialisés qui s’intègrent directement aux plateformes d’orchestration de conteneurs. Ces solutions permettent de générer des SBOM en temps réel lors de la création et du déploiement d’images de conteneurs, tout en offrant une visibilité unifiée sur les environnements cloud hybrides.

En automatisant le suivi des composants et en l’intégrant aux outils de sécurité existants dans le cloud, les entreprises peuvent maintenir des stocks précis des composants logiciels et répondre rapidement aux menaces de sécurité dans l’ensemble de leur infrastructure cloud. Cette fonctionnalité s’applique aux applications exécutées dans des conteneurs, en tant que fonctions sans serveur ou dans des environnements traditionnels.

Les SBOM constituent la base de la gestion des risques liés à la chaîne d’approvisionnement, en permettant une visibilité complète sur les logiciels tiers. Les entreprises utilisent souvent des plateformes alimentées par l’IA pour analyser les données issues des SBOM en parallèle d’autres indicateurs de sécurité, afin de créer une vue holistique de la santé des applications et de l’exposition au risque.

Ces plateformes suivent les versions des composants, évaluent les risques fournisseurs, assurent la conformité des licences et fournissent des informations exploitables pour atténuer les risques. L’intégration des données SBOM aux processus de gestion des risques plus larges permet aux organisations de prendre des décisions éclairées sur leurs dépendances logicielles et de maintenir des environnements applicatifs plus sûrs et conformes.

Les entreprises peuvent être confrontées à plusieurs obstacles majeurs lors de la mise en œuvre des pratiques SBOM à l’échelle de leur écosystème logiciel. Comprendre et relever ces défis est essentiel pour réussir leur adoption et maintenir une sécurité efficace des données tout au long de la chaîne d’approvisionnement.

Les défis suivants se présentent souvent lorsque les entreprises mettent en œuvre des pratiques SBOM :

• Gérer de milliers de composants logiciels dans divers environnements
  
  
• Intégration des données SBOM entre différents outils de développement et plateformes de sécurité
  
  
• Maintien de la qualité des données, notamment pour les logiciels anciens et les composants tiers
  
  
• Suivi des dépendances dans des environnements cloud à cycles de déploiement rapides
  
  
• Trouver un équilibre entre les contraintes de ressources et la nécessité de disposer de données SBOM précises et à jour
  
  
• Adaptation aux architectures cloud natives dynamiques, où les composants changent fréquemment

La réussite de la mise en œuvre de la SBOM nécessite une approche stratégique alignée sur les normes du secteur et les besoins organisationnels. Parmi les principaux éléments, vous trouverez :

• Automatiser les processus tout au long du cycle de développement du logiciel
  
  
• Intégrer de façon fluide avec les workflows et les outils de sécurité existants
  
  
• Utiliser une plateforme unifiée pour la gestion des SBOM

• Mettre en œuvre les éléments essentiels aux fonctionnalités de base du SBOM et à la conformité
  
  
• Enrichir la documentation pour couvrir des cas d’utilisation plus larges en matière de sécurité et de conformité
  
  
• Offrir une visibilité complète sur la chaîne d’approvisionnement grâce à des fonctionnalités avancées

• Générer et mettre à jour les SBOM en temps réel, notamment dans les environnements cloud natifs
  
  
• Documenter les informations inconnues de manière transparente plutôt que de les omettre
  
  
• Gérer à la fois des SBOM internes complets et des versions expurgées à partager en externe
  

• Définir des politiques claires de gouvernance SBOM avec audits réguliers et validation automatisée
  
  
• Connecter les données SBOM à Vulnerability Exploitability eXchange (VEX) pour une meilleure gestion des vulnérabilités

En suivant ces pratiques, les entreprises peuvent améliorer la visibilité de la chaîne d’approvisionnement, renforcer la sécurité et maintenir la conformité tout en relevant les défis de la mise en œuvre du SBOM.

Le paysage de la sécurité des chaînes d’approvisionnement logicielles continue d’évoluer, stimulant l’innovation dans les technologies SBOM et leur adoption. Les entreprises font face à des menaces de plus en plus sophistiquées, et le rôle des SBOM dans la sécurisation des écosystèmes logiciels devient de plus en plus crucial.

Plusieurs tendances majeures façonnent l’avenir de la mise en œuvre et de l’utilisation des SBOM :

Les avancées en l’intelligence artificielle transforment la manière dont les entreprises gèrent et utilisent les SBOM. Les systèmes d’IA modernes automatisent désormais la génération et l’analyse des SBOM, tout en fournissant une analyse prédictive plus précise des risques et une détection plus fine des vulnérabilités. Cette automatisation s’étend à l’identification proactive des risques de sécurité dans l’ensemble de la chaîne d’approvisionnement logicielle.

Une avancée notable est l’émergence de BOM spécialisés en IA/ML, conçus pour relever les défis spécifiques liés aux modèles et au code générés par l’IA. Ces BOM enrichis documentent l’architecture des modèles d’IA, les données d’entraînement et les méthodes de test, apportant la transparence nécessaire aux processus de développement en intelligence artificielle.

Le paysage de la sécurité lié à la gestion des SBOM continue également d’évoluer. La blockchain et les technologies de registre distribué offrent de nouvelles solutions pour le stockage et le partage sécurisés des SBOM, créant des pistes d’audit immuables particulièrement précieuses pour les systèmes d’infrastructure critique. Les organisations réclament de plus en plus des données SBOM exploitables, permettant l’identification rapide des composants compromis et une résolution efficace.

La blockchain peut renforcer la sécurité des SBOM en assurant un stockage inviolable, en permettant une vérification décentralisée et en facilitant le partage sécurisé entre organisations avec des contrôles d’accès stricts.

Cette convergence technologique favorise l’adoption de plateformes unifiées, intégrées aux pratiques DevSecOps existantes. Ces solutions automatisent l’ensemble du cycle de vie des SBOM, de la fusion de différentes sources de données à la gestion des validations pour de multiples versions et branches logicielles, tout en fournissant des informations utiles à l’atténuation des risques.