Hay tres formatos estándar: SPDX (ISO/IEC 5962, más extendido en ámbito legal/licencias), CycloneDX (OWASP, más orientado a seguridad) y SWID (ISO/IEC 19770-2, más común para gestión de activos). En la práctica, CycloneDX domina en uso defensivo.
Qué es SBOM
SBOM (Software Bill of Materials) es el inventario formal y legible por máquina de todos los componentes y dependencias que forman un producto software: librerías de código abierto, paquetes de terceros, frameworks, versiones, licencias y, en el caso de las versiones más completas, también firmas, hashes y proveedores. Es el equivalente a la lista de ingredientes de un producto, pero aplicada a software. Los formatos estándar más usados son SPDX y CycloneDX.
Por qué importa
Cuando se publica una vulnerabilidad como Log4Shell, una organización sin SBOM tarda días o semanas en saber dónde tiene el componente afectado. Con SBOM bien mantenido, la respuesta es minutos. El Cyber Resilience Act europeo (CRA) hace SBOM prácticamente obligatorio para productos digitales puestos en el mercado europeo a partir de 2027. La Executive Order 14028 estadounidense ya lo exige a proveedores de gobierno desde 2022. NIS2 y DORA piden trazabilidad de la cadena de suministro de software, y SBOM es la pieza técnica que materializa esa trazabilidad. Para quien vende software a la AAPP, sectores regulados o grandes corporaciones, presentar SBOM ya es requisito de muchos pliegos.
Puntos clave
Generar SBOM no es manual: se integra en el pipeline CI/CD con herramientas como Syft, CycloneDX-CLI, Trivy o el SBOM nativo de varios DevOps. El SBOM se genera cada build y se firma para garantizar integridad.
Tener SBOM no protege; usar SBOM sí. La utilidad real está en cruzarlo con feeds de vulnerabilidades (NVD, GitHub Advisory, OSV) para saber instantáneamente qué builds están afectados por una nueva CVE.
SBOM + gestión de vulnerabilidades + CVE tracking es la combinación que da supply chain visibility real. Sin SBOM, la gestión de vulnerabilidades sobre componentes de terceros es opaca.
Ejemplo: respuesta a una nueva CVE crítica con SBOM
Se publica una CVE crítica en una librería de parseo de XML ampliamente usada. Sin SBOM, el equipo de seguridad pregunta a desarrollo, abre tickets en cada producto, revisa manifests de cada microservicio y, en una organización mediana, tarda 5-10 días en saber su exposición real. Con SBOM bien implementado, una consulta automatizada sobre el repositorio SBOM cruza la versión vulnerable contra todos los builds publicados y devuelve en segundos: tres productos afectados, dos versiones concretas, dependencia transitiva en una de ellas (no directa). El equipo prioriza, actualiza y publica patches en horas, no semanas. Bajo NIS2 y DORA, ese plazo de respuesta es una diferencia material.
Errores habituales
- Generar SBOM una vez y guardarlo. SBOM tiene que ser un artefacto vivo, generado en cada build, versionado y consultable. Si no se mantiene, deja de reflejar la realidad rápido.
- Limitarse a dependencias directas. La mayoría de vulnerabilidades explotadas hoy llegan por dependencias transitivas (dependencias de dependencias). Un SBOM útil incluye todo el árbol completo.
- No firmar ni verificar SBOM. Si el atacante puede modificar el SBOM, también puede ocultar componentes maliciosos. SBOM se firma con sigstore o equivalente y se verifica en consumo.
- Confundir SBOM con análisis SCA. SCA (Software Composition Analysis) analiza vulnerabilidades en el código. SBOM es el inventario. SCA suele consumir SBOM como entrada.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿SBOM es obligatorio en la Unión Europea?
El Cyber Resilience Act (Reglamento UE 2024/2847) hace SBOM prácticamente obligatorio para productos con elementos digitales puestos en el mercado europeo, con plazos que llegan hasta 2027. NIS2 y DORA también exigen trazabilidad de cadena de suministro de software, donde SBOM es la herramienta natural.
¿Qué formato de SBOM debería elegir mi organización?
CycloneDX está más orientado a casos de uso de seguridad y es el más usado hoy en gestión de vulnerabilidades. SPDX cubre mejor licencias y aspectos legales. Si tu prioridad es seguridad y supply chain risk, empieza por CycloneDX.
¿SBOM tiene sentido si no fabricamos software?
Sí, como consumidor. Tu organización puede exigir SBOM a tus proveedores como parte de la diligencia de cadena de suministro. Te permite saber qué componentes corren en software comprado o externalizado y cruzarlo con nuevas vulnerabilidades publicadas.