Comprobación práctica de SBOM: cómo su empresa implementa la lista de componentes de software hasta septiembre de 2026
500.000 listas de componentes de software gestiona únicamente Deutsche Bahn. Lo que suena a burocracia se convertirá a partir de septiembre de 2026 en una obligación para todos los fabricantes de productos digitales en la UE. Quien no se prepare, arriesga multas de hasta 15 millones de euros – y la exclusión del mercado europeo.
En resumen
- 🔒 El Cyber Resilience Act de la UE hace obligatoria la lista de componentes de software (SBOM) a partir de diciembre de 2027. Las primeras obligaciones de notificación entran en vigor en septiembre de 2026 (Reglamento UE 2024/2847).
- 📊 El 75 por ciento de todas las empresas fue víctima de un ataque a la cadena de suministro en 2024. La predicción de Gartner del 45 por ciento fue demasiado conservadora (BlackBerry, 2024).
- 🛡️ El BSI exige expresamente en la TR-03183-2 los formatos CycloneDX a partir de la versión 1.6 o SPDX a partir de la versión 3.0.1 como formato SBOM (BSI, 2024).
- 🏭 Deutsche Bahn gestiona 500.000 listas con herramientas de código abierto y lógica propia (FOSDEM 2026).
- ⚙️ Tres vías de implementación: totalmente automática en la CI/CD-Pipeline, híbrida con revisión, o manual para software heredado.
Septiembre de 2026: comienza la cuenta atrás
Su equipo de seguridad enfrenta un problema concreto: a partir del 11 de septiembre de 2026, todos los fabricantes de productos con elementos digitales deberán notificar a la ENISA cualquier vulnerabilidad activamente explotada en un plazo de 24 horas. Sin una lista de componentes de software actualizada, esto es simplemente imposible. Porque quien no sabe qué componentes contiene su propio software, tampoco puede evaluar si una nueva vulnerabilidad afecta a su producto.
Actualmente, el tiempo medio de detección de infiltraciones en la cadena de suministro es de 287 días. Casi diez meses durante los cuales los atacantes operan sin ser detectados en sistemas comprometidos. Una SBOM reduce drásticamente este periodo, ya que permite una consulta inmediata: ¿Utilizamos la biblioteca afectada? ¿En qué versión? ¿En qué producto?
Fuentes: BlackBerry Global Threat Intelligence Report 2024; IBM/Ponemon Cost of a Data Breach 2025; Verizon DBIR 2025
Qué es una SBOM – y qué no
Una Software Bill of Materials (SBOM) documenta todos los componentes, bibliotecas y dependencias de un producto de software. Equiparable a la lista de ingredientes de un envase de alimentos, pero para código. El CRA la define como «registro formal que contiene detalles y relaciones de cadena de suministro de los componentes incluidos en los elementos de software».
Importante: una SBOM no es una auditoría de seguridad. Hace transparente lo que se ha integrado – no si es seguro. Pero sin esta transparencia, no es posible una evaluación sistemática de vulnerabilidades. Solo la combinación de SBOM y VEX (Vulnerability Exploitability eXchange) ofrece una imagen completa: la SBOM enumera los componentes, y el VEX evalúa si una vulnerabilidad conocida es realmente explotable en el contexto específico de uso.
Plazos regulatorios en resumen
El Cyber Resilience Act de la UE establece obligaciones en dos fases:
A partir del 11 de septiembre de 2026: Obligación de notificar a la ENISA cualquier vulnerabilidad activamente explotada en un plazo de 24 horas. Esto también se aplica a productos ya presentes en el mercado. Sin SBOM y seguimiento automatizado de vulnerabilidades, este plazo es prácticamente imposible de cumplir.
A partir del 11 de diciembre de 2027: Obligación total de SBOM para todos los productos con elementos digitales comercializados en la UE. La lista debe estar en un formato legible por máquina y cubrir al menos las dependencias de nivel superior. En caso de incumplimiento, se prevén multas de hasta 15 millones de euros o el 2,5 por ciento del volumen de negocio anual mundial.
Paralelamente, el BSI, como futura autoridad de supervisión del mercado, ha publicado la Directiva Técnica TR-03183-2. Esta va más allá de los requisitos mínimos de la UE y exige, entre otros aspectos, sumas de comprobación criptográficas, identificadores de licencias y mecanismos de firma.
„¡El CRA es un cambio de paradigma para la seguridad de los productos digitales!“
– Claudia Plattner, Presidenta de la Oficina Federal de Seguridad en la Tecnología de la Información (BSI)
Tres vías hacia la SBOM: comprobación práctica
Para directores de TI y CISOs surge una pregunta muy concreta: ¿cómo lo implementamos? La respuesta depende del entorno de software propio, del grado de madurez de las CI/CD-Pipelines y del presupuesto disponible. En la práctica, se han establecido tres opciones.
Opción 1: Totalmente automatizada en la CI/CD-Pipeline
Para quién: Empresas con procesos de desarrollo modernos, despliegues basados en contenedores y una cultura DevSecOps ya existente.
Cómo funciona: Herramientas como Syft, Trivy o cdxgen se integran directamente en la pipeline de compilación. En cada compilación, se genera automáticamente una SBOM en formato CycloneDX o SPDX, se versiona y se almacena centralmente. La SBOM se actualiza automáticamente con cada versión.
Ventajas: Mínimo esfuerzo continuo, máxima actualidad, escalable con el número de productos. Según la ENISA, este es el enfoque recomendado para empresas con más de diez productos de software.
Desventajas: Trabajo inicial de integración (2-4 semanas por pipeline), requiere competencias DevOps, los sistemas heredados sin CI/CD quedan excluidos.
Opción 2: Híbrida con revisión manual
Para quién: Medianas empresas con un entorno de software mixto. Algunos productos funcionan en pipelines modernos, otros son sistemas consolidados sin automatización.
Cómo funciona: Los productos modernos se capturan automáticamente (como en la Opción 1). Para el software heredado, las SBOM se generan mediante herramientas de análisis binario como FOSSA o Mend, que escanean binarios terminados. Un analista de seguridad revisa y complementa los resultados manualmente.
Ventajas: Cubre todo el entorno de productos, realista de implementar con equipos existentes, cumple plenamente con la BSI TR-03183-2.
Desventajas: Costes humanos continuos más altos, los pasos manuales son propensos a errores, los ciclos de revisión ralentizan los lanzamientos.
Opción 3: Manual con enfoque basado en plantillas
Para quién: Pequeños fabricantes de software con pocos productos, que no disponen de un departamento DevOps propio.
Cómo funciona: Las SBOM se crean manualmente, basadas en plantillas de la ENISA y directrices del BSI. Los desarrolladores documentan las bibliotecas y versiones utilizadas en una tabla estructurada, que luego se convierte a CycloneDX o SPDX.
Ventajas: No requiere inversión en herramientas, inicio rápido posible, cumple los requisitos mínimos del CRA.
Desventajas: No escalable, alta tasa de errores en árboles de dependencias complejos, se vuelve inmanejable con más de tres productos. La ENISA advierte expresamente que las SBOM creadas manualmente a menudo no alcanzan la calidad mínima requerida.
Cómo lo hace Deutsche Bahn
Que las SBOM también funcionan a gran escala lo demuestra Deutsche Bahn. En la FOSDEM 2026, la empresa presentó su enfoque: 500.000 SBOM, gestionadas mediante una combinación de herramientas de código abierto y lógica desarrollada internamente, integradas en la arquitectura empresarial existente.
Tres conclusiones del proyecto de DB son relevantes también para empresas más pequeñas:
Las SBOM no son un fin en sí mismas. DB trata las SBOM como un método de apoyo para diversos casos de uso – desde la gestión de vulnerabilidades y cumplimiento de licencias hasta el control de proveedores. Quien vea las SBOM solo como un requisito regulatorio pierde su utilidad operativa.
El software de código abierto es suficiente – con lógica propia. DB utiliza herramientas FOSS como Syft y Trivy, complementadas con su propia lógica para integrarlas en SAP y sistemas internos. No fueron necesarias plataformas comerciales costosas, pero el trabajo de integración fue considerable.
Las personas marcan la diferencia. Las herramientas técnicas solas no bastan. DB enfatiza que se necesita personal dedicado para integrar las SBOM en las pipelines y supervisar continuamente la calidad de las listas generadas.
La otra cara: por qué las SBOM no son una solución mágica
Pese al entusiasmo por los avances regulatorios: las SBOM no resuelven todos los problemas de seguridad en la cadena de suministro de software. Tres limitaciones que los directores de TI deben conocer.
Fragmentación de los estándares. CycloneDX y SPDX son los dos formatos dominantes, pero no son completamente compatibles. Muchas empresas generan ambos formatos simultáneamente – CycloneDX para el equipo de seguridad, SPDX para el departamento legal. Esto duplica el esfuerzo sin aportar beneficios de seguridad.
Problema de calidad. No toda SBOM generada automáticamente alcanza la calidad mínima. La ENISA advierte en su informe SBOM Landscape (diciembre de 2025) que los proveedores de software a menudo no incluyen datos relevantes porque simplemente no están disponibles. Una SBOM que registra el 60 por ciento de las dependencias transmite una falsa sensación de seguridad.
Los atacantes se adaptan. Los ataques a la cadena de suministro se duplicaron en 2025, con un promedio de 26 incidentes por mes a partir de abril de 2025. Los atacantes apuntan cada vez más a las propias pipelines de compilación – es decir, precisamente a la infraestructura que genera las SBOM. Un proceso de compilación comprometido puede producir incluso una SBOM que parezca correcta, pero que esté manipulada.
¿CycloneDX o SPDX? La decisión sobre el formato
El BSI acepta ambos formatos, pero recomienda CycloneDX a partir de la versión 1.6 o SPDX a partir de la versión 3.0.1. Para la práctica, se aplica lo siguiente:
CycloneDX es la mejor opción para los equipos de seguridad. El formato ofrece soporte nativo para VEX, hashing y árboles de dependencias. La versión 1.7 (octubre de 2025) añade además metadatos de patentes y una mayor transparencia criptográfica. CycloneDX soporta, además de SBOM de software, también listas de componentes de hardware (HBOM), de inteligencia artificial/aprendizaje automático (AI/ML) y listas criptográficas (CBOM).
SPDX es más fuerte en el ámbito del cumplimiento de licencias y la debida diligencia de propiedad intelectual. Como estándar certificado ISO/IEC 5962:2021, SPDX goza de una mayor aceptación regulatoria, especialmente en empresas con actividad internacional.
Recomendación pragmática: comience con CycloneDX para la operación de seguridad diaria. Si su departamento legal exige SPDX, utilice herramientas de conversión como cyclonedx-cli o spdx-tools. Ambos formatos se pueden convertir entre sí, aunque es posible que se pierdan algunos detalles.
Lista de comprobación: preparación SBOM en 90 días
Para directores de TI que quieran empezar ahora, aquí tiene un plan de acción concreto:
Semana 1-2: Inventario inicial
- Inventariar todos los productos con elementos digitales (incluyendo firmware, software embebido, dispositivos IoT)
- Documentar las pipelines CI/CD y procesos de compilación existentes
- Nombrar responsables (propietario de SBOM por línea de producto)
Semana 3-4: Proyecto piloto
- Seleccionar un producto (idealmente con una CI/CD-Pipeline moderna)
- Integrar un generador de SBOM (Syft para contenedores, cdxgen para aplicaciones)
- Generar la primera SBOM y validarla según la BSI TR-03183-2
Semana 5-8: Despliegue
- Extender el piloto exitoso a otros productos
- Configurar el seguimiento de vulnerabilidades (OSV, NVD o feed comercial)
- Definir y probar el proceso para la obligación de notificación en 24 horas
Semana 9-12: Consolidación
- Definir métricas de calidad de SBOM (grado de cobertura, actualidad)
- Exigir SBOM a proveedores e integrarlas en la lista propia
- Crear un historial de auditoría y documentación para la supervisión del mercado
El siguiente paso
La obligación de SBOM llega. La pregunta no es si, sino qué tan bien preparada está su empresa cuando entre en vigor la primera obligación de notificación en septiembre de 2026. El primer paso más pragmático: instale Syft o Trivy en un proyecto de prueba y genere su primera SBOM. Esto tarda 30 minutos y le mostrará inmediatamente cuántas dependencias hay en su software de las que no tenía conocimiento.
Preguntas frecuentes
Cada pregunta está bloqueada. Un toque desbloquea la respuesta.
¿Deben también las empresas que solo utilizan software (no lo fabrican) crear SBOM?
No. El CRA se dirige a fabricantes, es decir, a empresas que ponen productos con elementos digitales en el mercado de la UE. Los usuarios puros no deben crear sus propias SBOM, pero sí deben exigirlas a sus proveedores. La directiva NIS2 exige además que las infraestructuras críticas documenten su cadena de suministro de software en el marco de la gestión de riesgos.
¿Qué formato SBOM debo elegir – CycloneDX o SPDX?
Para la mayoría de los equipos de seguridad, CycloneDX a partir de la versión 1.6 es el punto de entrada más pragmático, ya que ofrece soporte nativo para vulnerabilidades y VEX. SPDX es más fuerte en cumplimiento de licencias. El BSI acepta ambos formatos en la TR-03183-2. Muchas empresas generan ambos formatos simultáneamente y convierten según sea necesario.
¿Cuánto cuesta la implementación de SBOM para una empresa de tamaño medio?
Los costes puramente de herramientas pueden ser cero, ya que herramientas de código abierto como Syft y Trivy están listas para producción. El esfuerzo principal reside en la integración: cuente con 2-4 semanas de trabajo de integración por CI/CD-Pipeline y medio FTE para el seguimiento continuo y aseguramiento de calidad. Las plataformas comerciales como FOSSA o Mend comienzan en aproximadamente 15.000 euros por año.
¿Es aplicable la obligación de SBOM también a proyectos de código abierto?
Sí y no. El software de código abierto desarrollado como proyecto de afición sin intención comercial queda exento del CRA. Tan pronto como una empresa integre componentes de código abierto en un producto comercial, asume la obligación de SBOM para el producto completo – incluyendo todas las dependencias de código abierto.
¿Debe la SBOM estar accesible públicamente?
No. El CRA aclara expresamente que los fabricantes no están obligados a publicar su SBOM. Debe formar parte de la documentación técnica y estar disponible para presentar a las autoridades de supervisión del mercado a petición. Algunas empresas publican voluntariamente sus SBOM como señal de confianza hacia sus clientes.
Artículos relacionados
- Seguridad en la cadena de suministro 2026: cómo las empresas protegen su cadena de suministro de software (SecurityToday)
- NIS2 en Alemania: lo que las empresas deben saber e implementar ahora (SecurityToday)
- DORA y NIS2 simultáneamente: doble carga de cumplimiento para los servicios financieros (SecurityToday)
Del red MBF-Media
- DORA, AI Act, MiCA simultáneamente: por qué RegTech se convierte en inversión obligatoria en 2026 (MyBusinessFuture)
- Tendencias Cloud 2026: lo que los responsables de TI deben tener ahora en el radar (cloudmagazin)
- Debida diligencia digital: por qué las operaciones de M&A fracasan por la IT (Digital Chiefs)
Fuente de imagen: Pexels / cottonbro studio
