Segurança
A dependência que ninguém atualiza há dois anos
Não é sobre o pacote que você instalou ontem. É sobre o que está lá desde o começo, ninguém olha, e para de receber correção sem avisar ninguém.
Existe muito conteúdo bom sobre o cuidado ao instalar um pacote novo. Conferir quem mantém, olhar o que ele traz junto, desconfiar de nome parecido.
Esse cuidado importa e é sobre um momento específico: a instalação.
O risco maior está no que já está lá dentro há dois anos e ninguém olha.
Por que o que já está instalado é mais perigoso
Porque não existe um momento de decisão.
Na instalação, você para, avalia, escolhe. Existe um instante de atenção.
Depois disso, nunca mais. O pacote fica no projeto, funciona, e envelhece sem que ninguém abra a questão. Não tem alerta, não tem reunião, não tem gatilho.
E enquanto ele envelhece, duas coisas acontecem sem aviso.
O que acontece com pacote parado
Correção de segurança se acumula. Cada versão que sai costuma trazer conserto de alguma coisa. Ficar dez versões atrás significa ter dez conjuntos de correção não aplicados, e as correções são públicas: quem quer explorar sabe exatamente o que procurar em quem não atualizou.
O projeto pode ter sido abandonado. Esse é o pior caso, e o mais silencioso. O pacote continua funcionando perfeitamente, mas ninguém mais mantém. Não vai ter correção nunca mais, e nada no seu projeto avisa isso.
Funcionar e ser mantido são coisas diferentes. Só a segunda protege.
Como fazer a triagem
Não precisa auditoria formal. Uma hora resolve.
Passo 1: lista o que está atrasado. O comando que mostra pacotes desatualizados existe em qualquer ecossistema. Roda e olha quantos aparecem, e quantos estão atrás de versão principal.
Passo 2: roda a checagem de vulnerabilidade. Também é comando pronto. Ela separa "está velho" de "está velho e tem problema conhecido", que é a diferença que importa pra priorizar.
Passo 3: olha as datas de lançamento das principais. Última versão de dois anos atrás é sinal de projeto parado. Vale conferir se o repositório tem atividade ou se as questões abertas ficam sem resposta.
Passo 4: separa o que dá pra remover. Boa parte das dependências antigas entrou pra resolver algo que hoje a linguagem já faz nativamente, ou pra uma funcionalidade que nem existe mais. Dependência removida é a única que não envelhece.
A ordem de atacar
Primeiro: o que tem vulnerabilidade conhecida e está no caminho de dado sensível.
Segundo: o que está sem manutenção. Não é urgente hoje e vai ser um problema sem solução depois, porque não vai existir versão nova pra atualizar.
Terceiro: o resto, que ganhou só funcionalidade nova. Esse atraso é o menos perigoso.
O erro de deixar acumular
O cenário que trava projeto de verdade é este: ninguém atualiza por dois anos, e aí atualizar deixa de ser uma tarefa e vira um projeto.
Três versões principais de distância, mudanças que quebram compatibilidade encadeadas, e nenhuma semana em que isso caiba.
Aí a decisão vira "depois", pra sempre.
Atualizar de pouco em pouco é chato. Atualizar de uma vez é inviável. É a diferença entre uma hora por mês e um trimestre que nunca acontece.
Onde a IA ajuda
Ela é boa em explicar o que muda entre versões e em fazer a alteração mecânica de compatibilidade.
O que ela não faz é decidir a ordem, avaliar risco no seu contexto e testar se continuou funcionando. Isso continua sendo trabalho de quem responde pelo sistema.
Vale colocar essa checagem no checkup mensal. Dez minutos de olhada evitam o trimestre que ninguém tem.
Código que você escreve, você revisa. Código que você instala, alguém revisa por você. E se esse alguém foi embora, ninguém revisa.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Qual a diferença entre esse risco e o de instalar pacote novo?
Instalar é uma decisão consciente que dá para avaliar na hora. O que já está instalado envelhece em silêncio, sem nenhum momento de decisão, e por isso passa despercebido por anos.
+Como saber se uma dependência foi abandonada?
Olhando a data do último lançamento e a atividade do repositório. Projeto sem atualização há muito tempo e com problemas abertos sem resposta costuma estar sem manutenção, mesmo que ainda funcione.
+Preciso atualizar tudo sempre?
Não. Precisa saber o que está atrasado e decidir conscientemente. O problema não é ficar uma versão atrás, é acumular tanto atraso que atualizar deixa de caber numa tarefa.
+Por onde começar se está tudo atrasado?
Pelas que têm correção de segurança pendente, depois pelas que estão sem manutenção. Deixe por último as que só ganharam funcionalidade nova, que é o atraso menos perigoso.
Continue lendo
Como usar IA em cima de dado sensível sem entregar o dado
Dá pra corrigir prova, analisar contrato e resumir atendimento com IA sem mandar nome, CPF e documento pro modelo. A técnica é simples e quase ninguém aplica.
SegurançaOs 3 lugares por onde dado sensível vaza num app feito com IA
Não é hacker. Na prática, quase todo vazamento em app feito com IA vem de três lugares chatos e previsíveis. Os três dão pra conferir hoje, sem ser programador.
SegurançaComo separar dado real de dado de teste (o que a LGPD cobra)
Testar com a base de produção é o atalho mais comum e o mais caro. Separar ambiente é mais simples do que parece, e a LGPD não trata isso como detalhe.