El SBOM deja de ser una rareza técnica: ENISA ve una adopción acelerada antes del Cyber Resilience Act

El dato que cambia la conversación no es que el SBOM guste a los reguladores. Eso ya lo sabíamos. Lo relevante es otro: el 78% de las organizaciones encuestadas por ENISA ya ha iniciado su adopción, y un 79% cree que alcanzará la madurez necesaria antes de que el Cyber Resilience Act sea plenamente aplicable en diciembre de 2027. Traducido al castellano llano: el SBOM ha dejado de ser una obsesión de arquitectos de software y empieza a convertirse en un requisito operativo con fecha de caducidad.

La encuesta de ENISA, publicada en junio de 2026 y lanzada a finales de 2025, llega en un momento muy preciso. El Reglamento (UE) 2024/2847, más conocido como Cyber Resilience Act o CRA, ya está aprobado, ya tiene calendario, y ya ha introducido una idea incómoda para muchos fabricantes: vender software o productos con elementos digitales en la UE implicará demostrar seguridad de forma bastante más concreta de lo que el mercado estaba acostumbrado. Entre esas pruebas, la transparencia sobre componentes, dependencias y relaciones de suministro ha pasado de “buena práctica” a expectativa regulatoria tangible.

ENISA no está legislando aquí. La propia agencia lo recuerda en su aviso legal. Pero cuando ENISA publica un informe sobre adopción real y barreras concretas, conviene leerlo como un termómetro bastante útil de por dónde va a romper la ola. Y la ola viene clara: más automatización, más presión contractual, más exigencia de formatos estándar y menos paciencia con los inventarios artesanales de software que se actualizan cuando a alguien le sobra tiempo. Es decir, nunca.

Lo que ENISA ha encontrado y por qué importa de verdad

Los titulares numéricos del informe merecen algo más que una mención rápida. Según ENISA, el 78% de las organizaciones ya ha empezado su recorrido con SBOM. Dentro de ese grupo, un 44% sigue en fase piloto o de adopción limitada, un 25% afirma que ya lo adopta ampliamente en sus productos y un 9% dice haber alcanzado un nivel maduro, con soporte pleno de automatización. No es una fotografía de mercado perfecta, pero sí una señal de que esto ya no vive en PowerPoints.

Otro dato fino, y bastante revelador, es cómo justifican la inversión. El 37% de los encuestados identifica la reducción de riesgo y la evitación de costes como principal beneficio del uso continuo de SBOM. Un 29% habla de eficiencia operativa. Y un 26% lo conecta con requisitos contractuales y ventaja competitiva en licitaciones o procesos de compra. Ahí está el quid: el SBOM está mutando de herramienta de seguridad a moneda de mercado. No solo sirve para saber qué llevas dentro; sirve para no quedarte fuera.

Eso encaja con la lógica del CRA. El reglamento impone obligaciones esenciales de ciberseguridad a productos con elementos digitales y exige que fabricantes gestionen vulnerabilidades a lo largo del ciclo de vida, incluida la identificación y documentación de componentes relevantes. El detalle técnico fino se apoya especialmente en el anexo I del CRA, que recoge los requisitos esenciales de ciberseguridad, y en el régimen de gestión de vulnerabilidades y documentación técnica. No todas las obligaciones exigen el término “SBOM” como tal en cada línea, pero el instrumento encaja de forma casi quirúrgica con lo que el reglamento quiere obtener: visibilidad, trazabilidad y capacidad de reacción.

La otra cifra que no conviene pasar por alto está en los formatos. El 44% usa CycloneDX y el 29% SPDX. Un 11% sigue sin usar un formato estándar y el resto continúa con formatos propietarios. Esto importa más de lo que parece. El CRA no quiere un inventario bonito en PDF para enseñar al auditor un jueves por la tarde. Quiere información en un formato común, legible por máquina y utilizable en procesos de gestión de vulnerabilidades, mantenimiento, soporte y cooperación en la cadena de suministro. Quien siga con formatos cerrados o documentos estáticos está construyendo deuda operativa con disfraz de cumplimiento.

