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
- En virtud de la Ley de Resiliencia Cibernética, debe gestionar las vulnerabilidades de su producto, incluidas las de sus dependencias, durante al menos cinco años, salvo que se prevea que el producto se utilice durante un periodo más corto.
- Muchos marcos de código abierto ofrecen soporte técnico para una versión durante un periodo de entre uno y tres años, por lo que un producto lanzado con una versión reciente puede dejar de tener acceso a las correcciones de seguridad del desarrollador original a mitad de su periodo de soporte.
- Cuatro opciones para seguir recibiendo parches de seguridad una vez que finalice el soporte del desarrollador original: pasar a una versión más reciente, sustituir la dependencia, arreglarlo uno mismo o comprar los parches.
- Las obligaciones de notificación están en vigor desde el 11 de septiembre de 2026, por lo que, en la actualidad, es obligatorio notificar cualquier vulnerabilidad que se esté explotando activamente en una dependencia cuyo ciclo de vida ya haya finalizado, aunque no exista una corrección del desarrollador original a la que remitirse. Las normas relativas al periodo de soporte entrarán en vigor el 11 de diciembre de 2027.
El periodo de soporte de la Ley de Ciberresiliencia de la UE (CRA) debe durar al menos cinco años, salvo que se prevea que un producto vaya a estar en uso durante un periodo más corto. Las versiones recientes de marcos de trabajo populares como Laravel, Django y Spring Boot dejaron de recibir correcciones de seguridad de código abierto entre uno y tres años después de su lanzamiento. Si comercializas software desarrollado con esos marcos de trabajo, las correcciones del desarrollador original dejan de llegar a mitad de tu periodo de soporte, y tendrás que proporcionar tú mismo las correcciones para el resto del periodo.
Un periodo de soporte es el tiempo durante el cual un fabricante debe seguir gestionando las vulnerabilidades de un producto. Según la CRA, se considera fabricante a quien comercializa el producto bajo su propio nombre o marca registrada en el marco de una actividad comercial, ya sea a título oneroso o gratuito. La obligación del fabricante de subsanar las vulnerabilidades abarca la totalidad del producto, incluidos sus componentes. Las personas que se encargan del mantenimiento de las bibliotecas subyacentes no suelen tener una obligación equivalente, por lo que nada les obliga a seguir corrigiendo la versión que tú distribuyes.
Las principales obligaciones entrarán en vigor el 11 de diciembre de 2027, lo que puede parecer lejano hasta que se comparen los requisitos del periodo de soporte con el tiempo durante el que las plataformas que se elijan hoy seguirán recibiendo actualizaciones.
Requisitos del periodo de asistencia de la CRA
La Ley de Resiliencia Cibernética es el Reglamento (UE) 2024/2847. Según los términos de la ley, se entiende por fabricante cualquier persona física o jurídica que desarrolle un producto, o encargue su desarrollo, y lo comercialice bajo su propio nombre o marca comercial, ya sea a título oneroso o gratuito. La ley define el «período de soporte» como el tiempo durante el cual el fabricante debe garantizar que las vulnerabilidades del producto se subsanen de manera eficaz.
El artículo 13 de la CRA exige a los fabricantes que establezcan un plazo que refleje el tiempo que se prevé que el producto permanezca en uso. Para ello se tienen en cuenta las expectativas razonables de los usuarios, la naturaleza del producto y su finalidad prevista. El plazo debe ser de al menos cinco años. La única excepción es un producto cuyo uso previsto sea inferior a ese plazo, en cuyo caso el plazo se ajustará a dicho uso previsto. Cuando sea razonable esperar que un producto se utilice durante más de cinco años, el plazo deberá ser más largo. En los considerandos de la Ley se citan como ejemplos los routers, los sistemas operativos y los sistemas de control industrial.
Este plazo conlleva tres obligaciones. Los fabricantes deben publicar actualizaciones de seguridad sin demora y de forma gratuita. La única excepción son los productos a medida, en los que el fabricante y el usuario empresarial pueden acordar una tarifa por las actualizaciones. La fecha de finalización, indicando al menos el mes y el año, debe quedar clara en el momento de la compra. Además, cada actualización de seguridad debe permanecer disponible durante al menos 10 años, o hasta el final del periodo de soporte si este es más largo. Estas tres condiciones se aplican tanto a las correcciones de los componentes de código abierto incluidos en el producto como a tu propio código. La fecha de finalización publicada es un compromiso público, así que averigua durante cuánto tiempo tus dependencias seguirán recibiendo correcciones de los desarrolladores originales antes de publicarla.
Nota: Los productos comercializados antes del 11 de diciembre de 2027 solo estarán sujetos a los requisitos principales de la CRA si se les realiza una modificación sustancial después de esa fecha. Esto significa un cambio posterior a su lanzamiento que afecte al cumplimiento de los requisitos de la Ley aplicables al producto o que modifique la finalidad para la que se evaluó el producto. El artículo 14, que regula la presentación de informes, funciona de manera diferente: sus obligaciones se aplican a los productos incluidos en el ámbito de aplicación que ya se encuentran en el mercado, y están en vigor desde el 11 de septiembre de 2026.
Cuánto duran las dependencias habituales
Tres versiones de marcos de trabajo —una de Python, otra de PHP y otra de Java— han llegado recientemente al final de su ciclo de vida. En este artículo, por «final del ciclo de vida» se entiende la fecha en la que un proyecto deja de publicar parches de seguridad para una versión.
| Dependencia | Publicado | Se han finalizado las correcciones de seguridad en las fases iniciales | Envergadura | Fundamentos |
|---|---|---|---|---|
| Django 4.2 (soporte a largo plazo) | 3 de abril de 2023 | 7 de abril de 2026 | Unos 3 años | Política del proyecto, no ley |
| Laravel 11 | 12 de marzo de 2024 | 12 de marzo de 2026 | 2 años | Política del proyecto, no ley |
| Spring Boot 3.5 | 22 de mayo de 2025 | 30 de junio de 2026 | Unos 13 meses | Política del proyecto, no ley |
Cada proyecto lo denomina de forma diferente. Django lo llama «fin del soporte ampliado», Laravel indica cuándo dejan de publicarse correcciones de seguridad y Spring lo denomina «fin del soporte de código abierto». Para ti, todos significan lo mismo, ya que la versión que has distribuido deja de recibir correcciones del desarrollador original.
Ninguno de los tres cuenta con cinco años de correcciones de seguridad del desarrollador original, que es lo mínimo que te exige la CRA. Sin embargo, la fecha de lanzamiento del marco de trabajo importa menos que la fecha de lanzamiento de tu producto, ya que tu periodo de soporte comienza cuando pones el producto en el mercado. El día del lanzamiento, comprueba cuánto soporte del desarrollador original le queda al marco de trabajo. Tomemos como ejemplo un producto lanzado el 11 de diciembre de 2027, el día en que entran en vigor las normas sobre el periodo de soporte: su periodo de soporte debe extenderse, como mínimo, hasta el 11 de diciembre de 2032. Si se basa en Laravel 13, lanzado el 17 de marzo de 2026, seguiría recibiendo correcciones de seguridad del desarrollador original hasta el 17 de marzo de 2028, unos tres meses después del inicio de ese periodo. Si se desarrollara con Django 5.2, una versión con soporte a largo plazo, seguiría recibiéndolas hasta abril de 2028, unos cuatro meses después del inicio de dicho periodo. Antes de diciembre de 2027 saldrán al mercado nuevas versiones de los marcos de trabajo: Laravel lanza una versión principal aproximadamente cada año, y la versión 6.2 de Django está prevista para abril de 2027, con soporte ampliado hasta abril de 2030, algo más de dos años después del inicio de ese mismo periodo. Sea cual sea la versión con la que se ponga en marcha el proyecto, las correcciones del desarrollador original finalizarán años antes de que termine su periodo de soporte, y las correcciones para los años restantes tendrán que venir de usted mismo.
Puedes pasar a una versión más reciente —y muchos equipos lo harán—, pero eso supone un trabajo de ingeniería que debe completarse antes o durante tu periodo de soporte. Tres marcos de trabajo no constituyen toda la pila tecnológica, y algunas de tus dependencias durarán más de cinco años. La tarea consiste en comparar las fechas de publicación de cada uno de ellos con las tuyas.
¿Quién es responsable de qué en relación con el código abierto que distribuyes?
La CRA señala dos aspectos sobre los componentes que no has escrito tú. «Componente» es el término que se utiliza para referirse a las dependencias que incorporas. El artículo 13 exige a los fabricantes que actúen con la debida diligencia al integrar componentes de terceros, incluidos los de código abierto, para que dichos componentes no pongan en riesgo la seguridad del producto. Además, cuando un fabricante detecte una vulnerabilidad en un componente, deberá notificársela a los responsables de su mantenimiento y subsanarla en su propio producto. Si el fabricante desarrolla una corrección, deberá compartir el código o la documentación con dichos responsables, en un formato legible por máquina cuando sea pertinente.
Los responsables reciben un trato diferente en función de quiénes sean. Un gestor de software de código abierto es una persona jurídica, distinta de un fabricante, que presta apoyo sistemático a productos específicos de código abierto destinados a actividades comerciales y garantiza su viabilidad. Las fundaciones y las empresas que publican software de código abierto en un contexto empresarial pueden pertenecer a ese grupo. El artículo 24 exige a los administradores que establezcan y documenten una política de ciberseguridad que garantice un desarrollo seguro y una gestión eficaz de las vulnerabilidades, y que cooperen con las autoridades de vigilancia del mercado. Además, establece obligaciones limitadas en materia de notificación. Los proyectos de código abierto que no generan ingresos suelen quedar fuera del ámbito de las obligaciones de los fabricantes, y los colaboradores individuales de proyectos que no gestionan ellos mismos tampoco están sujetos a dichas obligaciones.
Según el Reglamento: cuando un fabricante determina la duración de su periodo de soporte, el artículo 13 le permite tener en cuenta los periodos de soporte de los componentes de terceros que proporcionan funciones básicas. Esto puede justificar un periodo más largo. No puede situarse por debajo del mínimo de cinco años, por lo que un marco que deje de recibir correcciones de los proveedores anteriores al fabricante al cabo de dos años no permite declarar un periodo de dos años. El mínimo de cinco años sigue siendo aplicable.
| Punto | Lo que dice | Fundamentos |
|---|---|---|
| Longitud mínima | Al menos cinco años, salvo que se prevea que el producto se utilice durante menos tiempo | Carácter vinculante (artículo 13) |
| Componentes | La gestión de vulnerabilidades abarca todos los componentes del producto, incluidos los de código abierto | Carácter vinculante (artículo 13) |
| Responsables del mantenimiento | Los administradores deben contar con una política de ciberseguridad documentada (que abarque la gestión de vulnerabilidades) y no disponen de un periodo de soporte para ninguna versión. | Carácter vinculante (artículo 24) |
| Cinco años como dependiente | Cinco años es el plazo mínimo, y las directrices de la Comisión indican que no debe considerarse como el plazo por defecto para todos los productos. | Orientaciones (de la Comisión, de carácter no vinculante) |
| Versiones | Cada versión que haya sufrido modificaciones sustanciales y que se comercialice debe contar con su propio período de validez declarado; una modificación que no altere la vida útil prevista tampoco modifica el período original. | Orientaciones (de la Comisión, de carácter no vinculante) |
En definitiva, el proveedor de la cadena de suministro no suele ofrecerte ningún periodo de asistencia técnica, y la CRA te hace responsable, en tu calidad de fabricante, de gestionar las vulnerabilidades del producto final.
Qué puedes hacer cuando una dependencia llega al final de su ciclo de vida
Una vez que se detiene el proceso en las fases iniciales, alguien tiene que elaborar las correcciones, y la CRA no especifica quién debe redactarlas. Esto deja cuatro vías posibles, cada una con un proyecto de ley diferente.
Pasarse a una versión más reciente: esto funciona cuando se controla cuándo reciben los clientes las nuevas versiones, y supone un coste en tiempo de ingeniería en cada ciclo. En una pila con varios marcos de trabajo que siguen calendarios distintos, esas migraciones se van acumulando.
Sustituye la dependencia: una alternativa actualizada soluciona el problema, si lo hay, siempre que puedas permitirte reescribir el código.
Solucionalo tú mismo: tu equipo adapta las correcciones de seguridad a la versión que distribuyes. Para ello se necesitan personas que conozcan bien el código, y el artículo 13 te obliga a notificar la vulnerabilidad a los responsables del mantenimiento y a compartir tu corrección con ellos.
Adquiere las correcciones: algunos proyectos ofrecen soporte ampliado para versiones anteriores. El propio anuncio de Spring, por ejemplo, indica que el soporte comercial para Spring Framework 6.2 se prolongará hasta mediados de 2032. Los datos de soporte de Spring indican que el soporte empresarial para Spring Boot 3.5 —la versión que aparece en la tabla anterior— se prolongará hasta el 30 de junio de 2032. Los proveedores independientes también ofrecen parches para versiones que han llegado al final de su ciclo de vida. La cobertura depende de las versiones específicas que utilices, así que facilita al proveedor tu lista de versiones actuales y confirma que cada una de ellas esté cubierta antes de darlo por hecho.
Hay otras dos opciones que parecen tentadoras. No es posible declarar un periodo de soporte más corto a menos que se prevea que el producto vaya a estar en uso durante menos de cinco años. Aunque documentar una vulnerabilidad conocida en un registro de riesgos lo justifica, la CRA exige a los fabricantes que aborden y subsanen las vulnerabilidades sin demora, y una entrada en el registro no constituye una solución.
Qué hay que decidir antes de fijar un período de manutención
Hay que indicar la fecha de finalización en el momento de la compra, por lo que es más fácil resolver las cuestiones relacionadas con las dependencias antes de publicarlo que después.
- Empieza por hacer un inventario: una lista actualizada de lo que contiene tu producto, normalmente una lista de materiales de software (SBOM), te muestra qué dependencias debes comprobar, incluidas aquellas que se incorporan a través de tus dependencias directas.
- Organiza las fechas: Anota la fecha de fin de vida útil publicada de cada dependencia junto al periodo de soporte de la CRA que estés barajando. Una hoja de cálculo te servirá.
- Comprueba cada versión: el soporte técnico se presta por versión, tal y como indican las fechas de Django, Laravel y Spring Boot. Consulta la fecha de fin de vida útil de la versión exacta que comercializas. Las directrices de la Comisión también exigen que se declare un periodo de soporte técnico para cada versión que haya sufrido modificaciones sustanciales y que se comercialice.
- Asigna una persona responsable para cada carencia: por cada dependencia que no se cumpla, elige una de las cuatro vías y decide quién se encargará de ella.
- Señalizar lo que ya ha superado su fin de vida útil: si una dependencia de un producto en distribución ha superado hoy su fin de vida útil, la brecha ya existe. Si el producto entra dentro del ámbito de aplicación, cualquier vulnerabilidad de esa dependencia que esté siendo explotada activamente deberá notificarse en un plazo de 24 horas a partir del 11 de septiembre de 2026. La notificación posterior, que debe realizarse en un plazo de 72 horas, debe indicar qué medidas se han tomado al respecto, siempre que no exista una corrección del desarrollador original a la que remitirse.
- Anota el motivo: la documentación técnica debe incluir la información que has utilizado para establecer el periodo, así que conserva tu razonamiento.
Reducir la brecha antes de diciembre de 2027
Al lanzar un producto al mercado, se establece un periodo de soporte que se prolonga durante años, mientras que los marcos subyacentes siguen sus propios calendarios. Sincronizar ambos antes de comprometerse permite saber cuántos de esos años se dedicarán a buscar parches de seguridad para un código cuyos responsables ya han dejado de actualizarlo.
Si uno de los marcos de trabajo subyacentes a tu producto deja de recibir parches de seguridad del proveedor original antes de que finalice tu periodo de soporte, alguien tendrá que encargarse de crear el parche. El servicio «Endless Lifecycle Support» (ELS) de TuxCare se encarga de ello. Los ingenieros de TuxCare adaptan los parches de seguridad a las versiones exactas que ya utilizas, durante todo el tiempo que dependas de ellas. Tus desarrolladores conservan las versiones que tienen y los flujos de trabajo que utilizan. El ELS también se combina con SecureChain, que verifica los paquetes de código abierto antes de su instalación y les aplica parches mientras el proyecto original siga activo.
Al adquirirse conjuntamente, SecureChain y ELS se turnan automáticamente en la cobertura. Cuando un desarrollador deja de publicar correcciones de seguridad para una versión que utilizas, la cobertura de esa versión pasa de SecureChain a ELS. No es necesario que realices un seguimiento de la fecha de fin de vida útil de cada componente para saber cuándo dejan de publicarse las correcciones del desarrollador original. Los productos cubren ahora los ecosistemas de JavaScript, Python, Java, Go y PHP.
PREGUNTAS FRECUENTES
¿Cuál es la duración mínima del período de apoyo de la CRA de la UE?
La Ley de Ciberresiliencia de la UE (CRA) establece un período mínimo de asistencia de cinco años. Un fabricante solo puede reducir este período si se prevé que el producto se utilice durante menos tiempo, en cuyo caso el período se ajustará a dicha duración de uso. Un producto que, con toda probabilidad, se vaya a utilizar durante más tiempo requiere un período más largo.
¿Tienen los responsables del mantenimiento del software de código abierto que seguir ofreciendo soporte para las versiones antiguas?
En general, no. La Ley de Resiliencia Cibernética (CRA) trata a dos grupos de forma diferente, y ninguno de ellos tiene la obligación de ofrecer un periodo de soporte. Los gestores de software de código abierto —personas jurídicas que prestan soporte de forma sistemática a productos de código abierto de uso comercial— deben documentar una política de ciberseguridad, que incluya la gestión de vulnerabilidades, y cooperar con las autoridades. Los proyectos de código abierto que no se monetizan quedan fuera del ámbito de las obligaciones del fabricante, y los colaboradores individuales de proyectos que no gestionan ellos mismos no están cubiertos en absoluto. En cualquier caso, el fabricante que distribuya el código debe mantenerlo actualizado con los parches correspondientes durante el periodo de soporte que haya declarado.
¿Qué ocurre cuando una dependencia deja de recibir parches de seguridad durante el periodo de soporte?
La responsabilidad recae en el fabricante. En virtud de la Ley de Resiliencia Cibernética (CRA), las vulnerabilidades del producto, incluidos sus componentes, deben gestionarse durante todo el periodo de soporte declarado. Las opciones incluyen pasar a una versión compatible, sustituir la dependencia, desarrollar la corrección o adquirir parches para la versión antigua.
¿Qué deben comunicar los fabricantes a los usuarios sobre el periodo de asistencia técnica?
En virtud de la Ley de Resiliencia Cibernética (CRA), la fecha de finalización del periodo de asistencia, indicando al menos el mes y el año, debe quedar clara en el momento de la compra. Los fabricantes también deben consignar en su documentación técnica cómo han establecido dicho periodo y, cuando sea técnicamente viable, notificar a los usuarios cuándo finaliza la asistencia.
¿Se aplica la Ley de Resiliencia Cibernética a los productos que ya se encontraban en el mercado antes de diciembre de 2027?
Solo si se modifican de forma sustancial. En virtud de la Ley de Resiliencia Cibernética (CRA), los productos que ya se encuentren en el mercado antes del 11 de diciembre de 2027 solo estarán sujetos a sus requisitos tras una modificación sustancial a partir de esa fecha. Las obligaciones de notificación previstas en el artículo 14, incluidas las relativas a las vulnerabilidades explotadas activamente, se aplican a dichos productos en cualquier caso.
¿Son jurídicamente vinculantes las orientaciones de la Comisión sobre la Ley de Resiliencia Cibernética?
No. La Comisión Europea publicó el 27 de julio de 2026 sus directrices sobre la Ley de Resiliencia Cibernética (CRA) para explicar cómo aplicar las normas, pero estas no son vinculantes. El propio reglamento y los actos delegados o de ejecución adoptados tienen fuerza jurídica, y solo el Tribunal de Justicia de la UE puede ofrecer una interpretación autorizada. Las orientaciones sí muestran cómo espera la Comisión que se apliquen las normas, por lo que deben tenerse en cuenta a la hora de planificar las medidas hasta que un tribunal dictamine lo contrario.
