Software Bill of Materials

Cómo funciona

Un generador identifica componentes y relaciones a partir del código, archivos de dependencias o imágenes. El SBOM se almacena con la versión del artefacto y puede compararse con fuentes de vulnerabilidades y políticas.

Ejemplo: generar un inventario

Con Syft instalado, puedes inspeccionar el directorio de un proyecto y escribir un documento CycloneDX:

syft dir:. -o cyclonedx-json > sbom.json

La cobertura depende de los archivos y paquetes que el generador pueda identificar. Para una entrega en contenedor, analiza también la imagen construida: el código fuente no describe todos los componentes del sistema operativo.

Formatos

Formato	Origen	Rasgos
SPDX	Linux Foundation; ISO/IEC 5962	Fuerte en licencias y cumplimiento legal
CycloneDX	OWASP; estándar ECMA	Orientado a seguridad: vulnerabilidades, VEX, servicios, ML

La mayoría de herramientas generan y leen ambos.

Contenido mínimo

Según los elementos mínimos de la NTIA: proveedor, nombre del componente, versión, identificadores únicos (como purl o CPE), relación de dependencia, autor de los datos del SBOM y fecha. En la práctica conviene añadir licencias y hashes.

{
  "type": "library",
  "name": "jackson-databind",
  "version": "2.18.2",
  "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.2",
  "licenses": [{ "license": { "id": "Apache-2.0" } }],
  "hashes": [{ "alg": "SHA-256", "content": "…" }]
}

Generación en el pipeline

# Desde el código (dependencias declaradas)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Desde la imagen final (incluye paquetes del sistema operativo)
syft "$IMAGE@$DIGEST" -o cyclonedx-json > sbom.cdx.json
trivy image --format cyclonedx --output sbom.cdx.json "$IMAGE@$DIGEST"

# Analizar vulnerabilidades a partir del SBOM
trivy sbom sbom.cdx.json
grype sbom:sbom.cdx.json

# Adjuntar como atestación firmada a la imagen
cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$IMAGE@$DIGEST"

Genera el SBOM de lo que realmente se despliega (la imagen) y guárdalo junto al artefacto (Cosign).

Del inventario a la respuesta ante incidentes

Cuando se publica una vulnerabilidad crítica (como ocurrió con Log4Shell), la pregunta es «¿dónde la tenemos?». Con SBOM de cada versión desplegada en una plataforma como OWASP Dependency-Track, la respuesta tarda minutos en lugar de semanas de búsqueda manual en repositorios.

Capacidad	Herramienta
Generar	Syft, Trivy, cdxgen, plugins de Maven/Gradle/npm
Analizar vulnerabilidades	Trivy, Grype, OSV-Scanner
Gestionar y monitorizar	Dependency-Track (carga continua de SBOM y alertas)
Indicar explotabilidad	VEX: «afectado», «no afectado» y justificación

VEX: reducir el ruido

Un escáner reporta cada CVE presente en las dependencias, incluso si el código vulnerable nunca se usa. Un documento VEX declara para cada vulnerabilidad si el producto está realmente afectado y por qué («el componente no está en la ruta de ejecución»), de modo que los consumidores y los propios equipos puedan priorizar.

Contexto regulatorio

Los SBOM se han convertido en requisito para proveedores del gobierno de Estados Unidos y son relevantes para el Cyber Resilience Act de la Unión Europea. Cada vez más clientes empresariales los exigen en contratos de software.

Criterios de implementación

Vincula el documento con el digest y la versión exacta. Distingue inventario, análisis de vulnerabilidades y evaluación de explotabilidad. Firma o protege la evidencia y conserva su procedencia para responder a incidentes posteriores.