El CRA no obliga a “tener un SBOM” en abstracto. Obliga a poder demostrar cosas muy concretas

Conviene evitar una simplificación que empieza a circular con demasiada alegría: “el CRA exige SBOM”. La versión seria es algo más precisa. El CRA exige una serie de resultados jurídicos y técnicos que, en la práctica, hacen del SBOM una pieza muy útil y en muchos casos casi inevitable.

El Reglamento (UE) 2024/2847 entró en vigor en diciembre de 2024, pero su aplicación es escalonada. La plena aplicabilidad general llega el 11 de diciembre de 2027. Antes, hay hitos intermedios relevantes. Las obligaciones sobre notificación de vulnerabilidades explotadas activamente e incidentes graves a ENISA aplican antes, desde septiembre de 2026, conforme al calendario transitorio del propio reglamento. Esa anticipación no es un detalle menor: obliga a empezar antes la maquinaria de identificación y respuesta. Y esa maquinaria funciona bastante mejor si sabes exactamente qué componentes lleva cada producto, qué dependencias hereda y dónde impacta un fallo de terceros.

El anexo I, parte I, del CRA exige que los productos con elementos digitales se diseñen, desarrollen y produzcan de forma que garanticen un nivel adecuado de ciberseguridad basado en riesgos. También exige abordar vulnerabilidades conocidas de componentes de terceros, reducir superficies de ataque innecesarias, y asegurar que los productos puedan actualizarse con parches de seguridad. La parte II del mismo anexo entra en gestión de vulnerabilidades, incluida la identificación y documentación de vulnerabilidades y componentes, así como la distribución de actualizaciones de seguridad sin demoras indebidas.

Si una organización quiere cumplir eso sin una base estructurada de inventario de componentes, puede intentarlo. También puede intentar hacer contabilidad en servilletas. No es ilegal escribir números en una servilleta, pero cuesta cerrar la auditoría.

Además, el CRA obliga a elaborar documentación técnica suficiente para demostrar conformidad. Esa documentación debe permitir evaluar si el producto cumple los requisitos esenciales. Un SBOM bien generado, versionado, vinculado al pipeline de compilación y conectado a procesos de gestión de vulnerabilidades no agota por sí solo esa documentación, pero la fortalece de manera obvia. Sobre todo cuando hay software de terceros, componentes open source, dependencias transitivas y bibliotecas embebidas que nadie recuerda haber aprobado formalmente hace tres versiones.

La cronología regulatoria explica el apretón: no es solo CRA, es el efecto pinza con NIS2, DORA y contratación

Si el informe de ENISA se leyera aisladamente, podría parecer una historia técnica. No lo es. El SBOM está ganando tracción porque varias piezas regulatorias y de mercado empiezan a pedir, de distintas formas, la misma capacidad: saber qué software tienes, de quién depende, cómo lo aseguras y cuánto tardas en reaccionar cuando algo se rompe.

NIS2, la Directiva (UE) 2022/2555, obliga a entidades esenciales e importantes a implantar medidas de gestión de riesgos de ciberseguridad. El artículo 21 incluye seguridad de la cadena de suministro, gestión de vulnerabilidades, políticas de análisis de riesgos y manejo de incidentes. NIS2 no impone un SBOM nominalmente, pero sí exige resultados para los que un SBOM aporta ventaja táctica clara. Si eres operador de servicios esenciales, proveedor digital relevante o fabricante con exposición en cadenas críticas, la falta de visibilidad sobre dependencias de software empieza a parecerse mucho a un fallo de control básico.

