Foram algumas semanas difíceis. Um portátil de um programador esteve na origem do maior roubo da história das criptomoedas na Binance. O LiteLLM foi comprometido, mais uma vez, no PyPI. O PHP2Shell e o Node2Shell afetaram o PHP e o Node.js, que, em conjunto, suportam uma enorme parte da Web. E não nos esqueçamos do eMudhra e das chaves privadas que puderam ser recuperadas em segundos.
Estes incidentes basearam-se em técnicas conhecidas e apresentaram muito pouca sofisticação. No entanto, os atacantes agiram rapidamente e o intervalo de tempo entre a divulgação e a exploração está a encurtar-se rapidamente. No caso de algumas vulnerabilidades, esse intervalo já se esgotou.
As equipas devem partir do princípio de que um computador portátil, um fornecedor, um pacote de software ou um executor de CI no seu ambiente acabará por ser comprometido em algum momento. Quando isso acontecer, os danos dependerão do alcance que o atacante conseguir atingir a partir daí.
A seguir, apresentamos seis práticas que recomendamos para se manter em segurança até ao final de 2026.
Tornar as credenciais roubadas inutilizáveis
Já vimos os graves danos que as credenciais roubadas causam nas mãos dos atacantes, pelo que é fundamental limitar o alcance dos danos assim que uma credencial é exposta. A maioria das equipas não se preparou para o cenário em que as suas credenciais sejam efetivamente roubadas. Partir do pressuposto de que estas serão expostas facilita a implementação dos controlos compensatórios adequados.
Na prática, isso significa:
- Utilize tokens de curta duração ou acesso «just-in-time» (JIT), para que um serviço ou uma pessoa só tenha acesso a um segredo durante o tempo necessário para a realização da tarefa. Se essa credencial for comprometida, já estará prestes a expirar ou já terá expirado.
- Mantenha os âmbitos restritos. Se um serviço precisar apenas de acesso de leitura, não lhe conceda também acesso de escrita.
- Torne a autenticação de três fatores uma norma em todas as ferramentas. Ative a autenticação de dois fatores (2FA) sempre que possível. Por exemplo, exija a 2FA no GitHub e adicione restrições de IP.
- Analise as suas aplicações para identificar quaisquer chaves API e tokens que tenham sido emitidos. Avalie para que fins estão a ser utilizados. Certifique-se de que compreende o seu âmbito de aplicação. Revogue aqueles que não são necessários ou utilize a auditoria para definir um plano de rotação de credenciais.
Proteja o código que não escreveu
O PHP2Shell deixou dolorosamente claro o quão grande é o risco inerente ao código que se herda. As imagens base e as bibliotecas de código aberto vêm com os seus próprios problemas, tal como os ambientes de execução subjacentes. Torna-se responsável por tudo isso no momento em que entra no seu ambiente. Não é possível evitar herdar código, mas pode escolher o que herda e de que forma.
Na prática:
- Comece com imagens « container » mínimas. Estas incluem muito menos pacotes do que as imagens padrão, o que significa, por predefinição, uma superfície de ataque mais reduzida e menos CVEs.
- Combine imagens minimalistas com um fornecedor de imagens reforçadas do container , para que qualquer CVE que surja seja corrigido rapidamente.
- Crie bifurcações ou espelhe bibliotecas internamente e utilize-as a partir do seu próprio feed.
- Utilize bibliotecas reforçadas para dependências em fim de vida útil ou sempre que necessitar de um suporte alargado ao longo do ciclo de vida, com correções de segurança retroativas.
- Descubra quais são os produtos em fim de vida, verificando se o seu portfólio inclui versões que já não são mantidas.
- Utilize o análise de composição de software (SCA) para monitorizar todas as dependências de código aberto, incluindo as transitivas, e para comunicar e corrigir as vulnerabilidades que forem detetadas.
- Aplique as correções assim que forem divulgadas informações críticas. Atualmente, as explorações de vulnerabilidades surgem poucos dias após a divulgação.
Elimine os fornecedores de que não precisa
A proliferação de fornecedores é uma realidade, e cada fornecedor que introduz na sua organização representa um risco se não for bem gerido. Aquele plugin do GitHub que instalou no ano passado e só utilizou uma vez? Isso é um risco. O mesmo se aplica à dependência do npm que instalou para um projeto do qual já se afastou. Os fornecedores incluem qualquer entidade cujo código ou serviços sejam executados no seu ambiente, desde empresas a quem paga até mantenedores de software de código aberto.
Na prática:
- Crie um inventário bem gerido de todas as aplicações, plug-ins, integrações e serviços em todo o seu ambiente.
- Elimine os fornecedores externos sempre que possível. No que diz respeito aos que mantiver, espelhe ou utilize um proxy para os seus serviços através do seu próprio feed de artefactos.
- Limite ao mínimo as extensões e os plug-ins do IDE.
- Enumere todas as autorizações OAuth, aplicações do GitHub, tokens de acesso pessoal e integrações SaaS ligadas, e revogue as que não utiliza.
- Avalie cada fornecedor antes de o integrar. Pergunte quem é responsável pela sua manutenção e de que tipo de acesso necessita, e verifique se já dispõe de alguma solução que desempenhe a mesma função.
- Excluir os fornecedores externos assim que um projeto terminar ou um contrato chegar ao fim.
- Inclua cenários de violação de segurança por parte de fornecedores no seu plano de resposta a incidentes e teste-os. Parta do princípio de que um dos seus fornecedores sofre uma violação de segurança e, em seguida, analise como a sua equipa reage.
Coloca em modo offline o que não precisa de estar online
O PHP2Shell demonstrou que as equipas precisam de justificar cada serviço que mantêm online e de identificar rapidamente o que está a ser executado em todo o seu ambiente.
Aquele servidor web esquecido de 2019, aquele que «só devia estar a funcionar para alguns trabalhos de desenvolvimento internos», é exatamente o tipo de recurso informático sem atualizações que os atacantes visam. Muitas vezes, as equipas só descobrem a sua existência quando já é tarde demais.
Na prática:
- Faça uma análise do seu património, incluindo o seu superfície de ataque externa, e elabore um inventário de todos os serviços e sistemas em funcionamento.
- Analisa essa lista com atenção e prepara-te para justificar a razão pela qual cada item está incluído.
- Assegure a responsabilização pelos recursos, atribuindo a cada um deles um responsável e uma finalidade. Identifique também os ambientes e imponha a utilização de etiquetas por meio de políticas.
- Mantenha os sistemas fora da Internet pública, a menos que seja necessário que estejam lá. Coloque as ferramentas internas atrás de uma VPN ou de um sistema de acesso «zero-trust».
- Ensaie bem o seu processo de aplicação de correções, para estar preparado quando forem divulgadas informações críticas.
- Utilize horários de desligamento automático para que os recursos de computação só fiquem ativos quando forem necessários. Um cluster de desenvolvimento do Kubernetes que só utiliza às terças-feiras pode ficar desligado durante o resto da semana, o que também irá reduzir a sua fatura.
Controlar o que é executado nos computadores dos utilizadores
Os ataques de malware contra dispositivos estão a aumentar e, numa única semana, oAikido bloqueou quase 500 deles. Os computadores dos programadores constituem um alvo apetecível, uma vez que contêm credenciais e acesso a sistemas que, por vezes, são críticos. As secções acima abordam a forma de limitar o que essas credenciais podem fazer, e controlar o que é efetivamente executado nos computadores dos programadores reduz ainda mais a superfície de ataque. A violação de segurança da Vercel este ano também nos mostrou como uma única extensão de navegador pode conduzir a um incidente.
Na prática, isso significa:
- Auditar os computadores dos utilizadores e elaborar um inventário do software instalado e das respetivas versões, incluindo extensões de navegador, extensões de IDE, servidores MCP e ferramentas de IA.
- Bloqueia a instalação de novos plugins e extensões até que estes tenham sido aprovados.
- Mantenha uma lista de endereços autorizados para que as pessoas não tenham de esperar pelos endereços mais comuns.
- Impor um período mínimo de espera para os pacotes. A maioria dos pacotes maliciosos é detetada no espaço de algumas horas, pelo que um período de espera reduz o risco de instalar uma versão maliciosa.
- Mantenha os ficheiros « secrets » fora do disco. Os programas de roubo de informações procuram, em primeiro lugar, tokens em texto simples nos ficheiros .env e no histórico do shell. Os gestores de « Secrets » e os tokens de curta duração são os seus aliados neste caso.
Ataca-te a ti próprio primeiro
«Verifica tudo antes de te prejudicares» é um conselho de segurança válido. Realiza testes de penetração na tua rede e automatiza os testes de simulação de ataques nos serviços que geres, para que possas detetar as falhas antes que outra pessoa o faça.
Resolver uma fuga antes que se transforme numa inundação parece óbvio, mas será que o fazes mesmo? As ferramentas automatizadas facilitam essa tarefa. Na prática:
- Implemente ferramentas de « gerenciamento da superfície de ataque » (ASM) em todo o seu ambiente, para saber o que está exposto, incluindo aquilo de que já se tinha esquecido que possuía.
- Realize testes de penetração na rede externa regularmente, e não apenas uma vez.
- Teste continuamente as aplicações que são lançadas com frequência, em vez de tratar os testes como uma tarefa que se faz uma vez por ano apenas para cumprir o formalismo.
- Simule uma violação através de exercícios de simulação e teste o que um atacante poderia efetivamente alcançar a partir de um equipamento comprometido ou de um executor de CI.
Lista de verificação completa
Prepara a tua equipa, passo a passo.
Esta semana
- Procure nas máquinas dos programadores credenciais de acesso à nuvem, chaves SSH, tokens de API e ficheiros .env.
- Defina uma idade mínima de 48 horas para cada gestor de pacotes que utilizar, incluindo o npm e o PyPI.
- Comece a bloquear malware logo na fase de instalação com a Safe Chain d Aikido .
- Verifica o que está acessível a partir da Internet e retira da rede tudo o que não precise de lá estar.
Este mês
- Transfira o « secrets » de produção dos portáteis para um gestor de « secrets » e atualize todas as credenciais que encontrou nos computadores dos programadores.
- Verifique as dependências e elimine as que não são utilizadas ou que não são mantidas.
- Crie um inventário de fornecedores que inclua as suas aplicações, plugins, dependências e serviços, e atribua um responsável a cada um deles.
- Defina horários de desligamento automático para os recursos de computação que não se destinam à produção.
- Retire os direitos de administrador local nos computadores dos utilizadores, sempre que possível.
- Execute o comando « análise de código com IA » no código exposto à Internet e no código que lida com autenticação ou pagamentos.
- Armazene o fornecedor de identidade, a auditoria na nuvem, o controlo de código-fonte e os registos de CI num local onde as credenciais de produção não os possam eliminar.
- Estabeleça um prazo para a correção de vulnerabilidades críticas expostas à Internet, medido em horas ou dias.
Antes do final de 2026
- Implemente o « gerenciamento da superfície de ataque » em todo o seu parque de equipamentos.
- Realize um teste de penetração à rede externa e marque o próximo para 2027.
- Realize exercícios de simulação que pressuponham uma violação através de um fornecedor comprometido, do computador portátil de um programador, de um executor de CI ou de um pacote.
- Faça uma revisão de fim de ano de todos os seus fornecedores e inventários de serviços, para que cada item tenha um responsável no início de 2027.
Para mais informações, consulte as melhores práticas dosegurança da supply chain de software .
Conclusão
Novas vulnerabilidades (CVEs) e pacotes comprometidos continuarão a surgir até ao final do ano e muito além disso. Parta do princípio de que será afetado em algum momento e certifique-se de que está na posição mais sólida possível quando isso acontecer. As equipas que limitam o alcance de um único incidente conseguirão conter o próximo incidente mais rapidamente do que as equipas que dependem do bloqueio de todos os pontos de entrada.
Para uma perspetiva a mais longo prazo, leia o «PHP2Shell», depois de amanhã.
