Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Desde el 11 de septiembre de 2026, el artículo 14 de la CRA le obliga a notificarlo en un plazo de 24 horas desde que tenga conocimiento de que existe una vulnerabilidad que está siendo explotada activamente en su producto.
- Una SBOM de nivel superior, es decir, la mínima del anexo I, no detectará un paquete que se encuentre varios niveles más abajo; en cambio, sí lo hará un inventario a nivel de versión de cada compilación distribuida.
- Una adaptación hacia atrás compatible de la versión que ya utilizas soluciona una dependencia oculta sin modificar todo lo que hay por encima de ella.
- El periodo de soporte de CRA es más largo que el del mantenimiento del proyecto original, por lo que cada versión del paquete necesita una ruta de correcciones que continúe tras el fin de vida útil del proyecto original.
Un martes aparece una nueva entrada en el catálogo KEV de la CISA. En ella se identifica una vulnerabilidad que se está explotando activamente en un paquete que nadie de tu equipo eligió, situado tres niveles más abajo en un árbol de dependencias que nadie creó intencionadamente. En un plazo de 24 horas, alguien de tu empresa debe determinar si ese paquete está incluido en una versión que hayáis lanzado y si es necesario informar a vuestro CSIRT y a la ENISA.
Así es el artículo 14 de la Ley de Ciberresiliencia de la UE (CRA) desde dentro. Los plazos son cortos y el umbral de aplicación es más restrictivo de lo que sugieren la mayoría de los resúmenes, pero lo que realmente supone un problema rara vez es la notificación en sí misma. Lo difícil es determinar qué contiene realmente la versión mientras el tiempo corre.
El reloj de 24 horas de la CRA sigue en marcha
Desde el 11 de septiembre de 2026, está en vigor el artículo 14 de la CRA. Se trata del primer requisito de notificación de la CRA que recae sobre los fabricantes, y el plazo es estricto. Una vez que se tenga conocimiento de que una vulnerabilidad de su producto está siendo explotada de forma activa, dispone de 24 horas.
La CRA utiliza el término «fabricante» para referirse a una organización o persona que desarrolla un producto con elementos digitales, o encarga su desarrollo, y lo comercializa en el mercado de la UE bajo su propio nombre o marca comercial en el marco de una actividad comercial. La actividad comercial no se limita únicamente a cobrar un precio. La asistencia técnica de pago se considera tal cuando supone más que la mera recuperación de los costes reales. Lo mismo ocurre con la monetización a través de una plataforma o con el hecho de exigir a los usuarios que faciliten datos personales por motivos que vayan más allá de mejorar la seguridad, la compatibilidad o la interoperabilidad del software. Si ese es el caso de tu empresa y tu producto se distribuye como código abierto, el artículo 14 ya te concierne.
El artículo 14 establece tres plazos de notificación. Cada notificación se envía a través de la Plataforma Única de Notificación de la ENISA al CSIRT designado como coordinador —normalmente el correspondiente a su sede principal— y a la propia ENISA, la agencia de ciberseguridad de la UE.
La primera es la notificación de alerta temprana de 24 horas. En un plazo de 72 horas, se envía una notificación más detallada sobre la vulnerabilidad. A más tardar 14 días después de que esté disponible una medida correctiva o de mitigación —término que utiliza la CRA para referirse a una solución o una solución alternativa—, se envía un informe final. Los plazos de 24 y 72 horas son límites máximos, no períodos de espera. El texto dice «sin demora indebida y, en cualquier caso, dentro de» dichos plazos.
La expresión «explotada activamente» tiene un significado preciso. Debe existir evidencia fiable de que un actor malintencionado haya explotado la vulnerabilidad en un sistema sin el permiso del propietario del mismo. No basta con que se haya publicado un CVE. Tampoco basta con una prueba de concepto. El artículo 14 también abarca los incidentes graves que afectan a la seguridad de un producto. Estos se tratan por una vía independiente, y el informe final debe presentarse un mes después de la notificación del incidente. Este artículo trata sobre las vulnerabilidades y el aspecto de las dependencias de código abierto de la CRA. La evaluación de riesgos, la evaluación de la conformidad y las demás obligaciones del fabricante quedan fuera de su ámbito de aplicación.
El plazo de cumplimiento de la CRA para las obligaciones restantes de los fabricantes, así como para las multas, vence el 11 de diciembre de 2027. El artículo 14 ya está en vigor y se aplica a los productos comercializados en el mercado de la UE antes de esa fecha.
Fundamento jurídico: artículo 14, apartados 1, 2, 4 y 7; artículo 3, apartados 13 y 42; artículo 64; artículo 71, apartado 2; artículo 69, apartado 3; considerandos 15 y 18.
Por qué una SBOM de nivel superior no te permite saber si te ves afectado
La información que indica que se está explotando una vulnerabilidad suele llegar desde el exterior: una entrada en el catálogo de vulnerabilidades explotadas conocidas (KEV) de la CISA, un aviso de un proveedor o un responsable de mantenimiento, o un mensaje de un CSIRT, un investigador o un cliente. A partir de ahí, suceden tres cosas. Te enteras de que se está explotando una vulnerabilidad en algún lugar. Averiguas si tu producto se ve afectado. A continuación, identificas qué versiones y qué usuarios se ven afectados.
El plazo comienza a contar desde el momento en que tienes conocimiento de una vulnerabilidad que se está explotando activamente en tu producto, así que empieza a evaluar de inmediato las alertas fiables. El hecho de que el nombre del paquete coincida no significa por sí solo que tu producto se vea afectado, y disponer de un inventario preciso es lo que te permite aclararlo rápidamente. En la práctica, los pasos se solapan, y no hay que esperar a tener una lista completa de usuarios antes de enviar una alerta temprana a medida que se acerca la fecha límite.
El paquete mencionado en la alerta suele ser una dependencia transitiva, incorporada por una de tus dependencias directas y que nadie de tu equipo ha elegido. Log4Shell (CVE-2021-44228) es el caso habitual. log4j-core Estaba presente en muchas aplicaciones como dependencia de marcos de trabajo y conectores, y la primera tarea de la mayoría de los equipos consistía en averiguar si lo tenían o no.
Aquí es donde entra en juego el requisito de inventario de la CRA. El anexo I exige a los fabricantes que identifiquen y documenten los componentes de un producto, entre otras cosas, elaborando una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina. El nivel mínimo de detalle es «como mínimo, las dependencias de nivel superior». Ese mínimo es razonable. Sin embargo, tampoco es suficiente para responder a la cuestión de las 24 horas.
Una SBOM de nivel superior registra directamente lo que has añadido. La cuestión que se plantea es si una versión concreta de un paquete específico aparece en alguna parte del producto, y hay tres lugares donde buscar.
Tu manifiesto, ya sea que se trate de package.json, pom.xmlo requirements.txt, enumera las dependencias que has declarado, a menudo como rangos de versiones. Tu archivo de bloqueo registra el grafo de dependencias resuelto para una compilación, aunque lo que finalmente se distribuye puede variar debido a dependencias específicas de la plataforma y opcionales, las herramientas de compilación, el uso de «vendoring» y cualquier regeneración del archivo de bloqueo que se produzca durante el proceso. Tu inventario de lanzamiento muestra lo que contiene el artefacto distribuido: las versiones resueltas de los componentes, cualquier elemento incluido o gestionado mediante «vendoring» en el artefacto, y ninguna de las dependencias de desarrollo que nunca salen de tu compilación.
El archivo de bloqueo es un dato imprescindible, pero no demuestra qué se ha distribuido. Para saber si la vulnerabilidad notificada se encuentra en una versión concreta, necesitas el inventario de versiones.
Hay un problema más para todo aquello que haya superado su fin de vida útil según el proyecto original. Cuando se corrige una vulnerabilidad, el aviso suele decir algo así como «corregido en la versión 4.2; las ramas más antiguas ya no reciben soporte». Es muy posible que la versión 3.x de tu árbol se vea afectada, pero es posible que el proyecto original nunca lo indique, ya que allí ya nadie se ocupa de esa rama. El análisis recae en ti.
Fundamento jurídico: artículo 14, apartado 1; artículo 3, apartado 42; anexo I, parte II, punto 1.
Por qué el hecho de «no saberlo» no te exime de responsabilidad
El plazo previsto en el artículo 14 no comienza a contar hasta que se tenga conocimiento de una vulnerabilidad de su producto que esté siendo explotada activamente. Se trata de un límite muy restringido que se basa en un único factor desencadenante y que no aborda en absoluto el resto de la CRA.
A partir del 11 de diciembre de 2027, se aplicarán las obligaciones más amplias de la CRA. En el caso de los productos comercializados antes de esa fecha, las normas transitorias establecen que dichas obligaciones serán de aplicación cuando el producto sufra una modificación sustancial a partir de esa fecha. Dichas obligaciones le exigen identificar y documentar los componentes y las vulnerabilidades de su producto, así como realizar pruebas y revisiones de seguridad eficaces y periódicas. Se exige la debida diligencia a la hora de incorporar componentes de terceros, incluidos los de código abierto. Además, se le exige gestionar eficazmente las vulnerabilidades del producto, «incluidos sus componentes», durante todo el periodo de soporte.
El hecho de que su proceso de fabricación haya omitido un componente no demuestra, por sí solo, que su proceso sea deficiente. Sin embargo, sí puede llevar a una autoridad a examinar si la identificación de componentes y la gestión de vulnerabilidades son adecuadas. Estas obligaciones se encuentran en el nivel más alto de multas de la CRA, que asciende a un máximo de 15 millones de euros o al 2,5 % de la facturación anual total mundial de su empresa correspondiente al ejercicio financiero anterior, el que sea mayor. Las autoridades de vigilancia del mercado también pueden ordenar medidas correctivas, restringir o prohibir las ventas, o exigir una retirada del mercado o una recuperación del producto.
La fecha de entrada en vigor aún queda lejos. La próxima alerta, en cambio, no. Si tu herramienta no ha detectado un paquete, las primeras horas de un plazo de 24 horas se dedican a determinar si ese paquete se encuentra siquiera en tu pila, lo que deja mucho menos tiempo para todo lo demás que requiere el informe.
Fundamento jurídico: Anexo I, Parte II, apartados 1 y 3; artículo 13, apartados 5 y 8; artículo 54; artículo 64, apartado 2; artículo 69, apartado 2.
Ahora arréglalo sin estropear todo lo que hay encima
La notificación de 72 horas solicita la información de la que dispones hasta el momento: datos generales sobre el producto, la naturaleza general del exploit y de la vulnerabilidad, las medidas correctivas o de mitigación que hayas tomado y las medidas que puedan adoptar tus usuarios. No es necesario disponer de un parche terminado para enviarla. Sin embargo, en el caso de una dependencia transitiva tres niveles más abajo, sigue siendo necesario dedicar esfuerzo a definir dichas medidas.
Piensa en la situación habitual. La corrección existe en la versión 4.2 del proyecto original. El paquete intermedio de tu árbol se ha quedado estancado en la línea 3.x, y su responsable de mantenimiento no lo ha actualizado. Ninguna de tus opciones es gratuita. Puedes esperar a que actúe el responsable de mantenimiento. Puedes forzar una anulación en tu archivo de bloqueo y aceptar el riesgo de que algo por encima de él deje de funcionar. Puedes actualizar el paquete intermedio a una versión principal que sea compatible con la 4.2 e incluir cualquier cambio no relacionado que venga con ella como parte de una versión de seguridad. Puedes sustituir el componente o aplicar un parche tú mismo. O bien, puedes conseguir un backport compatible, que es la corrección de seguridad aplicada a la rama 3.x que ya utilizas.
A partir de diciembre de 2027, el Anexo I establece dos requisitos al respecto. Es necesario abordar y subsanar las vulnerabilidades sin demora. Y, cuando sea técnicamente viable, se deben distribuir las actualizaciones de seguridad por separado de las actualizaciones de funcionalidades. La CRA no prescribe qué vía se debe seguir. También permite proporcionar la actualización de seguridad únicamente para la versión más reciente, siempre y cuando los usuarios de versiones anteriores puedan actualizarse a ella de forma gratuita y no tengan que incurrir en costes adicionales para adaptar su entorno.
Una adaptación hacia atrás compatible se ajusta a esa separación y reduce al mínimo el trabajo de migración. Se trata de una compilación fija de la versión que ya tienes en tu árbol, compatible con sus dependencias, en la que los paquetes dependientes se vuelven a compilar según sea necesario. Si se hace correctamente, tus propios manifiestos no se modifican y las pruebas de compatibilidad solo se realizan una vez en tu producto.
Cuando una adaptación a versiones anteriores incluye una fecha de entrega confirmada, dispones de un plazo concreto para la corrección que puedes comunicar junto con las medidas que ya has tomado. El resto depende de ti: integrar el componente parcheado, probarlo y lanzarlo como una actualización de tu producto. Cuanto antes llegue el componente, más margen de tiempo tendrás para hacerlo.
Fundamento jurídico: artículo 14, apartado 2, letra b); anexo I, parte II, punto 2; artículo 13, apartado 10; artículo 69, apartado 2.
El informe final se elabora una vez realizada la reparación, y la obligación se prolonga durante años.
El informe final debe presentarse a más tardar 14 días después de que esté disponible una medida correctiva o de mitigación. En él se describe la vulnerabilidad, su gravedad e impacto, lo que se sabe sobre el atacante y la actualización de seguridad u otras medidas que se hayan puesto a disposición.
Por otra parte, una vez que se tenga conocimiento de la vulnerabilidad, se debe informar a los usuarios afectados y, cuando proceda, a todos los usuarios. El aviso debe indicarles qué pueden hacer para mitigar o solucionar el problema. Cuando proceda, se enviará en un formato estructurado y legible por máquina. La CRA no prescribe ninguno en concreto. El CSAF es el formato de aviso legible por máquina más utilizado, y las declaraciones VEX, que indican si una vulnerabilidad afecta a un producto concreto, pueden expresarse como CSAF VEX, CycloneDX VEX u OpenVEX.
A partir de diciembre de 2027, la propia actualización también deberá distribuirse de forma segura, sin demora y de forma gratuita.
Luego viene la «cola larga», donde la lógica del código abierto deja de jugar a tu favor.
Mientras dure el periodo de soporte, deberás seguir solucionando las vulnerabilidades del producto. Usted mismo establece el periodo de soporte, pero este debe reflejar el tiempo que se prevé que el producto esté en uso y ser de al menos 5 años, a menos que se prevea que el producto se utilice durante menos tiempo. Además, cada actualización de seguridad que publique durante el periodo de soporte debe permanecer disponible durante al menos 10 años tras su publicación, o hasta el final del periodo de soporte, lo que sea posterior, de modo que un usuario que actualice tarde pueda seguir obteniéndola.
El mantenimiento de la versión original de un paquete puede finalizar mucho antes de que termine tu periodo de soporte. Cuando esto ocurra, la CRA seguirá exigiéndote que respetes dicho periodo. No estás obligado a mantener esa versión concreta, ya que sustituir o actualizar un componente puede ser una solución válida. Sí que estás obligado a seguir solucionando las vulnerabilidades de tu producto, por cualquier medio, durante todo el periodo de soporte.
Fundamento jurídico: artículo 14, apartados 2, letra c), y 8; anexo I, parte II, puntos 7 y 8; artículo 13, apartados 8 y 9; artículo 69, apartado 2.
Nadie en la cadena de suministro comparte tu reloj
La CRA exime deliberadamente al software libre y de código abierto desarrollado o suministrado al margen de una actividad comercial de las obligaciones del fabricante.
Se crea una categoría independiente, la de «gestor de software de código abierto», para las personas jurídicas que prestan apoyo continuado al desarrollo de software de código abierto destinado a actividades comerciales. Los gestores se acogen a un régimen más flexible y adaptado a sus necesidades, que entrará en vigor en diciembre de 2027, con obligaciones limitadas en virtud del artículo 14 en circunstancias definidas. Los mantenedores individuales de la comunidad no son automáticamente fabricantes ni gestores.
Sean cuales sean sus obligaciones y compromisos de asistencia, son distintos de los tuyos y no te eximen de los tuyos. El artículo 13, apartado 6, lo deja claro. Cuando detectes una vulnerabilidad en un componente que distribuyes, debes notificársela a la persona o entidad que fabrica o mantiene dicho componente, corregirla en tu producto independientemente de si responden o no, y compartir el código o la documentación pertinentes si has desarrollado una solución. Puedes aplicar un parche, sustituir o actualizar el componente. Lo que no puedes hacer es permitir que la inacción de los responsables anteriores justifique el retraso de tu propia respuesta.
Estas obligaciones del artículo 13 entrarán en vigor a partir del 11 de diciembre de 2027. La lección práctica ya es válida en la actualidad. En el caso del código que se encuentra en lo más profundo de tu árbol de código, que no has escrito tú y que quizá nunca hayas leído, la responsabilidad de resolver la vulnerabilidad de tu producto sigue recayendo en ti, incluso cuando el desarrollador original no te ayude.
Fundamento jurídico: artículo 24; artículo 3, apartado 14; artículo 13, apartado 6; artículo 69, apartado 2; considerandos 18 y 19.
Qué tiene que ver una respuesta viable
La CRA te da margen para decidir cómo abordar el cumplimiento del artículo 14. A continuación se presenta un conjunto de recomendaciones prácticas para el código abierto de tu producto. Son especialmente importantes cuando mantener la compatibilidad con las versiones existentes te ahorra trabajo de migración.
Empieza por realizar un inventario a nivel de versión de todo lo que contiene el producto, hasta la última dependencia transitiva, registrado como versiones resueltas y asignado a lo que realmente se incluye en cada versión del producto. De este modo, la pregunta de las 24 horas se responde a partir de los registros, en lugar de a partir de un análisis que hayas puesto en marcha tras recibir la alerta.
A continuación, necesitas que las correcciones lleguen a tiempo, incluyendo adaptaciones compatibles para las versiones que ya están en tu árbol y en las que no resulta práctico actualizar, con los paquetes dependientes recompilados según sea necesario. De este modo, los cambios de seguridad pueden distribuirse por separado de los cambios de funcionalidad, y el trabajo de migración se mantiene reducido. Esa vía de correcciones también debe continuar tras el fin de vida útil del paquete por parte del desarrollador original, durante todo tu periodo de soporte y no solo mientras el mantenedor tenga interés en ello.
Los dos últimos se refieren a lo que sale de tu edificio. Los usuarios afectados deben recibir una notificación inmediata, en formatos legibles por máquina cuando sea pertinente, y actualizaciones de seguridad que permanezcan disponibles durante al menos 10 años tras su publicación, o durante el resto del periodo de soporte si este es más largo. Además, es necesario que la cobertura sea equivalente en todos los ecosistemas lingüísticos de tu producto, ya que al artículo 14 no le importa de dónde provenga un componente.
La mayoría de las obligaciones restantes de los fabricantes, así como las medidas de cumplimiento correspondientes, entrarán en vigor a partir del 11 de diciembre de 2027. La obligación de presentación de informes ya está en vigor. Los meses que quedan hasta entonces son el momento de poner en marcha esas capacidades.
El papel de SecureChain y el soporte de ciclo de vida ilimitado
SecureChain y el servicio Endless Lifecycle Support (ELS) de TuxCare se basan en esas capacidades, en el mismo orden.
Primero, el inventario. Los paquetes de código abierto se incorporan a tu producto a través del catálogo de SecureChain, que realiza un seguimiento de las versiones de los paquetes que gestiona y publica SBOM legibles por máquina para ellos —incluido CycloneDX—, con los detalles de las dependencias incluidos. Esa es la parte de los componentes de tu inventario de versiones. Lo vinculas a tus registros de compilación y a los artefactos distribuidos, y a partir de ahí, determinar si el componente afectado está presente es una simple consulta en lugar de un trabajo laborioso. Cuando se confirma una vulnerabilidad, TuxCare publica los datos de la misma para que puedas cotejarlos con las versiones de los paquetes de ese inventario.
A continuación, las correcciones. Mientras el desarrollador original siga distribuyéndolas, SecureChain las recompila desde el código fuente y ofrece sustitutos directos para las versiones de los paquetes compatibles que ya ejecutas. Cuando el desarrollador original deja de ofrecer actualizaciones, SecureChain aplica los parches al propio paquete y lo mantiene compatible. Cuando se corrige una dependencia oculta, los paquetes dependientes se recompilan con la corrección, lo que evita que tus propios manifiestos se vean afectados. La aplicación de parches se ajusta a los tiempos de respuesta objetivo publicados según la gravedad, tal y como se establece en la ficha técnica de cobertura del ciclo de vida. Esto proporciona a tu notificación de 72 horas un plazo concreto que comunicar, junto con las medidas ya adoptadas y las soluciones de mitigación disponibles para tus usuarios. La integración, las pruebas y el lanzamiento de la actualización como si fuera propia siguen siendo responsabilidad tuya.
A continuación viene la parte en la que el desarrollador original deja de intervenir. Cuando el desarrollador original deja de corregir una versión, ya sea por no cumplir un plazo de CVE o por no lanzar ninguna versión durante nueve meses, SecureChain sigue aplicando parches durante tres meses más. A partir de ahí, el «Soporte de ciclo de vida ilimitado» toma el relevo y adapta las correcciones a versiones anteriores mientras se utilice esa versión, es decir, durante todo el tiempo que exija tu propio periodo de soporte.
Los avisos y las actualizaciones se publican a través del portal de seguridad de TuxCare en forma de documentos CSAF y VEX, con fuentes RSS y metadatos firmados, listos para vincularse a tus propias versiones afectadas y avisos a los usuarios. TuxCare es también una Autoridad de Numeración CVE (CNA), por lo que puede asignar identificadores CVE a las vulnerabilidades que entran dentro de su ámbito de competencia y publicarlos en sus avisos, en lugar de tener que esperar en una cola detrás de otros.
El modelo abarca JavaScript, Python, Java, Go, Rust y PHP. Un único catálogo, un único modelo SBOM y un único modelo de corrección, independientemente del ecosistema del que proceda un paquete.
TuxCare es un fabricante a todos los efectos, en virtud del CRA, para los productos que comercializa en el mercado de la UE, por lo que se le aplican las mismas obligaciones del artículo 14, junto con la obligación establecida en el artículo 13, apartado 6, de notificar las vulnerabilidades de los componentes a los proveedores anteriores y compartir las correcciones. Lo que estos dos productos cambian para usted es el tiempo que se dedica, dentro del plazo comprendido entre una alerta y una versión corregida, a esperar a que se solucione el problema de un componente de terceros, así como la calidad del informe que puede presentar mientras el plazo sigue corriendo.
Antes de la próxima alerta
Puedes probar la mayor parte de esto en una tarde. Elige una versión actual y una alerta, ya sea real o hipotética. Log4Shell servirá si te ha afectado. De lo contrario, imagina una entrada KEV para una biblioteca situada tres niveles más abajo en tu árbol. A continuación, sigue la ruta que seguiría la alerta a través de tu empresa y responde a cada pregunta basándote en la última vez que ocurrió realmente, o utilizando una estimación realista si nunca ha ocurrido antes.
¿Se indica en vuestro inventario de versiones si el paquete está incluido en esa compilación? ¿De dónde vendría la corrección y hay alguien que se haya comprometido a una fecha para ello? ¿Cuánto tiempo tardó vuestra última versión de seguridad, desde el componente parcheado hasta la actualización distribuida? ¿Cómo se enterarían vuestros usuarios de ello? Allí donde no tengáis respuesta es donde la próxima alerta encontrará primero una brecha.
Alguien de tu empresa es el responsable durante las 24 horas siguientes a la recepción de esa alerta. El simulacro te indica si esa persona podría determinar a tiempo si se aplica el artículo 14 y, en caso afirmativo, presentar la solicitud correspondiente.