En el sector financiero europeo, DORA añade otra capa. El Reglamento (UE) 2022/2554 obliga a entidades financieras a gestionar riesgo TIC de forma integral, con especial foco en terceros. El artículo 5 exige un marco interno de gestión del riesgo TIC sólido y documentado. El artículo 8 impone identificación, clasificación y documentación de funciones, activos de información y dependencias TIC. El artículo 28 se centra en la gestión del riesgo de terceros proveedores de servicios TIC. De nuevo, DORA no convierte el SBOM en dogma obligatorio, pero sí convierte la opacidad sobre componentes y proveedores de software en un problema de gobierno y resiliencia operativa.

La contratación pública y privada está haciendo el resto. Muchas organizaciones no esperan a que el regulador les pida el papel; se lo piden ya a sus proveedores. El 26% de los encuestados por ENISA vincula el valor del SBOM a requisitos contractuales y ventaja competitiva. Ese porcentaje probablemente crecerá. Porque una gran empresa que ya está preparando cumplimiento de CRA, NIS2 o DORA no quiere depender de un proveedor que responda “lo estamos mirando” cuando aparezca una CVE crítica en una biblioteca muy extendida.

Ahí está una de las ironías de esta historia: durante años, buena parte del mercado compró software como si fuera una caja cerrada y mágicamente segura. Ahora descubre que el software era una cadena de suministros compleja, hecha de paquetes, forks, módulos huérfanos y dependencias transitivas que nadie revisó con demasiado cariño. El SBOM no arregla eso por arte de magia. Pero al menos quita la venda.

El verdadero valor del SBOM aparece el día que sale una vulnerabilidad grave

Para entender por qué ENISA habla de eficiencia operativa y reducción de costes, hay que salir del plano doctrinal y aterrizar en el incidente real. Cuando aparece una vulnerabilidad grave en una biblioteca ampliamente usada, el tiempo no se pierde en parchear; se pierde en averiguar si te afecta.

Log4Shell sigue siendo el ejemplo canónico. La vulnerabilidad CVE-2021-44228 en Apache Log4j explotó públicamente en diciembre de 2021 y dejó una lección brutal: muchas organizaciones no sabían dónde estaba Log4j, ni qué productos internos o de terceros lo incorporaban, ni qué versiones eran vulnerables. Durante días y semanas, la pregunta no fue “¿cómo mitigamos?”, sino “¿llevamos esto en algún sitio?”. Quien tenía inventarios pobres improvisó búsquedas masivas, escaneos parciales y llamadas nerviosas a proveedores. Quien tenía una práctica razonable de composición de software y trazabilidad pudo priorizar mucho mejor.

Un SBOM no elimina por sí mismo el trabajo de remediación. Tampoco sustituye a un VEX, un Vulnerability Exploitability eXchange, cuando toca informar si una vulnerabilidad concreta es explotable en un producto específico. Pero reduce dos costes que pesan muchísimo en un incidente serio: el coste de localización y el coste de coordinación. Saber qué componentes tienes, en qué versiones y en qué productos permite decidir antes si toca parchear, mitigar, aislar o simplemente documentar no afectación.

Eso encaja con la lógica de notificación del CRA y con otras obligaciones sectoriales. Si debes notificar una vulnerabilidad explotada activamente o un incidente grave, cuanto más tardes en determinar alcance, más frágil será tu respuesta. Y cuanto menos trazable sea tu cadena de componentes, más probable es que infraestimes impacto o sobrerreacciones. Ninguna de las dos cosas sienta bien ante un regulador, un cliente o un comité de crisis.

Además, el valor no se limita a seguridad. ENISA detecta que el 29% menciona eficiencia operativa. Tiene sentido. Un SBOM bien integrado en CI/CD puede acelerar revisiones de licencias, due diligence en M&A tecnológica, evaluación de proveedores, validación previa a despliegues y seguimiento de deuda técnica. No es glamuroso, pero ahorra horas, discusiones y, sobre todo, falsas certezas.

El problema no es generar un SBOM. El problema es que siga siendo útil una semana después

La conversación de mercado sobre SBOM a veces cae en una trampa bastante infantil: reducir el asunto a “qué herramienta lo genera”. ENISA, por fortuna, apunta a algo más interesante al analizar formatos, herramientas e integración en el ciclo de vida. Porque sí, generar un fichero CycloneDX o SPDX es relativamente sencillo. Integrarlo de manera fiable, continua y accionable en el SDLC ya es otra película.

