El plazo que llega antes que la norma
El 11 de septiembre de 2026 entra en aplicación el artículo 14 del Cyber Resilience Act. Desde esa fecha, todo fabricante que introduzca en el mercado de la UE un producto con elementos digitales debe notificar las vulnerabilidades explotadas activamente y los incidentes graves de seguridad: una alerta temprana en 24 horas desde que tiene conocimiento, una notificación más completa en 72 horas y un informe final en 14 días para una vulnerabilidad o en un mes para un incidente.
En la mayoría de las hojas de ruta de cumplimiento, el CRA aparece bajo el epígrafe de 2027. Ahí se concentra efectivamente el grueso del reglamento: marcado CE, requisitos esenciales de seguridad desde el diseño, documentación técnica y lista de materiales de software se aplican todos desde el 11 de diciembre de 2027. Pero la notificación va por separado y llega antes. La obligación alcanza también a los productos que ya están en el mercado, no solo a los introducidos después del plazo.
La distancia entre esas dos fechas es todo el problema. Debe notificar la explotación de un componente dieciocho meses antes de estar obligado a documentar sus componentes.
Fechas clave
El Reglamento (UE) 2024/2847 entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación del artículo 14 se aplican desde el 11 de septiembre de 2026. El resto de obligaciones, incluida la SBOM en la documentación técnica, se aplican desde el 11 de diciembre de 2027.
La Comisión publicó una guía de aplicación el 27 de julio de 2026, y el canal de notificación, la Single Reporting Platform operada por ENISA en virtud del artículo 16, debería estar disponible el mismo día en que comienza la obligación. El estado actual se sigue en la página de notificación del CRA de la Comisión.
El texto de referencia es el Reglamento (UE) 2024/2847. El artículo 14 fija las obligaciones de notificación, el artículo 16 crea la Single Reporting Platform y el anexo I, parte II regula el tratamiento de vulnerabilidades y la lista de materiales de software.
Un caso real: cómo un escáner de seguridad comprometió una pasarela de IA
En marzo de 2026 el grupo TeamPCP comprometió LiteLLM, una pasarela de IA de código abierto muy extendida que actúa también como proxy. Dos versiones maliciosas, 1.82.7 y 1.82.8, llegaron a PyPI. Estuvieron disponibles unos cuarenta minutos.
Lo relevante es cómo llegaron hasta ahí. LiteLLM nunca fue el objetivo directo. Su cadena de compilación instalaba el escáner de vulnerabilidades Trivy sin fijarlo a una versión verificada, y el propio proceso de publicación de Trivy llevaba ya unos veinte días comprometido. El escáner manipulado entró en la compilación de LiteLLM y produjo paquetes de LiteLLM manipulados. CloudSEK identificó la misma campaña en una tercera herramienta, Checkmarx KICS.
Leído en clave de controles: la herramienta encargada de encontrar vulnerabilidades en la cadena de compilación era la vulnerabilidad de esa cadena. Estaba dentro del perímetro de confianza, se ejecutaba con las credenciales del pipeline y quedaba fuera del escrutinio aplicado a las dependencias de aplicación porque se clasificaba como herramienta y no como código.
Un diagrama que muestra cómo una única credencial no revocada se propagó a través de tres herramientas. TeamPCP compromete el proceso de publicación del escáner Trivy, punto de entrada que pasó inadvertido unos veinte días. La cadena de integración continua de LiteLLM instala automáticamente la versión comprometida de Trivy al no fijar la versión, lo que produce una compilación manipulada. Los paquetes LiteLLM 1.82.7 y 1.82.8 llegan a PyPI y permanecen unos 40 minutos. Alcanzan unos 434.000 procesos de CI/CD en más de 2.500 organizaciones y recogen claves de nube, tokens de repositorio y claves de servicios de IA. Las credenciales recogidas siguen siendo válidas después de retirar los paquetes.
El código malicioso se ejecutaba en cada invocación de Python y no en el momento de la importación, por lo que no necesitaba que una aplicación usara realmente la biblioteca. Se ejecutaba en cualquier sitio donde aterrizara el paquete: agentes de compilación, imágenes de contenedor, contenedores de trabajo efímeros, portátiles de desarrollo, capas en caché. Recogía todas las credenciales a las que ese proceso podía llegar.
El conjunto de datos de exposición reconstruido por CloudSEK vincula a la ruta afectada más de 2.500 organizaciones y unas 434.000 ejecuciones de procesos de CI/CD. La empresa señala expresamente que una coincidencia de alta confianza acredita exposición y no prueba ni que una organización concreta fuera comprometida ni que se sustrajeran datos. Conviene mantener esa distinción al informar a un consejo de administración.
Los cuarenta minutos son la cifra engañosa
Una ventana de publicación corta limita cuántas compilaciones descargaron el paquete. No limita en absoluto la vida útil de las credenciales sustraídas. El aviso FLASH del FBI de julio de 2026 (FLASH-20260702-01) advierte de que los actores vinculados a esta campaña probablemente utilizarán las credenciales recogidas mucho después de la intrusión inicial.
La pregunta de contención va menos sobre si instalamos LiteLLM 1.82.7 durante la ventana de cuarenta minutos y más sobre qué credenciales podía leer cualquier proceso en cualquier agente que tocara esa ruta de dependencias, y si se han rotado todas. Son investigaciones muy distintas, y solo la segunda cierra la exposición.
Por qué esto es un asunto del CRA y no solo de respuesta a incidentes
Si su organización solo consume software, la cascada de LiteLLM es un incidente de seguridad y quizá un asunto de NIS 2. Si su organización entrega software, incluido el software que vende, integra, licencia o distribuye como parte de un producto conectado, es además una obligación de notificación con un reloj en marcha.
Según el CRA, fabricante es quien desarrolla un producto con elementos digitales y lo introduce en el mercado de la UE con su propio nombre o marca. El tamaño de la empresa es irrelevante. Si usted lo desarrolla y lo vende, es fabricante, y esa es la figura con las obligaciones más exigentes. El SaaS puramente de navegador suele quedar fuera del CRA y dentro de NIS 2, pero la frontera es más estrecha de lo que muchos equipos suponen en cuanto se entrega un agente, un SDK, un complemento, una aplicación móvil o firmware.
A ello se suma un deber hacia arriba que encaja exactamente con la cadena de LiteLLM: el fabricante que detecta una vulnerabilidad en un componente de terceros integrado en su producto debe informar a la entidad que mantiene ese componente. En una cascada de tres saltos, la organización mejor situada para detectar el compromiso puede estar cuatro dependencias más abajo.
Qué exige cada régimen, y en cuánto tiempo
Régimen: CRA, art. 14
Régimen: NIS 2, art. 23
Régimen: DORA, art. 19
Régimen: RGPD, art. 33
El solapamiento es la trampa operativa. Un solo episodio de robo de credenciales en una cadena de compilación puede activar de forma plausible tres de esos cuatro regímenes a la vez, con tres plazos distintos, ante tres autoridades distintas y con tres definiciones de gravedad distintas. Las organizaciones que tratan la notificación del CRA como un proceso nuevo e independiente incumplirán plazos, mientras que las que amplían un procedimiento existente de clasificación y notificación de incidentes no lo harán.
La mirada del experto: Alexis Hirschhorn
El fallo se sitúa casi siempre antes de la plantilla de notificación, en el paso de clasificación que la alimenta. Los equipos que ya siguen un proceso riguroso de clasificación de incidentes conforme a ISO/IEC 27035 absorben el artículo 14 como una vía de notificación más, mientras que los que no lo tienen descubren el primer día que nadie puede decir, en 24 horas, si una vulnerabilidad se está explotando activamente. Ese juicio es toda la obligación.
El reloj de 24 horas empieza cuando usted tiene conocimiento y no cuando termina la investigación. Diseñe el proceso para que ese momento quede definido, registrado y con responsable, o acabará reconstruyéndolo después ante una autoridad.
La SBOM que formalmente no necesita hasta 2027 y realmente necesita en septiembre
El anexo I, parte II, punto 1 del CRA exige a los fabricantes identificar y documentar los componentes de sus productos, entre otras cosas elaborando una lista de materiales de software en un formato legible por máquina de uso común, que cubra al menos las dependencias de primer nivel. Ese requisito se aplica desde diciembre de 2027.
La obligación de septiembre de 2026 la convierte de hecho en un requisito de 2026. El artículo 14 pide notificar en 24 horas una vulnerabilidad explotada activamente que afecte a su producto. Cuando un compromiso aparece en una biblioteca situada tres niveles por debajo en el árbol de dependencias, la única forma de responder dentro de esa ventana a qué productos y qué versiones contienen ese componente es haberlo respondido antes.
Las dependencias de primer nivel son el mínimo declarado, no un objetivo seguro. La cascada de LiteLLM habría sido invisible en una SBOM de un producto aguas abajo limitada al primer nivel: Trivy era herramienta de compilación y no dependencia de aplicación, y el propio LiteLLM podía ser transitivo. Si su inventario se detiene en las dependencias directas, no responde a la pregunta que plantea el reglamento.
SBOM
Inventario legible por máquina de los componentes de un software, con información de versión y proveedor. CycloneDX y SPDX son los dos formatos de uso común. La guía técnica BSI TR-03183-2 detalla una interpretación técnica de las expectativas del CRA y es hoy la referencia más concreta disponible.
Cuatro huecos que rompen la cobertura de la SBOM en la práctica
Las herramientas de compilación no figuran en la SBOM. Escáneres, linters, formateadores, marcos de pruebas y automatización de publicación se ejecutan con las credenciales del pipeline y suelen quedar completamente fuera de los inventarios de dependencias. Ese es exactamente el hueco que aprovechó TeamPCP.
La SBOM describe la entrega, no el entorno de compilación. Dos artefactos con una lista de materiales idéntica pueden proceder de cadenas con exposiciones muy distintas, porque el compromiso se produjo en el entorno y no en el código entregado.
Las cachés y las imágenes base se desvían del manifiesto. Una dependencia fijada en un fichero de bloqueo no equivale a una dependencia fijada en la capa que realmente se ejecutó, en cuanto entran en juego imágenes base, agentes efímeros y cachés calientes.
Nadie se responsabiliza de su actualidad. Una SBOM generada en la entrega y nunca regenerada responde a una pregunta sobre el pasado. El reloj de 24 horas plantea una pregunta sobre el presente.
Ámbito de aplicación: tres preguntas que lo resuelven
¿Introduce en el mercado de la UE un producto con elementos digitales con su propio nombre o marca? Si la respuesta es sí, usted es fabricante y el artículo 14 se le aplica desde el 11 de septiembre de 2026, también para los productos ya vendidos.
¿Sigue el producto en el mercado de la UE en esa fecha o después? Los productos existentes entran en la obligación de notificación. Los requisitos esenciales, más exigentes, solo los alcanzan cuando se produce una modificación sustancial, desde diciembre de 2027.
¿Queda realmente fuera del ámbito? El SaaS puramente de navegador suele quedar fuera del CRA, y el software libre no comercial está excluido, aunque el reglamento crea la figura atenuada del administrador de software libre en lugar de una exclusión general, y aunque el suministro comercial de componentes de código abierto vuelve a incluirle. Quedar fuera del CRA suele significar quedar dentro de NIS 2, de modo que esta vía rara vez lleva a no tener ninguna obligación.
Sanciones
Los incumplimientos de los requisitos esenciales o de las obligaciones del fabricante se sancionan con multas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, si esta cifra es superior.
El reloj del artículo 14, de principio a fin
La notificación se dirige al CSIRT designado como coordinador en el Estado miembro donde tenga su establecimiento principal, y se pone a disposición de ENISA al mismo tiempo. Se notifica una sola vez, a través de la Single Reporting Platform, y no por separado ante cada autoridad.
Conviene fijarse en lo que el artículo 14 no exige. No es un deber de notificar cada CVE. Alcanza a las vulnerabilidades que se están explotando activamente y a los incidentes graves que afectan a la seguridad del producto. El CRA tampoco obliga por sí mismo a informar a los clientes empresariales, pero revise sus contratos, porque los clientes lo imponen cada vez más por vía contractual y con plazos más cortos que el reglamento.
La corrección no forma parte de la obligación de septiembre
El deber de corregir y distribuir actualizaciones de seguridad durante el periodo de soporte se aplica desde el 11 de diciembre de 2027. Desde septiembre de 2026 hay que notificar, y notificar una vulnerabilidad que aún no se puede corregir es el caso esperado. No retrase una notificación mientras espera un parche.
Donde el CRA se encuentra con NIS 2 y la cadena de suministro
El artículo 21, apartado 2, letra d) de NIS 2 ya obliga a las entidades esenciales e importantes a adoptar medidas sobre la seguridad de la cadena de suministro, incluidos los aspectos de seguridad de las relaciones con proveedores directos y prestadores de servicios. El CRA aborda el mismo riesgo por el otro extremo: regula qué deben construir y divulgar esos proveedores.
Para la mayoría de las organizaciones se aplican ambos, en papeles distintos. Usted es una entidad NIS 2 que gobierna a sus proveedores y un fabricante CRA gobernado por sus clientes. Las evidencias se solapan en buena medida: inventario de componentes, proceso de evaluación de proveedores, procedimiento de tratamiento de vulnerabilidades y manual de notificación, siempre que se hayan diseñado una vez y no tres.
Aquí es donde ISO 28000 demuestra su valor. La norma aporta un sistema de gestión de la seguridad en la cadena de suministro, que es justamente la estructura que falta en la mayoría de las organizaciones cuando intentan responder de forma coherente a las preguntas de riesgo de proveedor entre compras, ingeniería y cumplimiento. La alternativa, una hoja de cálculo con cuestionarios de proveedores, no sobrevive a una cascada como la de LiteLLM, porque la parte comprometida nunca había sido evaluada como proveedor por nadie.
De la obligación a la capacidad, y de la capacidad a la certificación
Obligación: Clasificar y notificar en 24 h
Obligación: Conocer los propios componentes
Obligación: Gobernar el riesgo de proveedor y componente
Obligación: Cumplir NIS 2, art. 21.2 d)
Obligación: Asumir el programa de extremo a extremo
Un plan de preparación en 30 días
El objetivo realista antes del 11 de septiembre no es el cumplimiento completo del CRA. Es poder emitir una notificación defendible dentro de plazo. Ese alcance es mucho menor y sigue siendo alcanzable en el tiempo disponible.
- Determinar si es fabricante según el CRA y enumerar todos los productos que sigan en el mercado de la UE y entren en el ámbito de aplicación
- Identificar su CSIRT coordinador, el del Estado miembro de su establecimiento principal, y registrarse en la Single Reporting Platform
- Definir y documentar el momento del conocimiento: quién puede declararlo, cómo se registra y qué pone en marcha el reloj de 24 horas
- Designar por nombre a un responsable y a un suplente para la notificación, con cobertura fuera del horario laboral
- Generar una SBOM para cada producto en el ámbito, en CycloneDX o SPDX, incluyendo las herramientas de compilación además de las dependencias de aplicación
- Conectar la SBOM a una fuente de vulnerabilidades para responder en minutos a qué productos contienen el componente X
- Redactar la regla de clasificación que distingue una vulnerabilidad explotada activamente de una CVE ordinaria, y probarla con un caso real
- Encajar la notificación del CRA en sus vías de incidente de NIS 2, DORA y RGPD para que un episodio no dispare tres procesos descoordinados
- Establecer la vía de información hacia arriba para vulnerabilidades detectadas en componentes de terceros
- Realizar un ejercicio de mesa con la cascada de LiteLLM como escenario y cronometrarse hasta la marca de las 24 horas
El ejercicio de mesa es el paso que los equipos se saltan y el que encuentra los huecos reales. Realícelo con el escenario tal y como aparece de verdad: un aviso público nombra un paquete que usa su cadena de compilación, usted aún no sabe si llegó a producción y el reloj ya corre.
Empiece por el inventario de credenciales, no por el de dependencias
En esta clase de ataque la exposición la define lo que un proceso comprometido pudo leer, no lo que importó. Enumere qué credenciales son accesibles desde cada agente de compilación: claves de nube, tokens de registro, tokens de control de código, claves de modelos y de API, y todo lo que pueda obtenerse de un servicio de metadatos de instancia. Esa lista es a la vez el alcance de su investigación y su mejora de control más eficaz.
Qué conviene retener
Pese al enfoque que ha recibido, el compromiso de LiteLLM es menos una historia sobre IA que sobre una cadena de compilación que confiaba en sus propias herramientas, una credencial no revocada y una cadena de dependencias que nadie había cartografiado. La capa de IA solo lo agravó, porque las pasarelas de IA se sitúan inusualmente cerca de las credenciales de cuentas en la nube, proveedores de modelos y bases vectoriales.
Lo que cambia el 11 de septiembre de 2026 es que el mismo episodio conlleva ahora un deber de notificación en 24 horas para cualquiera que entregue software en la UE. El reglamento le pide que sepa rápido si la cascada le alcanzó y que lo diga, más que evitarla.
Es un problema de inventario de componentes y de clasificación de incidentes mucho antes de ser un problema regulatorio. Las organizaciones que ya practican ambas cosas como disciplinas vivirán el artículo 14 como una adición menor. Las demás disponen de unos treinta días.
