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
- LoopBack 3 alcanzó el fin de su ciclo de vida en la comunidad en diciembre de 2020 y ya no recibe correcciones del desarrollador original.
- Si LoopBack venía incluido con IBM API Connect, comprueba primero el ciclo de vida de ese producto.
- LoopBack 4 es una versión reescrita, por lo que no se aplica el plan habitual de actualización que consiste en aumentar la versión y corregir errores.
- Gran parte del riesgo radica en las dependencias transitivas restringidas que
npm audit fixno puedo llegar.
LoopBack 3 agilizó el desarrollo de API sofisticadas al combinar modelos, conectores, controles de acceso y puntos finales generados. Esas mismas abstracciones son la razón por la que la migración a LoopBack 4 es un proyecto arquitectónico y no una simple actualización de dependencias.
El soporte técnico de la comunidad finalizó en diciembre de 2020. La única excepción documentada fueron las correcciones de errores críticos y de seguridad proporcionadas a través de IBM API Connect, y esa vía se ha cerrado desde entonces, junto con las versiones del producto a las que se aplicaba. Por otra parte, gran parte de lo que un escáner detecta en un proyecto de LoopBack 3 suele encontrarse en el árbol de dependencias, más que en el propio paquete del marco de trabajo.
Esta entrada trata sobre qué hacer cuando LoopBack 3 haya llegado al final de su ciclo de vida, la migración suponga una reescritura y la API sea crítica para el funcionamiento del sistema.
El marco de API que definió el negocio
LoopBack 3 destacaba en una cosa que acabó resultando muy importante. Definías modelos, conectabas los conectores y configurabas los controles de acceso, y LoopBack generaba a partir de ahí puntos finales REST operativos. Rápidamente. Con el paso de los años, esas definiciones de modelos pueden convertirse silenciosamente en la capa de integración de la organización sin que nadie lo haya puesto por escrito. Lo difícil de dejar atrás LoopBack 3 rara vez es el código del marco de trabajo. Es la lógica de negocio que se fue acumulando dentro de las definiciones de modelos, los hooks y las ACL.
Imagina una empresa de logística con 60 puntos finales REST generados a partir de modelos de LoopBack 3. Dos aplicaciones internas dependen de ellos. Una integración con un socio los consulta según un calendario que controla el propio socio. Todo el sistema se ejecuta en Node.js 12 dentro de una máquina virtual que nadie quiere recompilar, porque la última persona que entendía la secuencia de arranque se fue hace años.
En un sistema como ese, un cambio de versión no constituye una estrategia de migración, y eso condiciona todas las decisiones posteriores. Si se actúa como si no fuera así, lo más probable es que la migración se estanque y la API, sin parches, siga en producción.
Qué significa realmente el fin de la vida útil de LoopBack 3
Al haber desaparecido el apoyo de la comunidad, LoopBack 3 no recibe nuevas funcionalidades ni correcciones de errores activas por parte de la comunidad. El archivo README del proyecto es muy claro al respecto: no se aceptan más solicitudes de incorporación de cambios (pull requests) ni se ofrece soporte a los usuarios de la comunidad. La política de soporte a largo plazo es ligeramente más flexible, ya que deja margen a los responsables del mantenimiento para evaluar las correcciones de errores críticos enviadas por la comunidad. Ambos documentos señalan la misma excepción limitada para las correcciones críticas a través de IBM API Connect, y ambos se redactaron cuando dicho producto aún ofrecía soporte.
Además, hay una política de soporte que pasa fácilmente desapercibida detrás de todo esto. La política de soporte a largo plazo de LoopBack vinculaba el soporte LTS (Maintenance LTS) a las versiones LTS de Node.js compatibles en el momento en que una versión entraba en esa fase. Una vez que esas versiones de Node.js llegaban al final de su periodo de mantenimiento, la línea correspondiente de LoopBack también llegaba al final de su periodo de mantenimiento. En «Maintenance LTS» no se permitía explícitamente añadir soporte para nuevas versiones principales de Node.js, lo que, dicho de forma más elaborada, significa que la generación de Node.js compatible se fijó hace años.
| Artículo | Estado de LoopBack 3 |
|---|---|
| Fin de vida útil de la comunidad | Diciembre 2020 |
| Nuevas funciones / correcciones de la comunidad | Ninguno |
| Correcciones de seguridad críticas | Excepción histórica a través de IBM API Connect, ya finalizada |
| Ámbito del mantenimiento LTS | Vinculadas a las versiones LTS de Node.js disponibles en el momento del lanzamiento |
| Desarrollo activo en las fases iniciales | LoopBack 4, que incluye el @loopback/* paquetes |
Consejo: Si tu LoopBack venía incluido con IBM API Connect v5 o v2018, comprueba el ciclo de vida del producto antes de dar por hecho que existe una solución alternativa de IBM. El soporte básico para la v5 finalizó el 30 de abril de 2022 y para la v2018 el 30 de abril de 2023; el soporte ampliado para ambas finalizó el 31 de diciembre de 2023, e IBM afirma ahora que ninguna de las dos versiones recibe correcciones de código ni de seguridad. Esa vía está cerrada, lo que significa que la fecha de fin de vida útil (EOL) del código abierto no es el único plazo que ya se te ha agotado.
Hay un indicio que se aprecia directamente en el historial público de paquetes. La última versión de LoopBack 3, [email protected], sigue siendo lo que ofrece npm, y el nuevo trabajo del equipo de desarrollo se centra en los paquetes de LoopBack 4. Ahí es donde se centra la atención del proyecto.
Por qué LoopBack 4 no es simplemente LoopBack 3 con un nuevo número
LoopBack 4 es la línea actual, en desarrollo activo. Además, se trata de una reescritura completa desde cero. El núcleo está escrito principalmente en TypeScript, se basa en la inyección de dependencias y en un contenedor IoC, y utiliza controladores y repositorios en lugar del enfoque de «modelo y script de inicio» que caracterizaba a LoopBack 3. El modelo de extensión también es diferente. Se trata de un nuevo modelo de programación, no de un objetivo al que se llega a través de un gestor de paquetes.
Así pues, la mayor parte del trabajo recae en aquellas partes de la aplicación que se basan en las propias convenciones de LoopBack 3. Esto suele incluir los scripts de arranque y la secuencia de la que dependen, los métodos remotos y los «hooks» de operación asociados a ellos, las definiciones de ACL que codifican el modelo de permisos, los mixins y la configuración de los conectores, todo aquello que se basa en las convenciones JSON de los modelos, y los SDK de cliente generados que los consumidores posteriores ya incluyen en sus productos.
Evalúa el alcance del trabajo con sinceridad. Una actualización normal del marco de trabajo puede medirse en sprints. Una migración a LoopBack 3 puede prolongarse fácilmente durante varios trimestres, y la estimación depende de cuánta lógica se encuentre en las definiciones de los modelos, en lugar de en el código de la aplicación, que se puede portar sin problemas.
Una visión realista: «Solo es una actualización» es la suposición que hunde estos proyectos. Doce puntos finales con una lógica sencilla constituyen un proyecto de alcance limitado para un equipo pequeño. Doscientos puntos finales generados con listas de control de acceso (ACL) que codifican un modelo de permisos constituyen un programa de arquitectura con su propia partida presupuestaria, y se lo merece.
Si la API alimenta integraciones que no controlas, separa el plazo de seguridad del plazo de reescritura antes de definir el alcance de cualquier otra cosa. Se trata de dos plazos distintos, y mezclarlos te obligará a realizar una reescritura apresurada por la que tendrás que pagar debido a los compromisos adquiridos con tus socios.
De dónde proceden realmente los resultados
Al abrir el árbol de dependencias de un proyecto de LoopBack 3, suele aparecer rápidamente un patrón. El código propio del marco de trabajo es solo una parte de la superficie de riesgo. Los nombres que aparecen una y otra vez se encuentran varios niveles más abajo y, dependiendo de los conectores y del archivo de bloqueo que utilices, suelen incluir qs, lodash, body-parser, nodemailer, strong-remoting, strong-globalize, el obsoleto shortid, glob, inflight, y underscore.string. Algunas son dependencias directas de los paquetes de LoopBack. Muchas son transitivas, es decir, se incorporan a través de las que se encuentran por encima de ellas.
El marco cuenta con su propio historial de asesoramiento, y ambos extremos resultan instructivos. El Aviso de seguridad de LoopBack del 30 de noviembre de 2020 abordó un problema de contaminación relacionado con un prototipo en @loopback/rest, donde las cargas útiles JSON que contienen constructor fueron aceptadas. Registrada como CVE-2020-4988, afectaba a la versión 8.0.0 y anteriores, y la corrección se incluyó en la 9.0.0. Se trata de código de LoopBack 4, que es precisamente la clave, ya que las correcciones a nivel de marco de trabajo se incorporan ahora allí. El comunicado del 6 de agosto de 2022 Es la guía que debes leer si utilizas PostgreSQL, ya que aborda una vulnerabilidad crítica de inyección SQL a través de la extensión contains filtrar en loopback-connector-postgresql 5.5.0 y versiones anteriores. El problema surge cuando ese filtro puede acceder al conector, incluidas las fuentes de datos configuradas con allowExtendedProperties: true y código que invoca métodos del conector directamente. La versión 5.5.1 incorpora la sanitización de entradas, y el aviso enumera soluciones alternativas para los equipos que aún no pueden actualizar.
| Dependencia | Función | Restricción de remediación |
|---|---|---|
qs, body-parser |
Análisis sintáctico de la solicitud (transitivo) | A menudo se marcan como fijos por los paquetes principales |
lodash, underscore.string |
Servicios públicos (transitivo) | A veces se puede golpear en la hoja |
strong-remoting, strong-globalize |
Funcionamiento interno de LoopBack | Fijado por el marco |
shortid |
Generación de identificadores, cuando proceda | Obsoleto y fijado por su elemento principal |
loopback-connector-postgresql |
Conector de PostgreSQL: dónde se utiliza | Corregido en la versión 5.5.1 |
Lo que veas exactamente dependerá de tu archivo de bloqueo, de tu versión de Node.js y de tus propias dependencias directas. Lo que se mantiene en todos los proyectos es su estructura. Algunas de estas versiones están limitadas por los rangos de paquetes de LoopBack o por los paquetes que las preceden, lo que impide que la corrección automática seleccione una versión compatible y corregida.
Cuidado: Trato npm audit fix --force como un cambio de alto riesgo en un proyecto de LoopBack 3. Plain npm audit fix solo instala las actualizaciones que se ajustan a los rangos que has declarado. Cuando una cadena de metavulnerabilidades llega al proyecto raíz, solucionarla puede requerir cambios fuera de esos rangos. En ese momento, npm quiere --force, que según su propia documentación instala módulos fuera del rango de dependencias que has especificado, incluidos los cambios de versión mayor según SemVer. En un árbol tan antiguo como este, así es como una tarde tranquila acaba convirtiéndose en una aplicación que no arranca. Ejecuta npm audit fix --dry-run --json Primero, lee lo que propone.
La conclusión práctica es mantener dos listas. Una con los hallazgos que se pueden resolver eliminando una dependencia de nivel inferior. La otra con los hallazgos bloqueados por restricciones situadas más arriba en el árbol. Esas listas requieren planes completamente diferentes, y mezclarlas supone desperdiciar un sprint. También es la razón por la que la cobertura transitiva es más importante aquí que en casi cualquier otra cosa que se corrija, ya que un plan de corrección que deje sin resolver una dependencia vulnerable aplicable no ha cerrado ese hallazgo.
Elegir el camino adecuado
No hay una única forma correcta de actuar, pero las opciones realistas son escasas. Reconstruye servicios más pequeños y bien probados en LoopBack 4 cuando la lógica sea lo suficientemente sencilla como para que el trabajo sea realmente factible. Cambia de plataforma las API cuya arquitectura ya no se adapta a las necesidades del negocio, ya que trasladar un mal diseño a un nuevo marco de trabajo solo te acarreará el mismo problema en TypeScript.
Aplica Secure LoopBack 3 cuando una migración precipitada suponga un riesgo operativo más inmediato que las vulnerabilidades que realmente afectan a tu implementación. Esto te permite ganar tiempo sin descartar por completo la posibilidad de reescribir el código.
En el caso de las API que soportan la carga, el patrón «strangler» es la versión concreta de este enfoque. Se coloca una fachada de compatibilidad delante de la API de LoopBack 3 para que los contratos externos se mantengan estables y, a continuación, se trasladan las funcionalidades detrás de ella de una en una. Los socios siguen accediendo a la misma URL mientras tú reconstruyes lo que hay detrás de ella.
Aún hay que parchear esa vulnerabilidad, y lo que hay disponible depende de la versión que tengas instalada. Asistencia durante todo el ciclo de vida (ELS) de TuxCare Actualmente documenta las versiones 1.10.0 y 2.42.0 de LoopBack, que se distribuyen como sustitutos directos a través de un registro npm gestionado por TuxCare. La lista de modificaciones que se incluye es la parte más interesante para cualquiera que lea un informe de análisis, ya que profundiza en qs, body-parser, underscore.string y el resto del árbol, en lugar de detenerse en el paquete de nivel superior. Si la fachada está conectada a un servicio de LoopBack 2, ese es el reloj de seguridad que se gestiona mientras se ejecuta la recompilación. En la versión 3.x, infórmate sobre la cobertura para tu versión concreta antes de incluirla en el plan.
En resumen, la cosa es así: una lógica sencilla y un número reducido de puntos finales implican reconstruir el sistema en LoopBack 4 y fijar una fecha. Los permisos basados en modelos y las integraciones con socios implican una reescritura por fases detrás de una fachada, manteniendo la seguridad de la interfaz antigua mientras siga cubriéndose su versión. Y si LoopBack llegó a través de IBM API Connect, hay que resolver la cuestión del soporte técnico del producto antes que nada.
Cómo gestiona TuxCare el «LoopBack»
TuxCare realiza un seguimiento del marco de trabajo y su árbol de dependencias y, a continuación, determina si cada aviso se aplica realmente a la versión cubierta antes de que se aplique ningún parche. Primero, la aplicabilidad; después, el ruido, lo cual es importante cuando gran parte de lo que estás analizando es transitivo.
Las correcciones se retroaplican a las versiones compatibles, en lugar de entregarse como una actualización del marco, y los paquetes se publican como sustitutos directos de los originales que han llegado al final de su vida útil. Esa distinción es importante, ya que los puntos finales generados constituyen un contrato del que dependen otros equipos, y una «corrección» que altere el formato de la respuesta supone una regresión para todos los que se encuentran en las fases posteriores del proceso.
El modelo de soporte está documentado, no es improvisado. Los objetivos publicados son de 14 días desde la divulgación pública para hallazgos de gravedad alta y crítica con puntuación CVSS 7.0 o superior, 60 días para los de gravedad media y 90 días para los de gravedad baja, con una respuesta inicial a un problema notificado en un plazo de tres días; todo ello enmarcado como esfuerzos comercialmente razonables, no como una garantía contractual. Cada paquete que compila TuxCare se distribuye con una SBOM, y los documentos VEX de CycloneDX se publican junto con cada versión del paquete y se actualizan con cada lanzamiento, de modo que el registro de auditoría recoge qué CVE conocidas afectan a una versión determinada del artefacto y cuáles no. Esa trazabilidad resulta muy útil en entornos regulados que necesitan un registro documental, y la escalación por escrito basada en tickets lo proporciona. TuxCare no es el proyecto original y no pretende serlo. El trabajo consiste en una adaptación retroactiva disciplinada para sistemas de producción, una vez que la atención del proyecto original se ha desplazado a LoopBack 4.
Para conocer el estado actual de los CVE en todos los paquetes incluidos, lo mejor es consultar el rastreador de CVE de TuxCare.
El papel de LoopBack en el ecosistema de OpenJS
LoopBack es un proyecto «At-Large» de la Fundación OpenJS. StrongLoop, una empresa de IBM, lo aportó a la Fundación en junio de 2021, y al año siguiente pasó de la fase de incubación a la categoría «At-Large». El Programa de Sostenibilidad del Ecosistema (ESP) de la Fundación existe para que las versiones obsoletas y antiguas puedan obtener cobertura comercial, y una parte de los ingresos de los socios se destina a apoyar a los mantenedores participantes y la labor de la Fundación. TuxCare se unió como miembro Gold y socio del ESP, y dado que el programa no es exclusivo, la cobertura comercial no impide a los mantenedores ofrecer soporte público a cualquier versión, incluidas aquellas que cubre un socio.
Es muy posible que LoopBack 4 sea el destino adecuado. Pero considerar la ruta como una simple actualización del paquete es la forma en que los buenos equipos elaboran planes erróneos.
