Agência britânica recomenda checagem manual de dependências antes de atualizar
O Centro Nacional de Segurança Cibernética do Reino Unido (NCSC) emitiu um alerta direto aos desenvolvedores de software: não instale automaticamente pacotes e atualizações de dependências sem uma verificação prévia. A orientação vai na contramão da prática comum de muitos times de desenvolvimento, que costumam confiar cegamente em atualizações automáticas em gerenciadores de pacotes como npm, PyPI e outros repositórios.
Antes mesmo desse posicionamento do NCSC, a agência de segurança cibernética dos Estados Unidos (CISA) já havia sugerido uma medida de contenção: aguardar pelo menos três horas antes de instalar novos pacotes publicados em repositórios públicos. A ideia é simples, mas eficaz: criar uma “janela de observação” para que a comunidade de segurança e os próprios mantenedores possam identificar rapidamente se uma nova versão foi comprometida.
Essas recomendações não surgiram do nada. Elas são uma resposta direta ao aumento de ataques à cadeia de suprimentos de software, nos quais criminosos exploram a confiança em bibliotecas, frameworks e componentes de terceiros para inserir código malicioso em projetos legítimos. Em vez de atacar diretamente uma empresa ou órgão governamental, os invasores comprometem o elo mais frágil da cadeia: as dependências usadas em larga escala.
Nas últimas semanas, diversos pacotes hospedados em plataformas populares como GitHub, npm e o Índice de Pacotes Python (PyPI) foram infectados com malware. Desenvolvedores que utilizavam esses pacotes em seus projetos e atualizaram para as versões maliciosas acabaram levando o código contaminado diretamente para dentro de seus ambientes de desenvolvimento e produção.
Uma vez instalado, o malware passou a roubar credenciais de login, tokens de acesso, chaves de API e outros segredos sensíveis armazenados nas máquinas dos desenvolvedores ou em variáveis de ambiente. Em alguns casos, o código malicioso também alterou pipelines de construção (CI/CD), contaminando binários, imagens de contêiner e outros artefatos de software, multiplicando o impacto da infecção ao longo de toda a cadeia de desenvolvimento.
Diante desse cenário, o NCSC reforça que equipes de desenvolvimento podem – e devem – adotar imediatamente medidas práticas para reduzir o risco de serem vítimas de ataques à cadeia de suprimentos. A primeira recomendação é óbvia, mas muitas vezes ignorada: revisar manualmente novas atualizações, dependências e versões antes de colocá‑las em ambientes de produção. Isso inclui analisar notas de versão, mudanças de mantenedor, tamanho dos binários e até padrões suspeitos no código-fonte, quando disponível.
Outra orientação importante da agência britânica é a suspensão de atualizações automáticas de dependências em caso de suspeita ou confirmação de um ataque à cadeia de suprimentos envolvendo determinado ecossistema, linguagem ou repositório. Em um contexto de crise, manter atualizações automáticas ligadas pode se transformar em uma porta aberta para que versões maliciosas se disseminem silenciosamente por dezenas de projetos ao mesmo tempo.
O NCSC também recomenda que desenvolvedores e organizações façam um mapeamento detalhado de todas as dependências utilizadas em seus projetos – tanto diretas (as que são instaladas explicitamente) quanto transitivas (as que vêm “de brinde” por causa de outras bibliotecas). Sem essa visão, fica praticamente impossível saber, em caso de incidente, quais projetos estão expostos e qual o real alcance de uma vulnerabilidade ou pacote comprometido.
Um ponto central do alerta é o equilíbrio entre a necessidade de aplicar patches rapidamente e a prudência ao atualizar dependências. Atualizar tudo no mesmo dia em que o pacote é lançado pode ser tão perigoso quanto adiar indefinidamente a aplicação de correções de segurança. A recomendação é adotar uma estratégia graduada: priorizar patches críticos, testar em ambientes de staging e liberar atualizações de forma controlada, monitorando erros, comportamento anômalo e feedback dos usuários.
Para entender melhor a gravidade do problema, é importante lembrar o que são dependências de software. Em praticamente todos os projetos modernos, boa parte do código vem de terceiros: bibliotecas de criptografia, frameworks web, ferramentas de logging, clientes de banco de dados, SDKs de serviços em nuvem e muito mais. Esse “lego” de componentes acelera o desenvolvimento, mas também amplia a superfície de ataque. Se um único bloco for comprometido, todo o castelo pode ruir.
Ataques recentes mostram que criminosos não dependem apenas de falhas técnicas. Muitas vezes, o vetor é social. Há casos em que mantenedores legítimos abandonaram um projeto e transferiram a propriedade do pacote a um desconhecido, que depois introduziu código malicioso. Em outros, invasores roubaram credenciais de mantenedores respeitados, publicando versões “oficiais” com malware embutido. Isso torna ainda mais essencial verificar mudanças de mantenedor, histórico de versões e sinais de atividade suspeita.
Na prática, proteger a cadeia de dependências exige uma combinação de processos, cultura e tecnologia. Times de desenvolvimento podem, por exemplo, implementar um processo de aprovação de novas bibliotecas, em que qualquer inclusão ou mudança de dependência crítica passe por revisão de pares ou da equipe de segurança. Outra boa prática é manter um mirror interno ou repositório privado, no qual as versões aprovadas são armazenadas e replicadas, reduzindo a exposição direta a repositórios públicos.
Ferramentas de análise de composição de software (SCA) também têm um papel importante. Elas identificam automaticamente todas as dependências de um projeto, verificam versões vulneráveis conhecidas e ajudam a gerar um inventário – muitas vezes chamado de “bill of materials” de software. Embora não sejam uma solução mágica, essas ferramentas facilitam o monitoramento contínuo e agilizam a resposta quando uma biblioteca específica é apontada como comprometida.
No nível de pipeline, é recomendável configurar ambientes de integração contínua (CI) e entrega contínua (CD) de forma que atualizações de dependências passem por testes automatizados e, preferencialmente, revisões manuais quando houver mudanças significativas. Monitorar comportamentos atípicos após uma atualização – como conexões inesperadas para domínios externos, aumento de consumo de CPU ou alterações em arquivos sensíveis – pode ajudar a detectar rapidamente a presença de malware.
Outro aspecto frequentemente negligenciado é a gestão de credenciais. Como os ataques relatados tiveram como principal objetivo o roubo de tokens, chaves e senhas, é fundamental que essas informações não fiquem espalhadas em arquivos locais, scripts de automação ou repositórios de código. O uso de cofres de segredos, rotação frequente de chaves e o princípio do menor privilégio reduzem drasticamente o impacto de uma possível infecção na máquina de um desenvolvedor.
Organizações também devem investir em treinamento contínuo para desenvolvedores, arquitetos e engenheiros de DevOps. Muitos profissionais ainda assumem que, se um pacote está em um repositório popular, ele é automaticamente confiável. A nova realidade exige uma mentalidade diferente: zero trust aplicado também a bibliotecas de terceiros. Isso inclui desconfiar de atualizações súbitas, mudanças de comportamento da aplicação e permissões excessivas solicitadas por novos componentes.
Por fim, a mensagem central das agências de segurança é clara: a conveniência das atualizações automáticas não pode se sobrepor à segurança. Automatizar sem critérios, especialmente em ambientes críticos, é um convite para que atacantes explorem a confiança cega nos ecossistemas de pacotes. Ao adotar checagens manuais, mapear dependências, controlar o ritmo das atualizações e fortalecer práticas de desenvolvimento seguro, empresas e desenvolvedores reduzem significativamente o risco de ver seus projetos transformados em vetores de ataque contra usuários, parceiros e a própria organização.