Un SBOM estático generado una vez para una auditoría puntual sirve de poco cuando el producto cambia cada sprint, cuando las dependencias se actualizan automáticamente y cuando los contenedores arrastran capas que nadie mira desde hace meses. El valor aparece cuando la generación está automatizada y vinculada al build real, cuando la firma o integridad del artefacto es verificable, cuando se conserva historial por versión y cuando esa salida conecta con procesos de vulnerabilidades, procurement, gestión de terceros y soporte.

Por eso el dato de ENISA sobre madurez importa más que el simple dato de adopción. Solo un 9% declara una implementación madura y plenamente automatizada. El 25% dice que el SBOM está ampliamente adoptado, pero eso no significa necesariamente que esté gobernado con rigor, validado en cada release o integrado con respuesta a vulnerabilidades. Ahí puede esconderse una zona gris enorme: organizaciones que ya producen SBOM, pero todavía no saben usarlos de forma consistente para decisiones operativas.

También conviene mirar la cuestión de profundidad. Un SBOM superficial que recoge solo dependencias directas puede dejar fuera justo lo que más duele: las dependencias transitivas. Y un SBOM que no cubra binarios, paquetes del sistema, firmware, imágenes de contenedor o componentes adquiridos a terceros puede dar una sensación peligrosa de control. Peor que no tener visibilidad es tener una visibilidad mediocre y creer que basta.

En la práctica, la pregunta útil no es “¿tenemos SBOM?”. La pregunta útil es esta: “¿podemos reconstruir con precisión qué componentes estaban en la versión X desplegada en producción el día Y, y cruzarlo con una vulnerabilidad publicada hoy?”. Si la respuesta es no, lo que tienes puede ser un documento; todavía no es una capacidad.

Los formatos importan porque la interoperabilidad no es un lujo burocrático

Que CycloneDX lidere con un 44% y SPDX le siga con un 29% refleja una consolidación razonable de formatos estándar. Y, aun así, el 11% sin formato estándar y el bloque que sigue atado a formatos propietarios enseñan un problema de base: la interoperabilidad sigue sin estar resuelta del todo.

Esto no es una guerra de siglas para especialistas. El formato determina si el SBOM puede circular entre fabricantes, integradores, clientes, herramientas de análisis y procesos de remediación sin convertirse en una pesadilla de transformación manual. CycloneDX ha ganado mucho terreno por su orientación práctica a seguridad y su ecosistema en herramientas modernas de software composition analysis. SPDX conserva fortaleza por su trayectoria y por su profundidad histórica en licencias y metadatos. La elección puede depender del caso de uso. Lo problemático no es usar uno u otro. Lo problemático es no usar ninguno o encapsular la información en un esquema propietario que obliga a rehacerla cada vez que cambias de herramienta o de proveedor.

El CRA habla de formatos comúnmente usados y legibles por máquina por una razón muy sencilla: un inventario que no puede consumirse automáticamente no escala. Y aquí ENISA apunta a otro tema serio: la interoperabilidad no es solo técnica, también es comercial. Si un fabricante exige SBOM a su proveedor, pero cada uno usa un esquema distinto, niveles diferentes de granularidad y taxonomías incompatibles para componentes o vulnerabilidades, el resultado es una cadena de suministro que intercambia papeles, no información.

La siguiente capa de madurez será precisamente esa: no solo generar SBOM, sino intercambiarlos con trazabilidad, validarlos automáticamente, correlacionarlos con fuentes de vulnerabilidades y complementarlos con información contextual, por ejemplo mediante VEX cuando haya que distinguir entre vulnerabilidad presente y vulnerabilidad explotable. Sin ese paso, muchas organizaciones acabarán con miles de SBOM almacenados y muy poca inteligencia real extraída de ellos.

