Un SBOM (software bill of materials) es un inventario, legible por máquina, de todo aquello con lo que está construido tu software: las librerías open source y comerciales, sus versiones exactas, quién las provee y cómo dependen unas de otras. CISA lo resume así: un SBOM es "un inventario anidado, una lista de ingredientes de los componentes del software".
Suena a burocracia, y durante años se lo trató así. Hasta que un par de incidentes grandes de cadena de suministro hicieron carísima una pregunta muy simple: "¿Estamos usando la versión vulnerable de esta librería? ¿Dónde?" El SBOM es el archivo que te deja responder eso en minutos y no en semanas. En esta guía vemos qué lleva adentro, por qué los reguladores lo empezaron a pedir, los dos formatos principales (CycloneDX vs SPDX), cómo generarlo y, tan importante como lo anterior, qué cosas un SBOM no hace.
Qué es un SBOM, exactamente
Pensá en la etiqueta de un paquete de comida. Te dice los ingredientes, no si cada uno te hace bien. El SBOM hace lo mismo con el software. Para cada componente registra como mínimo nombre, versión e identificador, y además las relaciones entre componentes: tu app depende de un framework web, que depende de una librería de logging, que a su vez depende de otra cosa tres niveles más abajo.
En julio de 2021 la NTIA de Estados Unidos publicó "The Minimum Elements For a Software Bill of Materials". Sus campos base siguen siendo el mejor modelo mental de lo que tiene que tener un SBOM:
- Proveedor (supplier name): quién creó o mantiene el componente.
- Nombre del componente y versión.
- Otros identificadores únicos, como un Package URL (purl) del tipo
pkg:npm/[email protected]o un CPE. - Relación de dependencia: qué componente incluye a cuál.
- Autor de los datos del SBOM y un timestamp.
Desde entonces CISA viene trabajando en una actualización de esos elementos mínimos, pero la idea de fondo es la misma: identificar cada componente con la precisión suficiente para que una máquina lo pueda cruzar contra una base de vulnerabilidades o una lista de licencias.
Dependencias directas y transitivas
Tu package.json o tu requirements.txt tiene, digamos, 30 dependencias directas. El lockfile suele tener cientos, porque cada una trae las suyas. Un SBOM útil captura el árbol completo, porque a una vulnerabilidad no le importa si importaste el paquete a propósito o no. Así se ve un solo componente en un SBOM CycloneDX en JSON:
{
"type": "library",
"name": "log4j-core",
"version": "2.14.1",
"purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
"licenses": [{ "license": { "id": "Apache-2.0" } }]
}Por qué el SBOM importa hoy
Ataques a la cadena de suministro y el "¿dónde nos pega?"
Cuando se publicó Log4Shell (CVE-2021-44228) en diciembre de 2021, a la mayoría de los equipos no les costó entender el bug. Les costó encontrarlo. Log4j muchas veces era una dependencia transitiva escondida dentro de otra librería, dentro de una imagen de contenedor, dentro de un servicio que nadie tocaba hacía un año. Las organizaciones con un inventario al día lo pudieron buscar. El resto hizo grep en los repos y le pidió a cada equipo que revisara a mano.
Ese es el valor central de un SBOM: convierte "¿estamos afectados?" de una investigación en una consulta. La misma lógica aplica a paquetes maliciosos, typosquatting y maintainers comprometidos. No podés reaccionar ante un riesgo en un componente que no sabés que estás distribuyendo. Por eso el SBOM va de la mano del software composition analysis en cualquier programa serio de DevSecOps.
Executive Order 14028 en Estados Unidos
El 12 de mayo de 2021 el gobierno de Estados Unidos emitió la Executive Order 14028, "Improving the Nation's Cybersecurity". Uno de sus objetivos era mejorar la seguridad de la cadena de suministro de software, y le ordenó a la NTIA publicar los elementos mínimos de un SBOM, cosa que la NTIA hizo el 12 de julio de 2021. En la práctica, el SBOM pasó de ser una buena práctica de nicho a algo que los compradores federales empezaron a pedirle a los proveedores de software.
Cyber Resilience Act de la Unión Europea
El Cyber Resilience Act (CRA) entró en vigor el 10 de diciembre de 2024. Las obligaciones de reporte de vulnerabilidades explotadas activamente aplican desde el 11 de septiembre de 2026, y las obligaciones principales desde el 11 de diciembre de 2027. El Anexo I, Parte II, exige a los fabricantes identificar y documentar los componentes de sus productos, incluso elaborando un SBOM en un formato de uso común y legible por máquina que cubra como mínimo las dependencias de primer nivel. Si vendés software o productos conectados en la UE, el SBOM se está volviendo parte del producto, no un extra.
Formatos de SBOM: CycloneDX vs SPDX
Hay dos formatos abiertos que dominan. Los dos son legibles por máquina, los dos tienen buen soporte, y para la mayoría de los equipos la elección importa menos que generar el SBOM. Igual vienen de lugares distintos.
SPDX
SPDX (Software Package Data Exchange) es un proyecto open source alojado en la Linux Foundation. Nació para el cumplimiento de licencias, y por eso incluye la SPDX License List y la sintaxis de expresiones de licencia que hoy usa casi todo el ecosistema (MIT, Apache-2.0, GPL-3.0-or-later). La especificación está reconocida como ISO/IEC 5962:2021. SPDX 3.0, publicado en abril de 2024, sumó perfiles de Security, Build, Dataset y AI.
CycloneDX
CycloneDX lo impulsan la OWASP Foundation y el comité técnico TC54 de Ecma International, y está estandarizado como ECMA-424. Se diseñó con la seguridad como caso de uso principal. Además del SBOM cubre SaaSBOM, CBOM (criptografía), HBOM (hardware), AI/ML-BOM y VEX (Vulnerability Exploitability eXchange), que sirve para declarar si una vulnerabilidad conocida afecta o no a tu producto.
| Dimensión | SPDX | CycloneDX |
|---|---|---|
| Quién lo mantiene | Linux Foundation | OWASP y Ecma TC54 |
| Estándar formal | ISO/IEC 5962:2021 | ECMA-424 |
| Origen | Cumplimiento de licencias | Seguridad de aplicaciones |
| Fortalezas | Datos de licencias, revisión legal, ecosistema amplio | Gestión de vulnerabilidades, VEX, otros tipos de BOM |
| Nombres de archivo típicos | *.spdx.json | bom.json, *.cdx.json |
Regla práctica: si quien lo consume es legales o compras, SPDX encaja natural. Si quien lo consume es un pipeline de gestión de vulnerabilidades, CycloneDX suele encajar mejor. Si un cliente o un regulador te pide un formato puntual, usá ese. Herramientas como Syft generan los dos desde el mismo escaneo.
Cómo generar un SBOM
Syft
Syft, de Anchore, es un CLI que genera SBOMs a partir de imágenes de contenedor, filesystems y archivos comprimidos, y soporta decenas de ecosistemas (npm, PyPI, Maven, Go, Cargo, Alpine, Debian, RPM y más):
# SBOM de un directorio de código, en CycloneDX JSON
syft ./mi-proyecto -o cyclonedx-json=./bom.cdx.json
# SBOM de una imagen, en los dos formatos a la vez
syft mi-app:1.4.2 -o spdx-json=./sbom.spdx.json -o cyclonedx-json=./bom.cdx.jsoncdxgen
cdxgen es un proyecto de la OWASP Foundation que genera BOMs CycloneDX desde rutas locales, repos git, purls e imágenes de contenedor, y también puede exportar SPDX 3.0.1 en JSON-LD:
cdxgen -o bom.json .Export del dependency graph de GitHub
Si tu código está en GitHub, podés exportar el dependency graph actual de un repo como archivo SPDX 2.3: entrá al repo, andá a Insights, después a Dependency graph y hacé clic en Export SBOM. También hay un endpoint de la REST API para el mismo export, útil si lo querés automatizar. Tené en cuenta que refleja lo que el dependency graph sabe a partir de tus manifests y lockfiles, no lo que termina dentro del contenedor que construís.
SBOM de código vs SBOM de build
Dónde generás el SBOM cambia lo que contiene. Un SBOM de código, armado desde los lockfiles, te dice lo que tu aplicación declara. Un SBOM de build o de imagen, armado desde el artefacto final, incluye además los paquetes del sistema operativo de la imagen base y cualquier cosa que se copie durante el build. Para un servicio desplegado, el SBOM de la imagen está más cerca de la realidad. Lo recomendable es generarlo en CI en cada release y guardarlo junto al artefacto, así cada versión que sale tiene su inventario.
Cómo usar un SBOM
Cruce con vulnerabilidades (CVE y OSV)
El SBOM se vuelve útil cuando lo cruzás con datos de vulnerabilidades. Dos opciones open source leen archivos SBOM directamente:
# Grype: escanear un SBOM existente
grype sbom:./bom.cdx.json
# OSV-Scanner: cruzar un SBOM con la base OSV
osv-scanner scan source -L ./sbom.spdx.jsonOSV-Scanner reconoce los SBOMs por nombre de archivo, así que respetá las convenciones (*.spdx.json, bom.json, *.cdx.json). Como guardaste un SBOM por release, podés volver a escanear versiones viejas cuando aparece un CVE nuevo, sin recompilar nada. Esa es la ganancia de pasar de investigación a consulta.
Licencias
Cada componente puede llevar un identificador de licencia SPDX. Los equipos legales lo usan para detectar licencias copyleft dentro de un producto propietario, componentes sin licencia o términos que chocan con la forma en que distribuís tu software.
Pedidos de clientes y reguladores
Cada vez más cuestionarios de seguridad piden un SBOM, y el CRA lo va a exigir como parte de la documentación técnica. Si acompañás el SBOM con declaraciones VEX, le podés decir a un cliente "sí, ese CVE está en un componente que distribuimos, pero la función vulnerable no es alcanzable en nuestro producto" de forma estructurada, en lugar de un hilo de mails eterno.
Los límites de un SBOM
- Es una foto. Un SBOM describe un build en un momento dado. Todos los días se publican CVEs nuevos contra componentes que ayer estaban limpios, así que el valor está en volver a cruzarlo, no en el archivo en sí.
- Es tan bueno como el generador. Código vendorizado, snippets copiados, binarios linkeados estáticamente y pasos de build a medida se escapan fácil. Dos herramientas pueden dar SBOMs distintos para el mismo proyecto.
- No dice nada sobre explotabilidad. Que figure una versión vulnerable no significa que tu código llame a la función vulnerable. Sin análisis de alcanzabilidad o VEX, el equipo se ahoga en hallazgos que no importan.
- No cubre tu propio código. Inyecciones, control de acceso roto y el resto del OWASP Top 10 viven en el código que escribiste vos, y para eso necesitás AI SAST u otro análisis estático (mirá SAST vs DAST).
- No cubre secretos ni configuración. Una API key filtrada o un workflow de CI con permisos de más nunca van a aparecer en un bill of materials. Eso es trabajo de las herramientas de detección de secretos, como un secret scanner que también revise el historial de git, y de los chequeos de configuración.
Dónde entra Nurbak
Para ser claros con el alcance: Nurbak no genera ni exporta archivos SBOM. Si necesitás un SBOM para un cliente o para la documentación del CRA, usá Syft, cdxgen o el export de GitHub que vimos arriba.
Lo que sí hace Nurbak es la parte que muchos equipos querían del SBOM desde el principio: conectás GitHub, escaneás un repo, y lee tus lockfiles, cruza cada dependencia con las vulnerabilidades conocidas de OSV y te reporta los paquetes vulnerables junto con la versión corregida a la que tenés que actualizar. En el mismo escaneo, su propio modelo de IA self-hosted analiza tu código en busca de vulnerabilidades explotables con archivo y línea (el análisis no manda tu código a OpenAI ni a Anthropic), marca misconfigs de GitHub Actions, Docker, Terraform y Kubernetes y detecta secretos en el código actual y en el historial de git, todo resumido en un score de 0 a 100. El escaneo gratis te muestra completos los 3 hallazgos más importantes. Mirá cómo funciona la parte de dependencias en la página de software composition analysis, o corré el GitHub security scanner completo.
En resumen
Un SBOM es la lista de ingredientes de tu software. No hace seguro a tu producto por sí solo, pero vuelve respondible en minutos la pregunta más común de la cadena de suministro, y la regulación a los dos lados del Atlántico lo está convirtiendo en lo mínimo esperable. Generá uno por release en CI, elegí CycloneDX o SPDX según quién lo consume, cruzalo contra datos de vulnerabilidades todo el tiempo y acordate de que tu propio código, tus secretos y tu configuración necesitan sus propios chequeos.