Una SBOM (Lista de materiales de software) lo ayuda a comprender su cadena de suministro de software al enumerar los paquetes y proveedores de los que depende su código. Los SBOM están cobrando impulso rápidamente como una forma de ayudar a mejorar la seguridad a raíz de los prominentes ataques a la cadena de suministro en el mundo real.
Uno de los principales defensores de los SBOM es Microsoft, que publicó su enfoque para su generación. en octubre de 2021. A principios de este año, la empresa su herramienta de código abierto para producir SBOM en Windows, macOS y Linux.
En este artículo, aprenderá cómo comenzar a usar el proyecto para indexar las dependencias de su código. Produce documentos compatibles con SPDX que enumeran los archivos, paquetes y relaciones dentro de su proyecto. SPDX (Software Package Data Exchange) es el estándar aceptado por ISO para SBOM, por lo que puede pasar los informes generados directamente a otras herramientas del ecosistema.
Microsoft anunció originalmente el proyecto bajo el nombre de Salus. es desde se retiró de este término porque entra en conflicto con lo existente. Proyecto de seguridad del código Salus que se originó en Coinbase. El generador SBOM ahora se conoce simplemente como sbom-tool.
Empezando
Puede descargar la herramienta SBOM de Microsoft’s repositorio GitHub. Los binarios precompilados están disponibles en la página de lanzamientos. Seleccione la descarga correcta para su sistema, luego haga que el binario sea ejecutable y muévalo a una ubicación en su camino.
Aquí hay un ejemplo para 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
Deberías poder correr sbom-tool para mostrar la información de ayuda en la ventana de su terminal:
$ sbom-tool No action was specified The Sbom tool generates a SBOM for any build artifact. Usage - Microsoft.Sbom.Tool <action> -options
Generación de un SBOM
Los nuevos SBOM se crean ejecutando la herramienta generate subcomando. Es necesario proporcionar algunos argumentos:
-b(BuildDropPath): la carpeta para guardar los manifiestos SPDX SBOM generados.-bc(BuildComponentPath) – La carpeta que será escaneada para encontrar las dependencias en su proyecto.-nsb(NamespaceUriBase): la ruta base que se utilizará como espacio de nombres del manifiesto SBOM. Esta debe ser una URL que sea propiedad de su organización, comohttps://example.com/sbom.
SBOM Tool también necesita saber el nombre y la versión de su proyecto. A menudo puede inferir esto de los archivos que ya están en su repositorio, como el package.json name y version campos, pero es posible que deba proporcionar la información manualmente o anular los valores predeterminados en algunos casos. Añade el pn y pv banderas para hacer esto:
-pn(PackageName) – El nombre de su proyecto o paquete.-pv(PackageVersion) – La versión del proyecto que está escaneando. Esto debería coincidir con la versión de lanzamiento que acompaña a su SBOM para que los usuarios puedan correlacionar las listas de dependencia con compilaciones específicas.
Aquí hay un ejemplo de cómo generar un SBOM para los archivos en su directorio de trabajo. El SBOM se colocará en el sbom-output subdirectorio. Esto debe existir antes de ejecutar la herramienta.
$ mkdir sbom-output $ sbom-tool generate -b sbom-output -bc . -pn example -pv 1.0 -nsb https://example.com/sbom
Se mostrará una descripción general de los resultados del escaneo en su 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.
Este proyecto usa npm para administrar sus dependencias. La herramienta detectó 241 paquetes dentro del directorio de trabajo package.json expediente.
SBOM Tool actualmente admite 19 lenguajes de programación y formatos de paquete diferentes. los la lista incluye npm, NuGet, PyPi, Maven, Rust Crates y Ruby gems, así como paquetes de Linux presentes en las imágenes de Docker. También se admiten referencias a repositorios remotos de GitHub.
Contenidos de la SBOM
El SBOM generado se escribirá en _manifest/spdx_2.2/manifest.spdx.json dentro del directorio de salida de compilación que especificó. El SBOM es un archivo JSON bastante detallado que está destinado a ser consumido por otro software.
{ "archivos": []"paquetes": [
{
"name": "color-convert",
"SPDXID": "SPDXRef-Package-A72B0922E46D9828746F346D7FD11B7F81EDEB15B92BEEDAE087F5F7407FECDC",
...
}
There are four main types of information within the report:
- The
filessection – 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
packagessection – 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
relationshipssection – This details all the relationships between the components listed in the SBOM. The most common relationship you’ll see isDEPENDS_ON, which declares an item in thepackagessection as one of your project’s dependencies. Several other kinds of relationship also exist, such asCREATED_BY,DEPENDENCY_OF, andPATCH_FOR. - Report metadata details – Fields such as
name,documentNamespace,spdxVersion, andcreationInfoidentify 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.