Las barreras que revela ENISA son bastante menos técnicas de lo que parece

Aunque el informe se centra en adopción, formatos y usos, la lectura entre líneas deja algo claro: el freno principal rara vez es la imposibilidad técnica. El freno suele estar en la gobernanza, en la responsabilidad difusa y en la incoherencia entre equipos.

En muchas compañías, el equipo de desarrollo ve el SBOM como una salida adicional del pipeline. Seguridad lo ve como una nueva fuente de señal. Compliance lo interpreta como evidencia potencial ante CRA, NIS2 o exigencias contractuales. Procurement lo descubre cuando un cliente empieza a pedirlo a la cadena. El problema aparece cuando nadie decide quién es dueño del proceso, qué nivel mínimo de cobertura se exige, qué repositorios y productos entran en alcance y qué calidad de datos se acepta.

Ese vacío genera tres fallos recurrentes. Primero, SBOM incompletos porque cada equipo usa herramientas o umbrales distintos. Segundo, falta de mantenimiento porque el ejercicio se hizo para una prueba piloto y no para operación continua. Tercero, ausencia de decisión sobre tratamiento de hallazgos: si un SBOM revela componentes obsoletos, bibliotecas sin mantenedor o licencias problemáticas, alguien tiene que priorizar, asumir coste y corregir. Sin ese circuito, el SBOM se convierte en una linterna encendida en un cuarto que nadie quiere limpiar.

ENISA también apunta a necesidades de orientación y soporte externo. Tiene lógica. El mercado aún arrastra fragmentación en herramientas, prácticas dispares por sector y dudas sobre granularidad adecuada, intercambio con terceros y relación con procesos de vulnerabilidades. No todo se resuelve comprando una plataforma de SCA y pulsando “exportar”. De hecho, uno de los mayores riesgos de 2026 y 2027 será precisamente ese: creer que la herramienta equivale al programa.

Qué deberían hacer ya los fabricantes y proveedores de software

Si una organización vende productos con elementos digitales en la UE, la ventana cómoda se está cerrando. No hace falta dramatizar, pero tampoco seguir fingiendo que esto puede dejarse para 2027. Hay varias decisiones que ya deberían estar tomadas, y ninguna requiere esperar a una guía milagrosa del regulador.

La primera es de alcance. Hay que decidir qué productos, líneas de código, componentes empaquetados, contenedores, firmware y dependencias de terceros entran en el programa. Sin alcance, no hay cobertura medible. La segunda es de formato y modelo de datos. Elegir CycloneDX o SPDX es menos importante que elegir uno, estandarizarlo y definir atributos obligatorios: nombre del componente, versión, origen, hash, relaciones, licencias, proveedor y vínculo con la release concreta.

La tercera es de integración. El SBOM debe salir del proceso real de build o packaging, no de una reconstrucción manual posterior. Si no está unido al artefacto que efectivamente se distribuye, perderá fiabilidad en cuanto el pipeline cambie. La cuarta es de uso operativo: qué procesos consumen el SBOM. Al menos deberían hacerlo gestión de vulnerabilidades, evaluación de terceros, soporte de incidentes, revisión de licencias y due diligence de producto. Y la quinta es de gobernanza: quién aprueba excepciones, quién mide cobertura, quién verifica calidad y quién responde cuando se detectan componentes no permitidos.

No hace falta una lista eterna de controles para ver la dirección. Lo esencial es que el SBOM deje de ser “el fichero que generamos” y pase a ser “la evidencia estructurada que conecta desarrollo, seguridad, producto y cumplimiento”.

Hay, además, una decisión incómoda que muchas empresas siguen aplazando: qué exigir a sus proveedores. El informe de ENISA dedica atención a requisitos para consumidores de SBOM. Tiene sentido. Una compañía puede mejorar su software propio y seguir ciega respecto a componentes embebidos en productos ajenos o módulos de terceros. Quien compra software para integrarlo en productos propios debería definir ya cláusulas sobre entrega de SBOM en formato estándar, frecuencia de actualización, cobertura mínima, gestión de vulnerabilidades y soporte cuando aparezcan CVE críticas. Si esperas a que estalle el incidente para negociar eso, llegarás tarde y negociarás peor.

