À la même époque l'année dernière, en 2023, la Security and Exchange Commission a publié un communiqué de presse concernant un procès intenté contre une société de logiciels basée à Austin, au Texas. Ce procès faisait écho à une préoccupation qui préoccupe les éditeurs de logiciels du monde entier : la sécurité de la chaîne d'approvisionnement logicielle. Les cybercriminels acteurs malveillants ciblent depuis un certain temps déjà les chaînes d'approvisionnement logicielles, exploitant des vulnérabilités telles que celle du framework Log4j pour installer des logiciels malveillants.
Cette préoccupation croissante pour la sécurité de la chaîne d'approvisionnement est l'une des principales raisons pour lesquelles la nomenclature logicielle (SBOM) trouve sa place dans les réglementations administratives officielles en matière de cybersécurité. Les chaînes logistiques logicielles sont souvent complexes et impliquent de multiples processus. La SBOM contribue à la visibilité des chaînes logistiques en répertoriant les différents composants et dépendances auxquels ces processus sont directement liés. Par conséquent, pour élaborer efficacement une stratégie de gestion des risques liés à la chaîne logistique logicielle, nous devons comprendre la SBOM et son champ d'application.
Introduction à la SBOM (Software Bill of Materials)
Une Software Bill Of Materials (SBOM) est une liste détaillée des différents composants d'un logiciel, y compris ses composants open source, ses bibliothèques et leurs relations. L'idée est de permettre aux parties prenantes de comprendre en détail tout ce qu'apporte le logiciel, garantissant ainsi la transparence dans le contexte de la cybersécurité. Les transformations dans les modes de développement et de livraison des logiciels ont entraîné une complexité croissante qui permet aux cyberattaquants d'inventer des moyens créatifs d'agir. La SBOM est donc un filet de sécurité essentiel qui permet d'avoir une visibilité sur nos applications.
Pourquoi la SBOM est-elle essentielle pour la cybersécurité ?
Lorsque le président Biden a mis l'accent sur la SBOM dans son décret concernant l'amélioration de la cybersécurité, c'était en connaissance des vulnérabilités de la chaîne d'approvisionnement que ciblent les campagnes malveillantes. Une liste imbriquée telle que la SBOM décompose essentiellement le logiciel en ses composants et aide à identifier ces vulnérabilités. Voici trois raisons qui rendent la SBOM essentielle pour la cybersécurité :
- Transparence des logiciels : La SBOM aide les parties prenantes à identifier les composants obsolètes ou à risque dans le logiciel. S'il existe, par exemple, une bibliothèque de cryptage obsolète ou un framework de journalisation comme Log4j, les experts en sécurité peuvent facilement identifier le risque associé.
- Suivi des composants open source : De nombreuses solutions logicielles modernes encouragent l'intégration de composants et de bibliothèques open source. Leur sécurité n'est pas toujours vérifiée, c'est pourquoi la SBOM permet de les suivre afin d'identifier les risques potentiels.
- Évaluation des dépendances : Si certains composants ne semblent pas présenter de menace pour la cybersécurité, leur dépendance à d'autres composants ou bibliothèques peut en être une. Par conséquent, la SBOM aide également les experts en sécurité à examiner ces dépendances et à identifier les failles de sécurité.
- Sécurité de la chaîne d'approvisionnement : La transparence au sein de la chaîne d'approvisionnement concernant la posture de sécurité de divers composants logiciels permet de garantir des stratégies de sécurité proactives contre toute exploitation potentielle. La SBOM offre aux acheteurs toutes les informations nécessaires pour mettre en œuvre ces stratégies de sécurité de la chaîne d'approvisionnement.
- Gestion de la conformité : La SBOM aide également les parties prenantes à évaluer la conformité réglementaire des solutions logicielles et de leurs composants. Avec des réglementations strictes dans tous les secteurs, notamment la santé, la fintech, la défense et bien d'autres, tout manquement à la conformité de la part d'un composant logiciel peut être facilement détecté.
Composants clés d'une SBOM (nomenclature logicielle)
Le rapport de la NTIA’s, conformément au décret présidentiel, a suggéré trois éléments interdépendants dans une SBOM qui sont considérés comme offrant la transparence requise dans le logiciel. Ces " éléments minimaux " peuvent fournir une vue détaillée de la technologie et du schéma fonctionnel du logiciel, le rendant visible pour une évaluation approfondie de la sécurité.
- Champs de données : Cet élément permet de vérifier les détails des composants logiciels dans une structure SBOM formelle. Les champs de données comprennent notamment le nom du fournisseur, la version du composant et les relations de dépendance, afin de faciliter le suivi des vulnérabilités de sécurité potentielles.
- Prise en charge de l'automatisation : Les supports d'automatisation offrent les formats de données requis qui permettent une navigation facile dans les données SBOM et la lisibilité machine des composants logiciels. Il s'agit d'un élément essentiel pour garantir un audit plus rapide et autonome du logiciel. Les balises CycloneDX, SPDX et SWID sont les trois formats acceptables selon le rapport.
- Processus : Il s'agit des pratiques nécessaires qui aideraient à intégrer la génération et la gestion des SBOM dans le cycle de vie sécurisé du développement des logiciels. Ces pratiques dictent divers aspects des SBOM, notamment leur fréquence de génération, les composants et les dépendances inclus, ainsi que les dépendances connues/inconnues, entre autres.
Avantages de la mise en œuvre d'une SBOM (nomenclature logicielle)
A survey in 2022 suggère que 53 % des entreprises de tous les secteurs considèrent les SBOM comme un outil utile pour la déclaration et la conformité. Une adoption aussi positive des SBOM ne peut être attribuée qu'à l'attention particulière portée aux détails que ces projets de loi offrent. C'est cette attention aux détails qui, à son tour, conduit à de nombreux avantages offerts par les SBOM :
- Transparence tout au long de la chaîne d'approvisionnement : Les champs de données et les relations indiqués par les SBOM permettent d'avoir une vue d'ensemble détaillée de l'ensemble de la chaîne d'approvisionnement logicielle. Les différentes versions des composants logiciels, leurs dépendances et leurs compatibilités entre les logiciels, ainsi que leurs risques de sécurité peuvent tous être facilement identifiés et analysés.
- Posture de sécurité cohérente : Même pour les logiciels qui sont achetés malgré les risques potentiels suggérés par leur SBOM, les administrateurs de sécurité peuvent être mieux préparés à faire face à d'éventuelles vulnérabilités. Des mesures proactives peuvent être prises sur la base de la SBOM afin d'atténuer les risques de sécurité.
- Gestion de la conformité : Si la SBOM est en soi une obligation réglementaire, elle aide également les parties prenantes à respecter strictement les réglementations applicables à certains composants du logiciel. De plus, grâce à des audits réguliers, la SBOM peut également aider à identifier tout écart de conformité.
- Menaces provenant de tiers : Les risques de sécurité posés par les composants tiers open source du logiciel peuvent être facilement suivis à l'aide de la SBOM. Même si le fournisseur néglige sciemment ou non une faille de sécurité, la SBOM peut aider à remonter jusqu'au composant tiers responsable.
Comment créer et gérer une SBOM ?
Il existe des outils permettant de créer une SBOM avec tous les éléments nécessaires. Ces outils ont pour fonction essentielle de traduire leur analyse des composants logiciels dans l'une des normes SBOM souhaitées, telles que SPDX, CycloneDX, etc. Ces outils de génération de SBOM peuvent également aider les parties prenantes à suivre les dépendances obsolètes, les licences et autres aspects susceptibles d'entraîner des failles de sécurité. Voici comment fonctionnent ces outils :
- Étape 1 – Intégration de l'outil SBOM dans le pipeline CI/CD : Afin d'enregistrer les différents composants du code logiciel, les outils SBOM doivent être intégrés au pipeline CI/CD. Ces outils peuvent être installés sur site ou dans un environnement cloud, selon les besoins.
- Étape 2 – Analyse du référentiel de code : Ensuite, l'outil analyse le code afin d'identifier les différents composants, bibliothèques, frameworks open source et autres éléments du logiciel.
- Étape 3 – Traduction de l'analyse du code : Une fois que tous les composants et dépendances du code ont été analysés, les données sont traduites dans l'un des formats SBOM standard, selon les besoins.
- Étape 4 – Génération de la SBOM : Les données SBOM traduites peuvent enfin être exportées au format XML ou JSON pour être examinées plus en détail. La NTIA exige la génération d'une nouvelle SBOM à chaque mise à jour d'un composant logiciel.
Normes et directives SBOM
Les normes et directives relatives à la génération de SBOM contribuent à maintenir l'uniformité de la structure SBOM tout en couvrant tous les éléments de la liste imbriquée des composants logiciels, bibliothèques, etc. Ces directives sont également nécessaires pour encourager la génération et le traitement automatisés des SBOM.
- System Package Data Exchange (SPDX) : Cette norme ouverte peut aider à créer un langage lisible qui peut être traduit dans des formats de fichiers tels que XML, JSON, YAML, etc. La norme permet de décrire efficacement les différents composants logiciels pendant le développement et le déploiement en collectant des données sous forme d'informations de création, d'informations sur les fichiers, d'informations sur les paquets, etc.
- CycloneDX : Ce format a été lancé en mettant l'accent sur la sécurité et la génération automatisée de SBOM. Cette spécification légère permet d'assurer une analyse approfondie des composants logiciels, de leur interaction avec les services externes et des relations entre eux. La norme open source s'adapte également bien aux composants open source dynamiques qui sont régulièrement modifiés et redistribués.
- Balises d'identification des logiciels (balises SWID) : Créées par l'ISO en 2012, les balises SWID sont destinées à suivre le composant logiciel tout au long de son cycle de vie. Ces balises, à savoir primaire, patch, corpus et supplémentaire, sont ajoutées une fois le logiciel installé afin de fournir des détails sur l'installateur, l'installation, les correctifs et d'autres aspects d'un composant logiciel.
Défis liés à la SBOM (nomenclature logicielle)
Les défis liés à la SBOM concernent principalement sa partie génération, compte tenu de sa nature profondément structurée et formelle. Voici comment ces défis se manifestent :
- Maturité des outils SBOM : Bien que les outils évoluent constamment pour se conformer aux formats et structures SBOM standardisés, il existe encore certaines lacunes. De plus, l'utilisation de ces outils est également compliquée pour les différentes parties prenantes, qui ont du mal à s'y retrouver en raison, entre autres, du manque d'interfaces efficaces et d'interopérabilité.
- Adoption et intégration lentes : Certains fournisseurs tiers ne respectent toujours pas l'obligation SBOM, ce qui entraîne un retard dans l'adoption et l'intégration des ressources SBOM, en particulier avec les logiciels open source.
- Continuité dans la génération des SBOM : Les entreprises ne parviennent toujours pas à faire de la génération des SBOM un processus continu, qui intervient à différentes étapes du cycle de vie du développement logiciel (SDLC). Bien que ce soit une aspiration pour la plupart des entreprises qui traitent des SBOM, beaucoup d'entre elles n'y sont pas encore parvenues.
- Problèmes de sécurité supplémentaires : Certains experts en sécurité affirment également que la gestion globale des vulnérabilitésvulnerability management ne peut protéger les écosystèmes numériques contre les menaces externes. Les organisations doivent hiérarchiser les vulnérabilités qu'elles souhaitent traiter et élaborer des stratégies en conséquence. Cela est difficile à réaliser avec les SBOM en raison de leur complexité accrue.
Meilleures pratiques pour garantir une utilisation efficace des SBOM
La génération de SBOM est déjà une bonne pratique. La meilleure pratique consiste à les générer de manière cohérente et tout au long du cycle de vie du développement logiciel (SDLC). Voici quelques autres pratiques qui peuvent permettre d'y parvenir et de maximiser l'utilité des SBOM pour la sécurité de la chaîne d'approvisionnement :
- Générer tôt et mettre à jour régulièrement : Il est essentiel que les SBOM soient générées le plus tôt possible dans le SDLC afin que chaque dépendance ajoutée puisse être enregistrée dès le début. Les mises à jour régulières de la SBOM permettront de s'assurer que toutes les versions et tous les lancements des différents composants logiciels sont dûment consignés dans la liste.
- Génération automatisée de la SBOM : L'automatisation étant un élément essentiel de la SBOM, il est logique de disposer de ressources automatisées pour la générer. L'automatisation garantirait également la génération régulière de factures tout au long du cycle de vie du développement logiciel.
- Formats standardisés : Les formats tels que SPDX ou CycloneDX ont la profondeur nécessaire pour capturer véritablement les données SBOM sensibles en matière de sécurité. L'utilisation de tels formats standardisés garantirait l'interopérabilité et la lisibilité automatique des factures.
- Contrôle de version : Le contrôle de version dans les SBOM garantira que toute nouvelle modification apportée ou publiée dans le composant logiciel pourra être facilement suivie à des fins d'évaluation de la sécurité. Cela rend également la SBOM plus responsable dans la gestion des dépendances.
Cas d'utilisation des SBOM
Bien que leur utilité première soit d'offrir des informations essentielles sur les vulnérabilités logicielles, les SBOM peuvent répondre à de nombreux cas d'utilisation, dont voici quelques exemples :
- Sécurité des logiciels : Les SBOM peuvent aider les équipes de sécurité à identifier précisément les parties vulnérables du code logiciel. Les équipes peuvent les utiliser pour rechercher et corriger les parties du logiciel susceptibles d'être exploitées par des cyberattaquants.
- Sécurité de la chaîne d'approvisionnement : De nombreuses institutions gouvernementales, notamment aux États-Unis et dans certains pays européens, ont rendu obligatoire l'intégration des SBOM dans les chaînes d'approvisionnement logicielles. Les experts prévoient qu'elles pourraient bientôt être mises à la disposition des clients finaux.
- Facilité d'approvisionnement : Alors que les entreprises de tous les secteurs s'inquiètent des incidents de cybersécurité, les SBOM inspirent confiance aux équipes d'approvisionnement à la recherche d'une solution logicielle. La transparence offerte a contribué à instaurer la confiance entre les deux parties.
- Facilité de développement : Comme les SBOM contiennent une ventilation détaillée des dépendances et des relations entre les composants logiciels, il est plus facile pour les développeurs de travailler sur de nouveaux composants sans perturber le fonctionnement antérieur.
Différences entre SBOM et SCA
Il est certain que la nomenclature logicielle (SBOM) et l'analyse de la composition logicielle (SCA) présentent des caractéristiques communes qui peuvent aider à comprendre les différents composants d'un logiciel. Par conséquent, pour faire un choix éclairé entre les deux, il faut tenir compte de la portée du cycle de vie du logiciel pour lequel vous souhaitez les utiliser.
Voici ce que les chefs d'entreprise doivent savoir pour faire ce choix :
| Aspect | SBOM | SCA |
|---|---|---|
| Focus | Focus dédié à l'enregistrement des composants logiciels variés et à la génération d'une liste détaillée. | L'accent est mis sur la gestion et l'analyse des composants à la recherche de vulnérabilités. |
| Offres | Propose un inventaire hiérarchique des composants, bibliothèques et dépendances | Permet d'identifier et de corriger les vulnérabilités de sécurité dues à des composants à risque. |
| Utilité | Le champ d'application de l'utilité est plus large, couvrant les développeurs, les équipes de sécurité, les équipes d'approvisionnement, etc. | Principalement limité aux équipes de sécurité qui ont besoin d'outils SCA pour traiter les composants vulnérables. |
Différences entre BOM et SBOM
Les termes BOM et SBOM sont si similaires dans leur nature qu'ils peuvent souvent être confondus. Cependant, ils appartiennent tous deux à des domaines très distincts. Alors que la BOM est un inventaire plus pertinent pour le domaine de la fabrication, la SBOM a un rôle très spécifique dans le domaine du génie logiciel. Voicicomment les décideurs peuvent distinguer les deux :
| Aspect | Nomenclature (BOM) | Nomenclature logicielle (SBOM) |
|---|---|---|
| Application | Plus applicable aux produits physiques tels que le matériel informatique ou électronique. | Application dédiée aux produits logiciels et à leurs chaînes d'approvisionnement. |
| Conformité | Conformité axée sur les réglementations en matière de fabrication ou de construction. | Conformité axée sur les licences logicielles, les besoins en matière de sécurité, etc. |
| Utilisateurs | Fabricants, responsables de la chaîne d'approvisionnement. | Développeurs, équipes de sécurité et auditeurs réglementaires. |
Cybersécurité alimentée par l'IA
Améliorez votre posture de sécurité grâce à la détection en temps réel, à une réponse à la vitesse de la machine et à une visibilité totale de l'ensemble de votre environnement numérique.
Obtenir une démonstrationConclusion
Faisant partie des réglementations administratives en matière de cybersécurité, la SBOM occupe déjà une place essentielle dans le cycle de vie des logiciels. La sécurité des chaînes d'approvisionnement logicielles fait partie des nombreux cas d'utilisation auxquels elle peut servir. Avec des architectures distribuées, des infrastructures codifiées et des réseaux étendus, les solutions logicielles répondent désormais à des cas d'utilisation commerciale plus complexes que jamais. Les composants clés et les formats standard des SBOM en font un allié puissant pour lutter contre des incidents tels que ceux survenus chez Uber et Solarwinds.
Sur la base de notre discussion dans ce blog, les chefs d'entreprise et les experts en sécurité peuvent suivre les meilleures pratiques pour automatiser la génération des SBOM et les exploiter pour la sécurité de la chaîne d'approvisionnement.
SentinelOne peut vous aider à utiliser des fonctionnalités telles que la SBOM pour protéger votre chaîne d'approvisionnement logicielle. Pour en savoir plus sur notre expertise, cliquezici.
FAQs
Une nomenclature logicielle, ou SBOM, est une liste hiérarchique détaillée des différents composants logiciels, bibliothèques, dépendances, etc. Il est important de garantir la visibilité des parties du code logiciel susceptibles de présenter des risques, qui peuvent être exploitées pour des cyberattaques.
Grâce à la visibilité approfondie offerte par la SBOM, les experts en sécurité peuvent plus facilement détecter les vulnérabilités potentielles dans la chaîne logistique logicielle et les traiter efficacement.
Conformément aux réglementations administratives, les éléments clés d'une SBOM comprennent les champs de données, les pratiques et processus, ainsi que la prise en charge de l'automatisation.
Pour une stratégie SBOM efficace, il est essentiel de suivre les meilleures pratiques telles que la génération précoce, les mises à jour régulières, la génération automatisée et l'intégration avec les pipelines CI/CD.
Les trois normes qui fonctionnent le mieux avec les SBOM sont SPDX, CycloneDC et SWID Tags.
Pour générer une nomenclature logicielle, vous pouvez utiliser des outils d'automatisation qui vous aideront à obtenir les formats et les résultats requis. Les experts de SentinelOne peuvent vous aider dans cette démarche.

