Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O LoopBack 3 atingiu o fim da vida útil na comunidade em dezembro de 2020 e não recebe mais correções do desenvolvedor original.
- Se o LoopBack vier integrado ao IBM API Connect, verifique primeiro o ciclo de vida desse produto.
- O LoopBack 4 é uma versão totalmente reescrita; portanto, o plano habitual de atualização, que consiste em simplesmente passar para a versão seguinte e corrigir os problemas, não se aplica.
- Grande parte do risco está nas dependências transitivas restritas que
npm audit fixnão consigo alcançar.
O LoopBack 3 agilizou o desenvolvimento de APIs sofisticadas ao combinar modelos, conectores, controles de acesso e endpoints gerados. Essas mesmas abstrações são o motivo pelo qual a migração para o LoopBack 4 é um projeto arquitetônico, e não apenas uma atualização de dependências.
O suporte da comunidade foi encerrado em dezembro de 2020. A única exceção documentada foram as correções de bugs críticos e de segurança fornecidas por meio do IBM API Connect, e essa opção foi encerrada desde então, juntamente com as versões do produto às quais se aplicava. Enquanto isso, grande parte do que um scanner relata em um projeto do LoopBack 3 tende a estar na árvore de dependências, e não no próprio pacote da estrutura.
Este post trata do que fazer quando o LoopBack 3 chegar ao fim de sua vida útil, o caminho de migração exigir uma reescrita e a API for a principal responsável pelo processamento de tráfego.
A estrutura de API que codificou o negócio
O LoopBack 3 era bom em uma coisa que acabou se revelando muito importante. Você definia modelos, conectava conectores e configurava controles de acesso, e o LoopBack gerava endpoints REST funcionais a partir disso. Rapidamente. Ao longo de alguns anos, essas definições de modelo podem, discretamente, se tornar a camada de integração da organização sem que ninguém tenha registrado isso por escrito. A parte difícil de abandonar o LoopBack 3 raramente é o código da estrutura. É a lógica de negócios que se acumulou dentro das definições de modelo, hooks e ACLs.
Imagine uma empresa de logística com 60 endpoints REST gerados a partir de modelos do LoopBack 3. Dois aplicativos internos dependem deles. Uma integração com um parceiro acessa esses endpoints de acordo com uma programação controlada pelo próprio parceiro. Todo o sistema roda no Node.js 12 dentro de uma máquina virtual que ninguém quer reconfigurar, porque a última pessoa que entendia a sequência de inicialização saiu da empresa há anos.
Para um sistema como esse, um aumento de versão não constitui uma estratégia de migração, e isso altera todas as decisões que se seguem. Se fingirmos o contrário, o resultado provável será uma migração paralisada, com uma API sem correções ainda em produção.
O que realmente significa o fim do ciclo de vida do LoopBack 3
Sem o apoio da comunidade, o LoopBack 3 não recebe novos recursos nem correções de bugs por parte da comunidade. O arquivo README do projeto é direto quanto ao restante: não há mais pull requests nem suporte para usuários da comunidade. A política de suporte de longo prazo é um pouco mais flexível, deixando margem para que os mantenedores avaliem correções enviadas pela comunidade para bugs críticos. Ambos os documentos apontam para a mesma exceção restrita para correções críticas por meio do IBM API Connect, e ambos foram redigidos enquanto esse produto ainda oferecia suporte.
Há também uma política de suporte fácil de passar despercebida por trás de tudo isso. A política de suporte de longo prazo do LoopBack vinculava o Maintenance LTS às versões LTS do Node.js suportadas no momento em que uma versão entrava nessa fase. Quando essas versões do Node.js chegavam ao fim da manutenção, a linha correspondente do LoopBack também chegava ao fim de seu período de manutenção. A adição de suporte a novas versões principais do Node.js era explicitamente proibida no Maintenance LTS, o que é uma maneira indireta de dizer que a geração do Node.js suportada havia sido definida há anos.
| Item | Status do LoopBack 3 |
|---|---|
| Fim da vida útil da comunidade | Dezembro de 2020 |
| Novos recursos / correções sugeridas pela comunidade | Nenhum |
| Correções críticas de segurança | Exceção histórica por meio do IBM API Connect, agora encerrada |
| Escopo da manutenção LTS | Vinculadas às versões LTS do Node.js disponíveis no lançamento |
| Desenvolvimento ativo na fase inicial | LoopBack 4, incluindo o @loopback/* pacotes |
Dica: Se o seu LoopBack veio integrado ao IBM API Connect v5 ou v2018, verifique o ciclo de vida do produto antes de presumir que há um fallback da IBM. O suporte básico para a v5 terminou em 30 de abril de 2022 e para a v2018 em 30 de abril de 2023; o suporte estendido para ambas terminou em 31 de dezembro de 2023, e a IBM agora afirma que nenhuma das versões recebe correções de código ou de segurança. Essa opção está encerrada, o que significa que a data de fim de vida útil (EOL) do código aberto não é o único prazo que já se esgotou para você.
Um indício fica evidente logo no histórico público das versões. A última versão do LoopBack 3, [email protected], continua sendo o que o npm disponibiliza, e os novos trabalhos no código-fonte estão concentrados nos pacotes do LoopBack 4. É nisso que o projeto está focado.
Por que o LoopBack 4 não é apenas o LoopBack 3 com um novo número
O LoopBack 4 é a linha atual, em desenvolvimento ativo. Trata-se também de uma reescrita completa. O núcleo é baseado em TypeScript, construído em torno da injeção de dependências e de um contêiner IoC, com controladores e repositórios substituindo a abordagem de “modelo e script de inicialização” que caracterizava o LoopBack 3. O modelo de extensão também é diferente. Trata-se de um novo modelo de programação, não de um destino ao qual se chega por meio de um gerenciador de pacotes.
Portanto, a maior parte do trabalho recai sobre as partes do aplicativo construídas com base nas convenções próprias do LoopBack 3. Isso geralmente significa scripts de inicialização e a sequência da qual eles dependem, métodos remotos e os ganchos de operação associados a eles, definições de ACL que codificam seu modelo de permissões, mixins e configuração de conectores, tudo o que se baseia nas convenções JSON de modelos, além dos SDKs de cliente gerados que os consumidores a jusante já distribuem.
Avalie o escopo do trabalho com honestidade. Uma atualização normal de framework pode ser medida em sprints. Uma migração para o LoopBack 3 pode facilmente levar trimestres, e a estimativa varia de acordo com a quantidade de lógica presente nas definições dos modelos, em vez de no código da aplicação, que pode ser portado de forma limpa.
A realidade: “É só uma atualização” é a suposição que leva esses projetos ao fracasso. Doze endpoints com lógica simples constituem um projeto de escopo limitado para uma equipe pequena. Duzentos endpoints gerados com ACLs que codificam um modelo de permissões constituem um programa de arquitetura com sua própria linha orçamentária — e ele merece isso.
Se a API alimentar integrações que você não controla, separe o prazo de segurança do prazo de reescrita antes de definir o escopo de qualquer outra coisa. São dois prazos distintos, e misturá-los leva a uma reescrita apressada pela qual você acabará pagando devido aos compromissos assumidos com seus parceiros.
De onde realmente vêm as descobertas
Ao abrir a árvore de dependências de um projeto do LoopBack 3, geralmente surge rapidamente um padrão. O próprio código da estrutura é apenas parte da área de risco. Os nomes que aparecem repetidamente estão vários níveis abaixo e, dependendo dos seus conectores e do seu arquivo de bloqueio, tendem a incluir qs, lodash, body-parser, nodemailer, strong-remoting, strong-globalize, o obsoleto shortid, glob, inflight, e underscore.string. Algumas são dependências diretas dos pacotes do LoopBack. Muitas são transitivas, incluídas por causa das que estão acima delas.
Esse quadro tem seu próprio histórico de orientações, e ambos os extremos desse histórico são esclarecedores. O Aviso de segurança da LoopBack de 30 de novembro de 2020 abordou um problema protótipo de poluição em @loopback/rest, onde as cargas de dados JSON contêm constructor foram aceitas. Registrada como CVE-2020-4988, a vulnerabilidade afetava a versão 8.0.0 e anteriores, e a correção foi incluída na versão 9.0.0. Trata-se do código do LoopBack 4, o que é justamente o ponto, já que as correções no nível do framework agora são implementadas ali. O comunicado de 6 de agosto de 2022 é o artigo que você deve ler se utiliza o PostgreSQL, pois aborda uma vulnerabilidade crítica de injeção de SQL por meio da extensão contains filtrar em loopback-connector-postgresql 5.5.0 e versões anteriores. Isso causa problemas quando esse filtro consegue acessar o conector, incluindo fontes de dados configuradas com allowExtendedProperties: true e código que chama métodos do conector diretamente. A versão 5.5.1 inclui a sanitização de entradas, e o comunicado apresenta soluções alternativas para equipes que ainda não podem atualizar.
| Dependência | Função | Restrição de remediação |
|---|---|---|
qs, body-parser |
Análise de solicitação (transitiva) | Frequentemente marcados como “pinned” por pacotes pais |
lodash, underscore.string |
Utilidades (transitivo) | Às vezes, pode-se esbarrar na folha |
strong-remoting, strong-globalize |
Funcionamento interno do LoopBack | Fixado pela estrutura |
shortid |
Geração de ID, quando houver | Obsoleto e fixado pelo elemento pai |
loopback-connector-postgresql |
Conector do PostgreSQL: onde é utilizado | Corrigido na versão 5.5.1 |
O que exatamente você vê depende do seu arquivo de bloqueio, da sua versão do Node.js e das suas próprias dependências diretas. O que se mantém consistente entre os projetos é a estrutura disso. Algumas dessas versões são limitadas pelos intervalos de versões do LoopBack ou pelos pacotes que estão acima delas, e é isso que impede que a correção automatizada escolha uma versão corrigida compatível.
Cuidado: Mimo npm audit fix --force como uma alteração de alto risco em um projeto do LoopBack 3. Simples npm audit fix instala apenas as atualizações que se enquadram nos intervalos declarados. Quando uma cadeia de metavulnerabilidades atinge o projeto raiz, corrigi-la pode exigir alterações fora desses intervalos. Nesse momento, o npm solicita --force, que conforme sua própria documentação instala módulos fora do intervalo de dependências especificado, incluindo mudanças de versão principal segundo a SemVer. Em uma árvore de código tão antiga, é assim que uma tarde tranquila se transforma em um aplicativo que não inicia. Execute npm audit fix --dry-run --json Primeiro, leia o que ele propõe.
A lição prática é manter duas listas. Uma contém as falhas que podem ser corrigidas removendo uma dependência de nível inferior. A outra contém as falhas bloqueadas por restrições em níveis superiores da árvore. Essas listas exigem planos completamente diferentes, e misturá-las desperdiça um sprint. É também por isso que a cobertura transitiva é mais importante aqui do que em quase qualquer outra correção que você faça, já que um plano de correção que deixe uma dependência vulnerável aplicável no lugar não considera essa falha como resolvida.
Escolhendo o caminho certo
Não existe uma única maneira correta de agir, mas as opções viáveis são poucas. Recrie serviços menores e bem testados no LoopBack 4 quando a lógica for simples o suficiente para que o trabalho seja realmente viável. Faça a migração das APIs cuja arquitetura não atenda mais às necessidades do negócio, pois transferir um projeto mal elaborado para uma nova estrutura apenas resulta no mesmo problema em TypeScript.
Implemente o Secure LoopBack 3 quando uma migração apressada representasse um risco operacional mais imediato do que as vulnerabilidades que realmente afetam sua implantação. Isso dá um tempo sem descartar a possibilidade de uma reescrita.
Para as APIs que suportam carga, o padrão “strangler” é a versão concreta disso. Coloque uma fachada de compatibilidade na frente da API do LoopBack 3 para que os contratos externos permaneçam estáveis e, em seguida, transfira os recursos para trás dela, um por um. Os parceiros continuam acessando a mesma URL enquanto você reconstrói o que está por trás dela.
Essa vulnerabilidade ainda precisa ser corrigida, e as opções disponíveis dependem da versão que você está usando. Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare Atualmente, documenta as versões 1.10.0 e 2.42.0 do LoopBack, fornecidas como substitutos diretos por meio de um registro npm gerenciado pela TuxCare. A lista de substituições que o acompanha é a parte interessante para quem estiver lendo um relatório de varredura, já que ela abrange até qs, body-parser, underscore.string e o restante da árvore, em vez de parar no pacote de nível superior. Se a fachada estiver conectada a um serviço do LoopBack 2, esse é o relógio de segurança gerenciado enquanto a recompilação está em andamento. Na versão 3.x, verifique a cobertura específica para a sua versão antes de incluí-la no plano.
A versão resumida é a seguinte. Uma lógica simples e um número reduzido de endpoints significam reconstruir tudo no LoopBack 4 e definir uma data. Permissões orientadas por modelos e integrações com parceiros implicam uma reescrita em fases por trás de uma fachada, com a interface antiga mantida segura enquanto sua versão estiver em uso. E, se o LoopBack foi implementado por meio do IBM API Connect, resolva a questão do suporte ao produto antes de qualquer outra coisa.
Como a TuxCare lida com o LoopBack
O TuxCare monitora o framework e sua árvore de dependências e, em seguida, determina se cada aviso se aplica de fato à versão coberta antes que qualquer correção seja aplicada. A aplicabilidade vem em primeiro lugar, o ruído em segundo — o que é importante quando grande parte do que você está analisando é transitivo.
As correções são retroportadas para as versões compatíveis, em vez de serem fornecidas como uma atualização da estrutura, e os pacotes são publicados como substitutos diretos dos originais que chegaram ao fim da vida útil. Essa distinção é importante, pois os endpoints gerados constituem um contrato do qual outras equipes dependem, e uma “correção” que altere o formato da resposta representa uma regressão para todos os usuários a jusante.
O modelo de suporte é documentado, e não improvisado. As metas publicadas são de 14 dias a partir da divulgação pública para vulnerabilidades de gravidade alta e crítica no CVSS 7.0 e acima, 60 dias para as de gravidade média e 90 dias para as de gravidade baixa, com uma resposta inicial a um problema relatado em até três dias; tudo isso enquadrado como esforços comercialmente razoáveis, e não como uma garantia contratual. Cada pacote compilado pela TuxCare é fornecido com uma SBOM, e os documentos do CycloneDX VEX são divulgados junto com cada versão do pacote e atualizados a cada lançamento, de modo que a trilha de auditoria registra quais CVEs conhecidas afetam uma determinada versão do artefato e quais não afetam. Essa rastreabilidade se justifica em ambientes regulamentados que exigem um registro documentado, e a escalação por escrito baseada em tickets fornece exatamente isso. A TuxCare não é o projeto upstream e não pretende ser. O trabalho consiste em um backporting disciplinado para sistemas de produção, após a atenção do upstream ter se voltado para o LoopBack 4.
Para acompanhar em tempo real o status dos CVEs nos pacotes abrangidos, o rastreador de CVEs da TuxCare é o lugar certo para consultar.
O papel do LoopBack no ecossistema do OpenJS
O LoopBack é um projeto At-Large da OpenJS Foundation. A StrongLoop, uma empresa da IBM, contribuiu com o projeto para a Fundação em junho de 2021, e ele passou da fase de incubação para o status de At-Large no ano seguinte. O Programa de Sustentabilidade do Ecossistema (ESP) da Fundação existe para que versões em fim de vida útil e versões mais antigas possam obter cobertura comercial, com uma parcela da receita dos parceiros destinando-se a apoiar os mantenedores participantes e o trabalho da Fundação. A TuxCare aderiu como membro Gold e parceira do ESP, e como o programa é não exclusivo, a cobertura comercial não impede que os mantenedores ofereçam suporte público a qualquer versão, incluindo aquelas cobertas por um parceiro.
O LoopBack 4 pode muito bem ser o destino certo. Mas tratar o caminho como uma atualização de pacote é como as boas equipes elaboram planos ruins.