Implicaciones para entidades financieras europeas: no les aplica el CRA como fabricantes… hasta que sí les afecta por la cadena

A primera vista, el informe de ENISA va dirigido sobre todo al mundo de fabricantes y proveedores de software. Sería un error que banca, seguros y fintech lo miraran como si fuera una historia ajena. El sector financiero ya opera bajo DORA desde el 17 de enero de 2025, y DORA obliga a entender dependencias TIC internas y de terceros con una disciplina que casa bastante bien con la lógica SBOM.

Una entidad financiera que desarrolla software propio, aplicaciones móviles, middleware o integraciones críticas no puede permitirse una visibilidad pobre de componentes. El artículo 8 de DORA exige identificar y clasificar funciones, activos de información y dependencias TIC. El artículo 10 obliga a mecanismos de detección de anomalías y vulnerabilidades. El artículo 28 refuerza el escrutinio sobre terceros proveedores de servicios TIC. Si un banco no sabe qué bibliotecas vulnerables arrastra una aplicación crítica o no puede exigir información estructurada a un proveedor de software, su narrativa de resiliencia se queda bastante coja.

Además, muchas entidades no son simples consumidoras. Algunas distribuyen productos con elementos digitales, desde dispositivos de autenticación y apps hasta software integrado en servicios B2B. En esos casos, la frontera entre “sector regulado financiero” y “fabricante con obligaciones CRA” puede no ser tan nítida como a algunos les gustaría. El resultado práctico es el mismo: conviene elevar la madurez SBOM no solo por higiene técnica, sino por coherencia regulatoria entre DORA, gestión de terceros y respuesta a vulnerabilidades.

También hay un ángulo contractual. Las entidades financieras grandes ya están endureciendo cuestionarios a proveedores. No solo preguntan si hay pruebas de penetración o certificaciones ISO 27001; empiezan a pedir evidencia concreta sobre composición de software, proceso de parcheado y capacidad de notificar exposición a vulnerabilidades de terceros. Un proveedor que no pueda entregar un SBOM usable o que lo haga en un formato excéntrico corre el riesgo de pasar de “innovador” a “demasiado costoso de supervisar”. Y en procurement, esa etiqueta mata más rápido que muchas vulnerabilidades.

Qué no demuestra este informe, y por qué conviene no leerlo con ingenuidad

Sería tentador concluir que el mercado ya va bien encaminado y que diciembre de 2027 no plantea demasiado riesgo. No sería una lectura muy fina. El propio dato del 79% que espera alcanzar la madurez necesaria debe tomarse con cautela. Es una estimación de los encuestados, no una verificación independiente. Entre “creemos que llegaremos” y “hemos desplegado una capacidad robusta, auditada y transversal” hay una distancia considerable. En compliance tecnológico, esa distancia suele medirse en presupuestos extra, integraciones frustradas y descubrimientos tardíos.

La segunda cautela tiene que ver con sesgo de muestra. Las organizaciones que responden a encuestas de ENISA sobre SBOM probablemente ya tienen cierto grado de interés o avance en el tema. No es descabellado pensar que las empresas más rezagadas o menos expuestas ni siquiera participan. Si eso es así, la fotografía puede estar algo inclinada hacia los más concienciados. Dicho sin rodeos: la realidad del mercado podría ser menos madura que el informe sugiere.

La tercera es conceptual. Adopción no equivale a calidad. Una organización puede generar SBOM para una parte de su catálogo, con datos incompletos, sin cobertura de dependencias transitivas, sin vincularlos a builds reproducibles y sin proceso para actuar ante hallazgos. Técnicamente habría “adopción”. Operativamente, el valor seguiría siendo bastante limitado. Por eso los reguladores y los clientes más serios terminarán mirando no solo la existencia del documento, sino su utilidad demostrable en escenarios de vulnerabilidades, soporte y trazabilidad.

