Définition
Une nomenclature logicielle (en anglais : Software Bill of Materials, ou SBOM) est une liste de tous les composants utilisés pour construire et exécuter une application. Ils comprennent un inventaire de tous les modules, bibliothèques, dépendances, modèles ML, ensembles de données ou autres composants que les développeurs intègrent dans une application ou dont la présence est requise lors de l’exécution d’une application.
Aperçu
Dans le monde du développement logiciel, la nomenclature logicielle (SBOM) peut être comparée aux ingrédients et à l’étiquetage nutritionnel figurant sur la face latérale d’une boîte de conserve.
C’est pourquoi les équipes de développement, d’exploitation et de sécurité devraient insister sur la création d’un SBOM pour chaque version de logiciel afin d’identifier et de corriger les vulnérabilités en matière de sécurité, ainsi que de documenter l’utilisation des composants pour les besoins des licences et des réglementations.
Comme les ingrédients d’une boîte de conserve, les SBOM fournissent une liste détaillée de tous les composants associés à une version particulière d’un logiciel, y compris les vulnérabilités potentielles et les informations relatives aux licences.
Comment fonctionnent les SBOM ?
En général, les SBOM sont générés au cours de la phase de construction du processus de développement du logiciel. Cette étape consiste à compiler et à assembler le logiciel à partir du code source en programmes exécutables ou autres composants. La génération d’un SBOM à ce stade permet de dresser une liste détaillée et précise de tous les composants, bibliothèques et dépendances inclus dans le logiciel. Cela est essentiel pour suivre la provenance et garantir la sécurité de tous les composants utilisés dans le logiciel.
Les étapes ci-dessous décrivent le processus typique de génération d’un SBOM :
- Identification des composants: Les développeurs ou les outils automatisés identifient tous les composants utilisés dans le logiciel, y compris les bibliothèques, les frameworks, les modules et les dépendances. Cette opération peut être effectuée manuellement ou à l’aide d’outils automatisés qui analysent la base de code et génèrent une liste exhaustive.
- Version et métadonnées: Chaque composant du SBOM est associé à des métadonnées telles que les numéros de version, les informations de licence et les dépendances. Ces métadonnées sont importantes pour le suivi des vulnérabilités, le respect des accords de licence et la gestion des mises à jour et des patchs.
- Format et normes: Les SBOM peuvent être représentés dans différents formats tels que SPDX (Software Package Data Exchange) ou CycloneDX. SPDX est une norme largement utilisée pour documenter le contenu et les licences des progiciels.
- Distribution et partage: Les SBOM peuvent être partagés entre les différentes parties prenantes de la chaîne d’approvisionnement logicielle, notamment les développeurs, les vendeurs, les clients et les régulateurs. Ce partage facilite la transparence, la collaboration et la responsabilité dans le développement, le déploiement et la conformité réglementaire des logiciels
- Intégration aux outils et processus: Les SBOM peuvent être intégrés dans divers outils et processus de développement et de sécurité des logiciels. Par exemple, ils peuvent être utilisés par des scanners de vulnérabilité pour identifier les failles de sécurité connues dans les composants logiciels et par des outils de conformité de licence pour garantir le respect des exigences en matière de licence.
- Surveillance et mises à jour continues: Les logiciels étant en constante évolution, les SBOM doivent être régulièrement mis à jour pour refléter les changements intervenus dans la composition des logiciels. Il s’agit notamment d’ajouter de nouveaux composants, de mettre à jour les versions et de supprimer les composants obsolètes ou vulnérables
La plupart des SBOM sont organisés de manière très structurée à l’aide de normes de formatage telles que SPDX ou CycloneDX pour produire des inventaires imbriqués du contenu de la chaîne logistique logicielle d’une application. Voici des exemples de la structure de quelques-uns des principaux formats :
SPDX
Dans la version actuelle de la génération d’un rapport SPDX, les champs suivants sont obligatoires :
- Nom du paquet
- Version du paquet
- Licences détectées
- Sommes de contrôle détectées dans la mesure du possible
Voici comment cela apparaîtrait dans le rapport :
PackageName: PyYAML SPDXID: SPDXRef-Package-PyYAML-3.10 PackageVersion: 3.10 PackageDownloadLocation: NOASSERTION FilesAnalyzed: false PackageChecksum: SHA256: 3d8ee7cc23fef4279e6a0a46ea8df14f2bfe09703dd1e67b465bca5d4b500602 PackageHomePage: NOASSERTION PackageLicenseConcluded: MIT PackageLicenseDeclared: NOASSERTION PackageCopyrightText: NOASSERTION
CycloneDX
L’implémentation de CycloneDX fournit les métadonnées générales du rapport qui comprennent des informations telles que la version de Cyclone DX, l’auteur et la date de génération du rapport. Il contient également des informations détaillées sur chacun des composants détectés et sur leurs vulnérabilités (VEX).
"type": "application",
"name": "ubuntu:bionic:libsqlite3-0",
"version": "3.22.0-1ubuntu0.4",
"hashes": [
{
"alg": "SHA-256",
"content": "1c0f71e7796c1ddb8527b9b052f9948fc8a2c1e8e9c89b084bcc36100f966714"
}
],
"licenses": [
{
"license": {
"id": "GPL-2.0",
"url": "http://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html"
}
}
]
}
Voici un exemple de la manière dont un sample SBOM peut être utilisé dans une application :
<?xml version="1.0" encoding="utf-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2"
serialNumber="urn:uuid:d6aa76fa-e488-480d-9ad0-f67765dfd015"
version="1">
<metadata>
<timestamp>2020-08-03T03:19:55.999Z</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>Node.js module</name>
<version>2.0.0</version>
</tool>
</tools>
<component type="library" bom-ref="pkg:npm/juice-shop@11.1.2">
<name>juice-shop</name>
<version>11.1.2</version>
<description>
<![CDATA[Probably the most modern and sophisticated insecure web application]]>
</description>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/juice-shop@11.1.2</purl>
<externalReferences>
<reference type="website">
<url>https://owasp-juice.shop</url>
</reference>
<reference type="issue-tracker">
<url>https://github.com/bkimminich/juice-shop/issues</url>
</reference>
<reference type="vcs">
<url>git+https://github.com/bkimminich/juice-shop.git</url>
</reference>
</externalReferences>
</component>
</metadata>
En analysant le code XML, ce SBOM fournit des détails non seulement sur les composants qui existent dans l’application, mais aussi des métadonnées concernant les versions et les URL associées à chaque composant.
Rôles du SBOM
La production de logiciels sécurisés de qualité, à grande vitesse et à grande échelle, nécessite une coopération totale entre les équipes de développement, d’exploitation et de sécurité. Le SBOM est un outil polyvalent qui sert de source unique de vérité tout au long du cycle de vie du développement logiciel (SDLC). Voici les différents rôles que joue le SBOM au sein des différentes équipes et dans les différents aspects du développement et du déploiement des logiciels.
Chaîne d’approvisionnement logicielle
La transparence et la traçabilité des composants logiciels, du développement au déploiement, permettent d’identifier l’origine de chaque composant et de s’assurer que seuls des composants vérifiés et sécurisés sont utilisés. Si une vulnérabilité est exploitée, elle peut être rapidement retracée et corrigée afin de minimiser les dommages.
Sécurité
Le SBOM est crucial pour la sécurité et le DevSecOps, permettant de s’assurer que tous les composants logiciels sont sécurisés et conformes avant qu’ils ne fassent partie du code. En répertoriant tous les composants et leurs versions, il permet aux équipes d’identifier et d’atténuer les vulnérabilités dès le début du processus de développement, ce qui permet une surveillance continue de la sécurité et des réponses rapides aux menaces de sécurité.
DevOps
En permettant l’automatisation et la surveillance des processus de développement, il fournit des informations détaillées sur les composants logiciels, ce qui permet un suivi efficace des mises à jour, des dépendances et des risques potentiels. Ces informations sont vitales pour maintenir la stabilité et la fiabilité du logiciel pendant l’intégration continue et le déploiement continu via les pipelines CI/CD.
Cloud Native
Dans les environnements cloud native, un SBOM est utilisé pour gérer et sécuriser divers microservices et applications conteneurisées. Il garantit que tous les composants basés sur le Cloud sont documentés et sécurisés. Ceci est particulièrement important dans les architectures cloud natives dynamiques et évolutives où les composants peuvent changer assez fréquemment.
Licences et conformité
Partie intégrante de la gestion des licences et de la garantie de conformité, il offre un inventaire détaillé de tous les composants logiciels, y compris les bibliothèques et les dépendances, avec leurs conditions de licence. Ce niveau de transparence permet aux équipes DevOps de vérifier que chaque composant est utilisé conformément à sa licence, évitant ainsi d’éventuels problèmes juridiques.
Cela également essentiel pour se conformer aux normes réglementaires, qui peuvent imposer la divulgation de composants logiciels pour des raisons de sécurité et de protection de la vie privée. Cela est particulièrement important dans les secteurs réglementés tels que les soins de santé, la finance et les infrastructures critiques, où le non-respect des réglementations peut entraîner des sanctions sévères.
| Rôles clés d’un SBOM dans la sécurisation de la chaîne d’approvisionnement | |
| Rôle | Description |
| Visibilité et transparence | Les SBOM offrent une visibilité complète sur les composants qui constituent une application logicielle. Cette transparence aide les équipes de sécurité à comprendre ce que contiennent leurs logiciels, ce qui leur permet de gérer les risques plus efficacement. |
| Gestion des vulnérabilités | En dressant la liste de tous les composants et de leurs versions, les SBOM permettent d’identifier les vulnérabilités connues de ces composants. Cela permet aux organisations de remédier rapidement aux vulnérabilités et de les corriger, réduisant ainsi le risque d’exploitation. |
| Conformité et réglementation | De nombreux cadres réglementaires et normes, tels que le NIST, l’ISO et d’autres, exigent des organisations qu’elles tiennent un inventaire des composants logiciels. Un SBOM permet de répondre à ces exigences de conformité en fournissant un moyen structuré de fournir la preuve de la conformité. |
| Gestion des risques | Comprendre les composants d’une application logicielle permet d’évaluer le risque associé à chaque composant. Il s’agit notamment d’évaluer le niveau de sécurité des bibliothèques tierces et des composants open source. |
| Réponse aux incidents | En cas d’incident de sécurité, un SBOM peut accélérer le processus de réponse à l’incident en identifiant rapidement les composants affectés par une vulnérabilité particulière et le développeur responsable, ce qui permet d’accélérer les mesures d’atténuation. |
| Sécurité renforcée | Les SBOM renforcent la sécurité de la chaîne d’approvisionnement en offrant une visibilité sur les composants tiers et en gérant les risques de sécurité associés aux chaînes d’approvisionnement logicielles, y compris les logiciels tiers et les logiciels open source. |
| Intégrité des logiciels | Les SBOM permettent de vérifier l’intégrité et la provenance des composants logiciels. Cela garantit que les composants utilisés sont légitimes et n’ont pas été altérés, ce qui renforce la sécurité globale des applications. |
| Amélioration de la maintenance | Avec un inventaire clair des composants, il devient plus facile de gérer la maintenance et les mises à jour des logiciels. Les SBOM permettent de s’assurer que tous les artefacts sont à jour et ont été analysés pour détecter les failles de sécurité, réduisant ainsi le risque d’exploitation dû à une version obsolète d’un composant spécifique. |
Importance du SBOM
La nomenclature logicielle joue un rôle essentiel dans le développement des logiciels, en servant d’inventaire complet qui détaille chaque composant, bibliothèque et dépendance des logiciels, ainsi que les informations relatives à leur licence. Les SBOM jouent également un rôle essentiel dans le respect des normes réglementaires, en aidant les organisations à faire face à la complexité de la garantie de l’intégrité juridique et opérationnelle de leurs opérations de développement de logiciels.
Source unique de vérité
Plus vite vous pourrez déterminer si et comment une vulnérabilité affecte vos applications et leur environnement d’exploitation, moins vous risquerez d’être confronté à une faille de sécurité. Cette source unique de vérité permet d’identifier et de remédier aux vulnérabilités de la chaîne d’approvisionnement beaucoup plus rapidement et efficacement que les autres méthodes. En cas de violation, le temps de réaction rapide que permet un SBOM peut épargner à une organisation d’importants dommages financiers.
Sécurité renforcée
Lorsque des problèmes de sécurité sont découverts par les développeurs d’un logiciel ou par des chercheurs indépendants, les informations relatives à ces failles sont généralement publiées dans des bases de données publiques sur les vulnérabilités, telles que la base de données CVE (également connue sous le nom de National Vulnerability Database ou NVD) du NIST. Des informations sur les vulnérabilités connues sont donc disponibles.
Dans la plupart des cas, cependant, il n’y a pas de moyen facile de le faire à partir des applications elles-mêmes. Vous ne pouvez pas simplement lancer une commande pour demander à une application si elle utilise une certaine bibliothèque. Bien qu’il soit possible d’analyser les applications pour identifier les dépendances et les autres composants, ce processus peut prendre beaucoup de temps et n’est pas facilement extensible. Les entreprises n’ont donc pas toujours le temps de respecter les délais de publication tout en identifiant les risques de sécurité critiques avant que les attaquants ne commencent à les exploiter.
Les SBOM relèvent ce défi en offrant une visibilité en temps réel des composants qui existent dans la chaîne d’approvisionnement d’une application. Grâce à ces informations, les équipes DevOps et de sécurité peuvent rapidement déterminer si les vulnérabilités connues ont un impact sur l’un des composants de leurs applications.
Bonnes pratiques SBOM
Si les SBOM contribuent grandement à améliorer la visibilité des chaînes d’approvisionnement logicielles et à prévenir l’introduction de failles de sécurité potentielles, la simple création d’un SBOM lors de la création d’une nouvelle application ne suffit pas à minimiser les risques en matière de sécurité. En outre, les mesures suivantes devraient être prises pour garantir l’efficacité de SBOM dans toutes les situations :
- Mises à jour permanentes– Les applications changent constamment, et les SBOM doivent évoluer avec elles. Lorsque vous ajoutez ou supprimez des composants d’application ou des dépendances, ou même si vous changez simplement la version d’un composant, veillez à mettre à jour votre SBOM en conséquence.
- Génération automatique – Il est possible de créer des SBOM manuellement, mais cela prend du temps, est difficilement extensible et inefficace. Cela augmente également le risque d’oublis ou d’erreurs dues à des fautes humaines. Pour améliorer la sécurité, les SBOM devraient être générés automatiquement en analysant les applications afin d’identifier leur contenu, puis en produisant automatiquement des SBOM basés sur les composants identifiés.
- Des métadonnées riches– Plus le SBOM contient de données concernant les versions, les sources et les vulnérabilités, plus il sera utile dans des situations cruciales. Dans de nombreux cas, le contexte fourni par les métadonnées est essentiel pour déterminer rapidement si une vulnérabilité donnée est réellement exploitable et comment y remédier.
- Cohérence – Compte tenu de la multiplicité des méthodes de formatage des SBOM, il est utile d’étudier les avantages et les inconvénients de chaque format et de déterminer celui qui convient le mieux à votre organisation. Cependant, une fois qu’une structure particulière est choisie, il est essentiel de maintenir la cohérence du format et des types de données requis pour une génération efficace de SBOM.
La solution SBOM de JFrog
La bonne gestion d’une nomenclature logicielle (Software Bill of Materials, ou SBOM) a toujours été une bonne pratique du point de vue de la sécurité et de la conformité. Toutefois, les récentes annonces du gouvernement américain et de l’Union européenne lui ont conféré une urgence particulière.
En octobre 2023, la Maison-Blanche a publié un décret qui suggère aux développeurs d’IA de fournir au gouvernement américain des informations détaillées sur la composition de leurs applications avant de les rendre publiques. De même, la loi sur la résilience opérationnelle numérique (DORA) de l’UE, qui devrait être promulguée en 2025, exige des institutions financières qu’elles fournissent le contenu de leurs applications logicielles afin d’améliorer la résilience opérationnelle des services financiers numériques.
Que ce soit pour des raisons de conformité ou de sécurité, il est important que les SBOM soient fournis dans un format standardisé commun. À cette fin, JFrog Xray prend en charge les formats SPDX, CycloneDX et d’autres formats standard qui permettent de créer un fichier lisible par machine répertoriant l’inventaire des composants logiciels et des dépendances. L’essentiel est de comprendre les exigences de votre SBOM et d’effectuer des exportations dans le format qui convient le mieux à votre application.
Lorsqu’il s’agit de gérer vos applications logicielles tout au long du cycle de vie du développement logiciel, la plateforme JFrog est la solution universelle de chaîne logistique logicielle pour DevOps, DevSecOps et MLOps. Elle comprend plus de 50 intégrations couvrant la plupart des principaux outils de l’écosystème du développement logiciel et permettant une gestion automatisée, intégrée, extensible et sécurisée de l’ensemble de la chaîne d’approvisionnement logicielle.
Pour une plongée en profondeur dans les SBOM, y compris la façon dont ils sont créés et gérés sur la plateforme JFrog, n’hésitez pas à planifier une démonstration ou suivre une visite guidée en ligne à votre convenance.
