SBOM: la lista de ingredientes del software que empieza a ser imprescindible
Cuando compramos comida, miramos la etiqueta para saber qué contiene. En software hacemos justo lo contrario: instalamos aplicaciones, contratamos servicios y desplegamos sistemas críticos sin conocer realmente todas las piezas que hay dentro. Un SBOM, siglas de Software Bill of Materials, intenta corregir ese punto ciego. Es una lista estructurada de componentes, librerías, versiones y dependencias que forman parte de un producto software. Es una herramienta práctica para responder rápido cuando aparece una vulnerabilidad, evaluar proveedores y reducir riesgos en la cadena de suministro digital.
El software moderno ya no se construye desde cero
La mayoría del software actual es una composición de piezas propias, librerías de terceros, paquetes open source, frameworks, contenedores, SDK y servicios externos. Incluso una aplicación aparentemente sencilla puede depender de cientos de componentes directos e indirectos. Esa reutilización acelera el desarrollo, pero introduce un problema: muchas organizaciones no saben con precisión qué código ejecutan.
Log4Shell lo hizo evidente. Cuando se publicó la vulnerabilidad de Log4j, muchas empresas tuvieron que responder una pregunta básica: “¿tenemos esta librería en algún sistema?”. En demasiados casos, la respuesta no estaba en un inventario fiable, sino en búsquedas manuales y correos al proveedor. La CISA define el SBOM como un inventario anidado de los ingredientes del software. Esa palabra, “anidado”, es clave: no basta con listar lo instalado directamente; también hay que saber qué traen esas piezas dentro.
Qué contiene un SBOM útil
Un SBOM útil no es un PDF decorativo que se entrega una vez y se guarda en una carpeta. Debe ser un artefacto técnico, legible por máquinas y actualizado con cada versión relevante del producto. Normalmente incluye el nombre de cada componente, versión, proveedor, identificadores normalizados, relación entre dependencias, licencias y referencias que permitan cruzarlo con bases de datos de vulnerabilidades.
La NTIA publicó en 2021 unos elementos mínimos para un SBOM que siguen siendo una referencia clara. En la práctica, los formatos más habituales son SPDX y CycloneDX, porque permiten integrar el SBOM en herramientas de desarrollo, escáneres de seguridad, repositorios y plataformas de gobierno del software.
La clave está en el ciclo de vida. Si el SBOM no se genera automáticamente, si no se asocia a una versión concreta y si no se actualiza tras cada cambio de dependencias, pierde valor. Un inventario desfasado puede dar una falsa sensación de control.
La cadena de suministro también se audita
Durante años, la seguridad del software se ha tratado como una cuestión interna: revisar código, aplicar parches, hacer pruebas y configurar bien los sistemas. Eso sigue siendo necesario, pero ya no basta. Hoy una vulnerabilidad puede entrar por una dependencia open source, una imagen de contenedor, un paquete comprometido o un proveedor que integra componentes sin suficiente control.
Aquí el SBOM cambia la conversación. En vez de preguntar solo “¿el proveedor cumple?”, permite preguntar “¿qué contiene exactamente lo que me entrega?”. Esto es especialmente relevante en sectores regulados, infraestructuras críticas, sanidad, banca, telecomunicaciones y Administración Pública. Cuando se compra software, también se compra una cadena de dependencias.
En Tecnoic ya hemos hablado de seguridad de aplicaciones al explicar el OWASP Top 10. El SBOM encaja en esa lógica, pero desplaza el foco desde la vulnerabilidad visible hacia la trazabilidad.
Europa empuja hacia la transparencia obligatoria
El SBOM está ganando peso porque la regulación europea se mueve hacia una idea clara: los productos digitales deben diseñarse, mantenerse y documentarse con seguridad durante todo su ciclo de vida. El Cyber Resilience Act introduce requisitos horizontales de ciberseguridad para productos con elementos digitales comercializados en la Unión Europea. Sus principales obligaciones se aplicarán desde el 11 de diciembre de 2027, aunque la notificación de vulnerabilidades explotadas e incidentes graves empezará el 11 de septiembre de 2026.
El Reglamento (UE) 2024/2847 incluye la obligación de identificar y documentar vulnerabilidades y componentes, incluyendo una lista de materiales de software en un formato común y legible por máquina, al menos para dependencias de primer nivel. Dicho de forma sencilla: Europa quiere que los fabricantes sepan qué venden y puedan responder cuando algo falla.
Esto alcanzará a software comercial, dispositivos IoT, herramientas empresariales y componentes integrados en otros productos.
Un SBOM no sustituye a la seguridad
Conviene evitar otro error: pensar que tener SBOM equivale a estar seguro. Un inventario no parchea sistemas, no bloquea ataques y no decide prioridades por sí solo. Su valor aparece cuando se conecta con gestión de vulnerabilidades, análisis de riesgo, monitorización, control de proveedores, pruebas de seguridad y procedimientos de respuesta.
También tiene límites. Puede revelar información sensible sobre arquitectura interna, contener errores si se genera mal y producir mucho ruido si todas las vulnerabilidades se tratan igual. Saber que una librería vulnerable está presente no significa automáticamente que sea explotable en ese producto concreto. Por eso ganan relevancia conceptos complementarios como VEX, que permite indicar si una vulnerabilidad afecta o no afecta realmente a un componente en un contexto determinado.
La madurez está en usar el SBOM como evidencia técnica, no como casilla de cumplimiento.
Conclusión
El SBOM representa un cambio sencillo pero profundo: dejar de tratar el software como una caja negra. En un entorno lleno de dependencias, proveedores y componentes reutilizados, saber qué contiene un sistema ya no es un lujo técnico, sino una condición básica de seguridad. La pregunta no es si todas las organizaciones necesitarán SBOM mañana, sino cuándo empezarán sus clientes, auditores o reguladores a pedirlo. ¿Lo estamos preparando de verdad o solo esperando al siguiente Log4Shell?