Protege los servicios de Fastify que ya no reciben soporte sin tener que apresurarte a actualizar el marco de trabajo

Utiliza una versión de sustitución que se mantenga actualizada y que sea compatible con la que tu servicio ya espera. Añade tres líneas de registro al archivo .npmrc de tu proyecto, configura la dependencia de Fastify para que apunte al paquete de TuxCare y vuelve a instalarlo. Las vulnerabilidades CVE se corrigen sin necesidad de realizar una migración del marco de trabajo al mismo tiempo, y las rutas, los hooks, los decoradores y el registro de complementos permanecen tal y como están.

ELS cubre Fastify 3.29.5 y 4.29.1, las versiones finales de cada línea. Fastify 3 dejó de ser LTS en el proyecto original en junio de 2023 y Fastify 4 en junio de 2025, por lo que los nuevos problemas de seguridad que afecten a cualquiera de ellas ya no cuentan con una ruta de parches garantizada por el proyecto original. Si tu servicio utiliza una versión fija diferente, ponte en contacto con TuxCare para hablar sobre la cobertura.

Cuando un CVE publicado afecta a una versión cubierta, TuxCare lo evalúa y aplica la corrección necesaria retroactivamente siempre que sea posible. El historial de Fastify ya incluye casos de denegación de servicio a través de encabezados «Content-Type» manipulados y una elusión de la comprobación previa de CORS, el tipo de hallazgo que sale a la luz en un análisis mucho tiempo después de que un servicio haya dejado de actualizarse.

Sí. ELS incluye correcciones de seguridad para las dependencias directas y transitivas cubiertas, por lo que la corrección no se limita al paquete Fastify de nivel superior. TuxCare documenta una entrada de anulación en el archivo package.json para las copias anidadas; el Patcher la escribe por ti, y el servicio de asistencia puede confirmarte el método adecuado si tu proyecto se compila con una versión anterior de npm.

No. La adopción del paquete mantenido por TuxCare supone un cambio en la resolución de dependencias que se lleva a cabo a través del registro npm de TuxCare. Las definiciones de rutas, los hooks de ciclo de vida, los esquemas y el árbol de complementos funcionan exactamente igual que antes.

Sí. Los paquetes ELS se resuelven a través de npm desde el registro de TuxCare, por lo que se adaptan a las compilaciones de Docker, a los procesos de CI/CD y a los flujos de trabajo de implementación existentes. El cambio se produce en la resolución de dependencias, no en la lógica de tu aplicación.

ELS está diseñado para dar respuesta a los requisitos de corrección de vulnerabilidades en el marco de normas como SOC 2, PCI DSS, HIPAA, NIS2, DORA y la CRA. Un acuerdo de nivel de servicio (SLA) contractual sobre la aplicación de parches proporciona a los auditores una hoja de ruta documentada para la corrección de vulnerabilidades en un marco que, de otro modo, no estaría cubierto.

Actualiza cuando sea viable desde el punto de vista técnico. ELS mantiene actualizadas las versiones cubiertas mientras pruebas los complementos, los requisitos de ejecución, los esquemas y el comportamiento de la aplicación en la versión principal más reciente, de modo que la migración se ajuste a tu plan de trabajo en lugar de a la próxima vulnerabilidad CVE.