SBOM
¿Qué es una SBOM?
Una SBOM, o lista de materiales de software (software bill of materials), es una lista legible por máquina de los componentes que hay dentro de un software: cada biblioteca, paquete y dependencia, con su versión, su productor y su licencia. Es para el software lo que la lista de ingredientes para los alimentos. Cuando se publica una nueva vulnerabilidad, una SBOM le indica en minutos si distribuye el componente afectado.
Actualizado el
¿Qué significa SBOM?
SBOM son las siglas de software bill of materials, lista de materiales de software. El término procede de la fabricación, donde una lista de materiales enumera las piezas que forman un producto. CISA describe una SBOM como un inventario anidado, una lista de los ingredientes que forman los componentes de software.
La mayor parte del código de una aplicación moderna la escribió otra persona, y casi todo ese código llega de forma indirecta: usted añade un paquete y este trae consigo decenas de dependencias transitivas. Una SBOM lo deja todo por escrito, de modo que puede responder a «¿nos afecta?» sin leer ni un solo repositorio.
¿Qué contiene una SBOM?
Una SBOM útil tiene dos partes: datos sobre la propia SBOM y datos sobre cada componente. Los 2026 Minimum Elements, publicados por CISA, la NSA y el FBI con socios internacionales el 29 de julio de 2026, sustituyen a la lista de la NTIA de 2021 y fijan la referencia que hoy cita la mayoría de los compradores.
| Parte | Campos |
|---|---|
| Sobre la SBOM | Autor y firma del autor, marca de tiempo, nombre y versión del formato de datos, nombre y versión de la herramienta, versión de la SBOM y contexto de generación |
| Sobre cada componente | Nombre, versión, productor, identificadores como una package URL, valor y algoritmo de hash, licencia y relaciones de dependencia |
El contexto de generación importa más de lo que parece. Indica cuándo se creó la SBOM: antes del build, durante el build, a partir del artefacto terminado o después. Dos SBOM de la misma versión pueden diferir precisamente por eso. Consulte ejemplos de SBOM para ver cómo son estos campos en un archivo real.
Formatos de SBOM
Dos formatos cubren casi todas las SBOM en uso. CycloneDX, de OWASP, nació en el ámbito de la seguridad y también describe vulnerabilidades y servicios. SPDX, de la Linux Foundation, nació en el cumplimiento de licencias. Ambos pueden incluir los elementos mínimos, y la mayoría de las herramientas genera los dos. Consulte CycloneDX frente a SPDX para saber cuál elegir.
Por qué importan las SBOM
- Respuesta a incidentes más rápida. Cuando aparece una vulnerabilidad como Log4Shell, la pregunta es cuáles de sus productos la contienen. Con SBOM, eso es una búsqueda. Sin ellas, es un proyecto.
- Monitorización de vulnerabilidades después del lanzamiento. El software que estaba limpio cuando se distribuyó puede ser vulnerable mañana. Volver a comprobar las SBOM almacenadas frente a nuevos avisos lo detecta sin recompilar nada.
- Riesgo de licencias. La licencia declarada de cada componente muestra las condiciones copyleft o comerciales antes de que lleguen al producto.
- Preguntas de clientes y reguladores. Los compradores piden cada vez más una SBOM en los procesos de compra, y varios marcos esperan un inventario de componentes.
¿Quién necesita una SBOM?
Cualquiera que distribuya software y cualquiera que tenga que responder de lo que contiene. El requisito suele llegar por una de estas vías:
- Dispositivos médicos. La sección 524B de la FDA exige una SBOM para los ciberdispositivos en las solicitudes previas a la comercialización.
- Productos vendidos en la UE. El Cyber Resilience Act pide a los fabricantes una SBOM. Consulte requisitos de SBOM y herramientas para el CRA.
- Compras del Gobierno federal de EE. UU. El memorando M-26-05 de la OMB de enero de 2026 permite que cada agencia decida si la exige, así que cuente con que se decidirá caso por caso.
- Software de pagos. El requisito 6.3.2 de PCI DSS 4.0 pide un inventario del software a medida y de sus componentes de terceros. No prescribe una SBOM, pero una SBOM cubre esa necesidad.
Cómo generar una SBOM
Hay tres formas de crearla, y el método determina lo que acaba en el archivo.
| Método | Qué lee | Carencia habitual |
|---|---|---|
| Escanear el código fuente | Manifiestos y lockfiles del repositorio | Todo lo que el build descarga y ningún lockfile enumera |
| Escanear el resultado | Una imagen de contenedor o un binario terminados | El código compilado es ambiguo, y las herramientas de build no dejan rastro |
| Registrar el build | Lo que el build descargó realmente mientras se ejecutaba | El tráfico que elude el registrador, que debería señalarse |
Los generadores de código abierto como Syft, Trivy y cdxgen utilizan los dos primeros métodos. No coinciden entre sí con un mismo commit, porque cada uno tiene sus propias reglas sobre qué leer. Para ver las opciones lado a lado, consulte las mejores herramientas de SBOM.
SBOM frente a SCA y VEX
- Una SBOM es un inventario. Dice lo que hay, no si es seguro.
- El análisis de composición de software es el análisis. Encuentra los componentes y comprueba sus riesgos, y muchas herramientas de SCA generan una SBOM por el camino.
- VEX es una declaración sobre el impacto. Indica si una vulnerabilidad conocida afecta realmente a su producto, lo que reduce el ruido que genera una SBOM por sí sola.
Generar una SBOM es la parte fácil
Un archivo que nadie lee no cambia nada. El valor está en conservar una SBOM por versión, monitorizarlas y poder encontrarlas cuando hacen falta. Ese trabajo es la gestión de SBOM, y buenas prácticas de SBOM explica cómo llevarlo a cabo.
Cómo crea CRACI las SBOM
CRACI es un runner de GitHub Actions que registra cada paquete que descarga cada job, a cualquier profundidad del árbol e incluidos los paquetes restaurados desde cachés de CI. El resultado es una SBOM del build que generó la versión, con un estado de completitud que indica lo que el job no pudo ver. Se exporta en CycloneDX o SPDX, y CRACI sigue reevaluándola a medida que se publican nuevas vulnerabilidades. Consulte generación de SBOM durante el build.
SBOM: preguntas frecuentes
¿Qué es una SBOM en palabras sencillas?
Una SBOM es una lista de ingredientes para el software. Nombra cada componente de un producto, con su versión, su productor y su licencia, en un formato que las máquinas pueden leer.
¿Qué significa SBOM?
SBOM son las siglas de software bill of materials, lista de materiales de software.
¿Por qué necesita una SBOM?
Para saber rápidamente si una vulnerabilidad recién publicada afecta a lo que distribuye, ver el riesgo de licencias antes del lanzamiento y responder a los clientes y reguladores que preguntan qué contiene su producto.
¿Cuáles son los dos principales formatos de SBOM?
CycloneDX y SPDX. CycloneDX procede de OWASP y nació en el ámbito de la seguridad. SPDX procede de la Linux Foundation y nació en el cumplimiento de licencias. Ambos pueden incluir los elementos mínimos.
¿Exige la ley una SBOM?
Depende del producto y del mercado. La sección 524B de la FDA la exige para los ciberdispositivos, y el Cyber Resilience Act de la UE la pide a los fabricantes. En las compras del Gobierno federal de EE. UU., ahora lo decide cada agencia. Para muchas otras empresas es un requisito de los clientes más que un requisito legal.
¿Con qué frecuencia debe actualizarse una SBOM?
Genere una nueva SBOM para cada versión, porque cada build puede descargar versiones distintas. La SBOM de una versión no cambia después, pero debe seguir cotejándola con las nuevas vulnerabilidades.
¿Quién crea la SBOM?
Normalmente, el equipo que compila el software, idealmente en CI para que cada versión obtenga una de forma automática. El software que usted compra debería incluir una SBOM de su proveedor.
Vea la SBOM de su build real
Ejecute un workflow de GitHub Actions en CRACI y compare su SBOM registrada con lo que indican sus herramientas actuales.
Reservar una demo