Software Bill of Materials (SBOM) : Vue d'ensemble
Comment pouvez-vous vous prémunir contre les risques liés à la sécurité de la chaîne d’approvisionnement logicielle, c’est-à-dire les menaces à la sécurité qui proviennent de ressources logicielles tierces utilisées par votre entreprise ou dont votre entreprise dépend ?
Pour répondre à cette question, il est important d'envisager une nomenclature logicielle, ou SBOM. En répertoriant systématiquement les composants qui existent dans chaque application, ainsi que les dépendances que l’application nécessite pour s’exécuter, les SBOM fournissent la visibilité cruciale dont les entreprises ont besoin pour détecter et réagir aux risques de sécurité de la chaîne d’approvisionnement logicielle. En outre, les SBOM peuvent, dans certains cas, répondre aux exigences de conformité et fournir aux clients et aux partenaires l’assurance que votre entreprise prend la sécurité de la chaîne d’approvisionnement au sérieux.
Continuez votre lecture pour mieux comprendre ce qu’est un SBOM, comment les SBOM fonctionnent, pourquoi ils sont importants et comment les générer.
Qu’est-ce qu’un SBOM ?
Une nomenclature logicielle, ou SBOM, est une liste de tous les composants et dépendances (propriétaires et open source) qu’une application utilise. Souvent, les SBOM comprennent également des informations sur la version de chaque composant et dépendance ; cela est important car les problèmes de sécurité n’affectent souvent que des versions spécifiques du logiciel.
Les SBOM sont généralement formatés d’une manière spécifique et peuvent généralement être représentés sous forme de fichiers XML ou JSON. Cela dit, la nature exacte d’un SBOM varie en fonction de la norme SBOM – telle que CycloneDX, SPDX ou SWID – que les équipes choisissent pour enregistrer et structurer les informations SBOM. Cependant, malgré des différences mineures, tous les formats SBOM se concentrent sur la facilité de déterminer en un coup d’œil ce qui « entre » dans chaque application utilisée par une entreprise.
Pourquoi les SBOM sont-ils importants ?
Les SBOM sont le seul moyen de suivre systématiquement les composants et les dépendances d’une application. Par extension, ils fournissent les informations nécessaires pour déterminer si des composants ou des dépendances sont exposés à des risques de sécurité.
Les SBOM sont également importants car, dans certains cas, ils peuvent être exigés par les organismes de réglementation ou les clients. Par exemple, en 2021, le gouvernement fédéral américain a annoncé son intention d’exiger des SBOM des fournisseurs qui font affaire avec des agences gouvernementales, dans le cadre d’un effort visant à garantir que les agences aient une certaine visibilité sur les logiciels dont elles dépendent.
De plus, même si les SBOM ne sont pas strictement requis par vos clients, partenaires ou régulateurs, les générer est un excellent moyen de montrer que vous prenez la sécurité de la chaîne d’approvisionnement logicielle au sérieux. Les SBOM offrent aux parties prenantes externes la tranquillité de disposer de plus de visibilité sur les composants logiciels et les dépendances et la capacité de déterminer si les logiciels tiers les exposent à des risques.
SBOM vs gestion manuelle des composants logiciels
Vous pouvez, bien sûr, essayer de suivre manuellement les composants et les dépendances en demandant aux développeurs de les répertorier sur demande ou en essayant de suivre ces informations de manière informelle dans la documentation. Cependant, les problèmes de cette approche sont les suivants :
- Ce n’est pas systématique : Il est facile d’oublier de noter une dépendance ou un composant important lorsque vous n’avez pas de processus systématique pour définir et formater ces informations.
- Le partager est difficile : Les données informelles sur les composants logiciels sont difficiles à partager avec les régulateurs, les auditeurs, les partenaires et les clients, car ces derniers peuvent ne pas avoir accès aux emplacements où vous stockez les informations. Ils peuvent également ne pas savoir comment les interpréter.
Les SBOM résolvent ces deux problèmes en fournissant un moyen systématique et standardisé de définir ce qui entre dans chaque application utilisée par votre entreprise. Lorsque vous faites de la génération SBOM un élément standard de votre processus de livraison d’applications, vous minimisez le risque d’oublier de noter les informations importantes de la chaîne d’approvisionnement logicielle. Vous rendez également les informations facilement partageables avec toute partie prenante qui a besoin d’y accéder.
Exemple de SBOM
Un SBOM est composé d’une liste des différents composants open source et propriétaires qui existent dans un logiciel. Comme indiqué ci-dessus, les listes sont généralement structurées à l’aide de XML ou JSON, ce qui permet de diviser le SBOM en différentes sections et de définir non seulement les composants de l’application, mais également les métadonnées qui leur sont associées.
Par exemple, voici un fichier SBOM simple au format JSON conforme à la norme SBOM CycloneDX :
{
« $schema » : « http://cyclonedx.org/schema/bom-1.2a.schema.json »,
« bomFormat » : « CycloneDX »,
« specVersion » : « 1.2 »,
« version » : 1,
« metadata » : {
« tools » : [
{
« vendor » : « cyclonedx »,
« name » : « cyclonedx-php-composer »,
« version » : « dev-master »
}
],
« component » : {
« bom-ref » : « pkg:composer/cyclonedx/cyclonedx-php-composer-demo@dev-master »,
« type » : « application »,
« name » : « cyclonedx-php-composer-demo »,
« version » : « dev-master »,
« group » : « cyclonedx »,
« description » : « demo of cyclonedx/cyclonedx-php-composer with a pinned version of laravel/framework »,
« purl » : « pkg:composer/cyclonedx/cyclonedx-php-composer-demo@dev-master »
}
},
« components » : [
{
« bom-ref » : « pkg:composer/asm89/stack-cors@1.3.0 »,
« type » : « library »,
« name » : « stack-cors »,
« version » : « 1.3.0 »,
« group » : « asm89 »,
« description » : « Cross-origin resource sharing library and stack middleware »,
« licenses » : [
{
« license » : {
« id » : « MIT »
}
}
],
« purl » : « pkg:composer/asm89/stack-cors@1.3.0 »,
« externalReferences » : [
{
« type » : « distribution »,
« url » : « https://github.com/asm89/stack-cors.git »,
« comment » : « Tel que détecté par 'getSourceUrls()' du compositeur (type=git & reference=b9c31def6a83f84b4d4a40d35996d375755f0e08) »
},
{
« type » : « distribution »,
« url » : « https://api.github.com/repos/asm89/stack-cors/zipball/b9c31def6a83f84b4d4a40d35996d375755f0e08 »,
« comment » : « Tel que détecté par 'getDistUrls()' du compositeur (type=zip & reference=b9c31def6a83f84b4d4a40d35996d375755f0e08 & sha1=UNDEFINED) »
},
{
« type » : « website »,
« url » : « https://github.com/asm89/stack-cors »,
« comment » : « Comme défini via 'homepage' dans la définition du package du compositeur. »
},
{
« type » : « issue-tracker »,
« url » : « https://github.com/asm89/stack-cors/issues »,
« comment » : « Comme défini via 'support.issues' dans la définition du package du compositeur. »
},
{
« type » : « distribution »,
« url » : « https://github.com/asm89/stack-cors/tree/1.3.0 »,
« comment » : « Comme défini via 'support.source' dans la définition du package du compositeur. »
}
]
},
]
}
La première strophe principale de ce SBOM définit les métadonnées associées au SBOM lui-même, telles que la norme SBOM et le formatage utilisé. Ensuite, le SBOM comprend une section « components » : où se trouve l'élément « meat » du SBOM. La section des composants répertorie les packages spécifiques inclus dans l’application en question, ainsi que les données connexes telles que les URL des packages, les sites Web, les informations de licence et même l’emplacement des outils de suivi des problèmes.
En utilisant ces informations, les développeurs, les ingénieurs informatiques, les équipes de sécurité, les équipes DevOps et les équipes DevSecOps sont en mesure de déterminer non seulement les dépendances et les composants existants dans le logiciel auquel le SBOM s’applique, mais aussi d’où proviennent ces composants et où ils peuvent trouver plus d’informations à leur sujet.
Outils SBOM
Vous pouvez lire manuellement un SBOM pour trouver cette information. Ou, vous pouvez utiliser les différents outils qui permettent d'analyser et de visualiser les fichiers SBOM. Notez cependant que la plupart des outils SBOM sont conçus pour fonctionner uniquement avec une norme SBOM spécifique, vous devez donc vous assurer de choisir des outils compatibles avec les normes et le formatage de votre SBOM. Par exemple, si vous voulez des outils compatibles avec CycloneDX, vous trouverez la liste des options open source et propriétaires disponibles sur le site Web CycloneDX.
Outils SBOM et comment générer un SBOM
Le moyen le plus efficace de générer un SBOM est de tirer parti des outils SBOM qui suivent automatiquement les composants et les dépendances de chaque application, ainsi que leurs versions, puis de signaler ces informations dans un format SBOM standardisé, tel que CyloneDX, SPDX ou SWID.
À l’aide des outils SBOM, vous pouvez faire de la génération SBOM une tâche automatisée de votre processus CI/CD. Les outils SBOM peuvent analyser automatiquement chaque nouvelle version ou package d’application pour déterminer si les composants de l’application ont changé, garantissant ainsi que vos SBOM sont continuellement mis à jour.
Pour plus de conseils sur la création et l’utilisation des SBOM, consultez notre article sur les meilleures pratiques de gestion des SBOM.