La siguiente batalla será la calidad del dato, no la evangelización

ENISA da por bastante asentada la dirección del viaje. Tiene razón. La discusión estratégica sobre si el SBOM merece la pena está perdiendo relevancia. La pregunta útil ahora es otra: qué hace falta para que ese inventario sea fiable, interoperable y accionable a escala.

Ahí aparecen varias batallas concretas. Una es la normalización de identificadores de componentes y la consistencia entre herramientas. Otra, la validación de completitud: cómo saber si el SBOM generado realmente representa el producto final distribuido. Otra más, la sincronización con bases de vulnerabilidades y contextos de explotabilidad. Y una especialmente ingrata, pero decisiva: la disciplina de mantenimiento a lo largo de versiones, ramas y productos heredados.

También habrá que resolver tensiones comerciales y legales. Algunos proveedores seguirán siendo reacios a compartir demasiado detalle sobre composición por temor a exponer propiedad intelectual, facilitar análisis de ataque o generar más carga contractual. Esas preocupaciones no son absurdas, pero el mercado se está moviendo en la dirección contraria. El equilibrio pasará por definir qué nivel de detalle se comparte, con quién, en qué formato y bajo qué controles. Lo que parece cada vez menos sostenible es la opacidad total.

Y luego está la pregunta de fondo: quién se responsabiliza. Porque si algo enseña el historial de la seguridad en la cadena de suministro es que las iniciativas que dependen de la buena voluntad interdepartamental suelen durar hasta el siguiente cambio de prioridades. Para que el SBOM madure de verdad, alguien tiene que medir cobertura por producto, exigir calidad mínima, conectar el inventario con remediación y reportar desviaciones a un nivel que importe. Si no toca comité, presupuesto o riesgo aceptado formalmente, la disciplina se afloja. Siempre.

Lo que deberían vigilar los equipos de seguridad y compliance entre 2026 y 2027

La consecuencia práctica del informe de ENISA no es “compra una herramienta”. Esa receta sirve para vender software, no para resolver el problema. Lo que deberían vigilar los equipos de seguridad, producto y compliance en los próximos 18 meses es bastante más concreto.

Primero, si el programa SBOM cubre productos realmente puestos en mercado y no solo repositorios cómodos o proyectos nuevos. Segundo, si la generación está automatizada en build y release. Tercero, si existe una política de calidad de datos: campos obligatorios, validaciones, gestión de errores y trazabilidad por versión. Cuarto, si el SBOM se usa de verdad cuando aparece una CVE relevante o cuando un cliente exige evidencia. Quinto, si los contratos con proveedores estratégicos ya incluyen requisitos de entrega y mantenimiento de SBOM en formatos estándar.

También merece atención la coordinación entre obligaciones regulatorias. Una empresa afectada por CRA, con exposición a NIS2 y clientes financieros bajo DORA, no debería construir tres programas paralelos de visibilidad de software. Sería carísimo y bastante absurdo. Lo sensato es diseñar una capacidad común de inventario de componentes, evaluación de vulnerabilidades, documentación técnica y gestión de terceros que luego alimente distintos marcos de cumplimiento. El regulador no siempre armoniza con la elegancia que uno querría; internamente, al menos, conviene intentarlo.

La buena noticia es que el informe de ENISA muestra movimiento real. La mala es que el mercado entra ahora en la fase menos agradable: pasar del piloto convincente a la disciplina cotidiana. Ahí desaparece la novedad y aparecen los detalles que deciden si un programa sirve o es puro teatro de conformidad.

El SBOM ya no necesita evangelistas. Necesita operadores competentes, dueños claros y métricas menos complacientes. Diciembre de 2027 está a la vuelta de la esquina en términos de ciclo de producto. Y la cadena de suministro del software tiene una costumbre fea: no perdona la improvisación, aunque la presentación al comité haya salido preciosa.