Une SBOM (Software Bill of Materials) vous aide à comprendre votre chaîne d’approvisionnement logicielle en répertoriant les packages et les fournisseurs sur lesquels repose votre code. Les SBOM gagnent rapidement du terrain en tant que moyen d’aider à améliorer la sécurité à la suite d’importantes attaques de la chaîne d’approvisionnement dans le monde réel.

L’un des principaux partisans des SBOM est Microsoft, qui a publié son approche de leur génération de retour en octobre 2021. Plus tôt cette année, la société open source son outil pour produire des SBOM sous Windows, macOS et Linux.

Dans cet article, vous apprendrez comment commencer à utiliser le projet pour indexer les dépendances de votre code. Il produit des documents compatibles SPDX qui répertorient les fichiers, les packages et les relations au sein de votre projet. SPDX (Software Package Data Exchange) est la norme acceptée par l’ISO pour les SBOM afin que vous puissiez transmettre les rapports générés directement dans d’autres outils de l’écosystème.

Microsoft a initialement annoncé le projet sous le nom de Salus. C’est depuis s’est retiré de ce terme parce qu’il est en conflit avec l’existant Projet de sécurité du code Salus qui est originaire de Coinbase. Le générateur SBOM est maintenant appelé simplement sbom-tool.

Commencer

Vous pouvez télécharger SBOM Tool à partir de Microsoft Référentiel GitHub. Des binaires précompilés sont disponibles sur la page des sorties. Sélectionnez le bon téléchargement pour votre système, puis rendez le binaire exécutable et déplacez-le vers un emplacement de votre chemin.

Voici un exemple pour Linux :

$ wget https://github.com/microsoft/sbom-tool/releases/download/v<VERSION>/sbom-tool-linux-x64
$ chmod +x sbom-tool-linux-x64
$ mv sbom-tool-linux-x64 /usr/local/bin/sbom-tool

Tu devrais pouvoir courir sbom-tool pour afficher les informations d’aide dans la fenêtre de votre terminal :

$ sbom-tool
No action was specified

The Sbom tool generates a SBOM for any build artifact.

Usage - Microsoft.Sbom.Tool <action> -options

Génération d’un SBOM

De nouveaux SBOM sont créés en exécutant l’outil generate sous-commande. Quelques arguments sont à fournir :

-b (BuildDropPath) – Le dossier dans lequel enregistrer les manifestes SPDX SBOM générés.
-bc (BuildComponentPath) – Le dossier qui sera analysé pour trouver les dépendances dans votre projet.
-nsb (NamespaceUriBase) – Le chemin de base qui sera utilisé comme espace de noms du manifeste SBOM. Il doit s’agir d’une URL appartenant à votre organisation, telle que https://example.com/sbom.

SBOM Tool doit également connaître le nom et la version de votre projet. Il peut souvent déduire cela à partir de fichiers déjà dans votre référentiel, tels que le package.json name et version champs, mais vous devrez peut-être fournir les informations manuellement ou remplacer les valeurs par défaut dans certains cas. Ajouter le pn et pv drapeaux pour faire ceci:

-pn (PackageName) – Le nom de votre projet ou package.
-pv (PackageVersion) – La version du projet que vous numérisez. Cela doit correspondre à la version fournie par votre SBOM afin que les utilisateurs puissent corréler les listes de dépendances avec des builds spécifiques.

Voici un exemple de génération d’un SBOM pour les fichiers de votre répertoire de travail. Le SBOM sera placé dans le sbom-output sous-répertoire. Cela doit exister avant que vous n’exécutiez l’outil.

$ mkdir sbom-output
$ sbom-tool generate -b sbom-output -bc . -pn example -pv 1.0 -nsb https://example.com/sbom

Un aperçu des résultats de l’analyse s’affichera dans votre terminal :

[INFO] Enumerated 3728 files and 607 directories in 00:00:00.5938034 

[INFO] |Component Detector Id         |Detection Time                |# Components Found            |# Explicitly Referenced                 | 
...
[INFO] |Npm                           |0.63 seconds                  |241                           |0                                       | 
...
[INFO] |Total                         |0.64 seconds                  |241                           |0                                       | 

[INFO] Detection time: 0.6374678 seconds.

Ce projet utilise npm pour gérer ses dépendances. L’outil a détecté 241 packages dans le répertoire de travail package.json dossier.

SBOM Tool prend actuellement en charge 19 langages de programmation et formats de packages différents. La la liste comprend npm, NuGet, PyPi, Maven, Rust Crates et Ruby gems, ainsi que les packages Linux présents dans les images Docker. Les références aux référentiels GitHub distants sont également prises en charge.

Contenu de la SBOM

Le SBOM généré sera écrit dans _manifest/spdx_2.2/manifest.spdx.json dans le répertoire de sortie de construction que vous avez spécifié. Le SBOM est un fichier JSON assez verbeux destiné à être utilisé par d’autres logiciels.

{  "des dossiers": []"paquets": [
    
      "name": "color-convert",
      "SPDXID": "SPDXRef-Package-A72B0922E46D9828746F346D7FD11B7F81EDEB15B92BEEDAE087F5F7407FECDC",
      ...

There are four main types of information within the report:

The files section – This lists all the files containing source code you’ve written in your project. SBOM Tool will only populate this section when certain project types are scanned, such as C# solutions.
The packages section – A complete catalog of all the third-party dependencies present in your project, with references to their source package manager, the version used, and the type of license that applies.
The relationships section – This details all the relationships between the components listed in the SBOM. The most common relationship you’ll see is DEPENDS_ON, which declares an item in the packages section as one of your project’s dependencies. Several other kinds of relationship also exist, such as CREATED_BY, DEPENDENCY_OF, and PATCH_FOR.
Report metadata details – Fields such as name, documentNamespace, spdxVersion, and creationInfo identify the SBOM, the tool used to create it, and the SPDX manifest revision that applies.

Now you’ve got an SBOM you can start using it with other tools to conduct vulnerability scans and manage license compliance. You can consider distributing the SBOM with your software releases so consumers are able to inspect the contents of each new version. SBOMs are best generated as part of your build pipeline so they stay up to date.

Having access to an SBOM is invaluable when major new supply chain problems appear. Organizations using SBOMs were better placed to respond to Log4j, for example. They could inspect their reports to quickly find projects depending on the vulnerable library, instead of auditing package lists by hand.

Scanning Docker Images

SBOM Tool is capable of scanning existing Docker images as part of a report generation. To use this capability, you need to add the -di flag and specify the image tag or digest that you want to scan. The rest of the arguments stay the same.

$ sbom-tool generate -di ubuntu:latest -b sbom-output -bc . -pn demo -pv 1.0 -nsb https://demo.com/demo

The Docker image will be analyzed to identify the packages it includes. They’ll be added to the SBOM report alongside the dependencies found in your source folder. You can scan multiple Docker images in a single operation by separating their tags or digest hashes with commas.

Summary

SBOM Tool is a young open-source SBOM generation utility developed at Microsoft. It supports several leading package formats and produces SPDX-compatible output. This means you can feed generated SBOMs straight into other tools like Grype to automatically find security vulnerabilities and outdated dependencies.

SBOMs are an effective way to increase awareness of software supply chains and uncover lurking issues. Producing and distributing an SBOM helps users understand what’s being silently included in their project. SBOM Tool is one way to generate industry-standard reports with a single command, making it easier to offer an SBOM with each of your releases.

Vous pouvez lire l’article original (en Angais) sur le blogwww.howtogeek.com