No segundo trimestre de 2026, aAikido Intel analisou cerca de 7,5 milhões de versões de pacotes. Entre os nossos sistemas automatizados e os investigadores humanos, confirmámos 19 500 pacotes maliciosos. Os atacantes têm vindo a abusar das dependências de código aberto para se infiltrarem no software, e o ataques à Supply chain começou a registar um aumento acentuado em meados de 2025. Pacotes populares como o axios e ferramentas de segurança como Trivy e Checkmarx foram comprometidos.
Este guia apresenta as melhores práticas de segurança da cadeia de abastecimento que teriam impedido os ataques dos últimos 18 meses. Se quiser aprofundar o tema, consulte a lista de verificação prática para se defender contra o « ataques à Supply chain ». A lista de verificação prática completa abrange 30 controlos relacionados com contentores, reforço de infraestruturas de código (CI) e muito mais, classificados por ordem de prioridade para que saiba por onde começar.
{{cta}}
Impedir que o malware se instale
Aplicar um prazo mínimo de 48 horas para a idade da encomenda
Um período de espera bloqueia qualquer versão publicada recentemente. A maioria das versões comprometidas é sinalizada e retirada poucas horas após a publicação, o que significa que um filtro de 48 horas as deteta. O filtro cria um intervalo de tempo entre a publicação e a adoção. Aplique-o no registo privado ou no gestor de pacotes. O npm tem idade mínima de lançamento desde a versão 11.10.0, e tanto o Yarn como o Bun incluem os seus próprios sistemas de verificação de idade.
Bloquear os ganchos pós-instalação com o `ignore-scripts`
Não é necessário utilizar um pacote para que este execute código no seu computador; basta instalá-lo. Quando executa o comando «npm install», o npm executa qualquer script pós-instalação que o autor do pacote tenha escrito, utilizando os seus privilégios. Desative os scripts de instalação com --ignore-scripts e inclua na lista de permissões os poucos pacotes que realmente precisam de compilar algo. Aplique a mesma configuração na integração contínua (CI) e nos computadores dos programadores, para detetar credenciais que se encontrem no portátil.
As tendências do ecossistema estão a avançar na direção certa
O pnpm desativou os scripts de instalação de dependências por predefinição na versão 10, em janeiro de 2025, e, em seguida, ativou um período de espera de 24 horas por predefinição em v11 em abril de 2026. npm v12 foi lançado a 8 de julho de 2026 com os scripts de instalação de dependências desativados por predefinição, embora os seus próprios scripts continuem a ser executados, e não tem qualquer tempo de espera predefinido, pelo que ainda pode definir idade mínima de lançamento você mesmo. Atualizar o seu gestor de pacotes é a forma mais económica de garantir parte de ambos os controlos. As equipas que utilizam versões mais antigas e outros ecossistemas precisam das configurações explícitas acima referidas. O que um período de espera teria impedido
O axios o atacante publicou um isco inofensivo, plain-crypto-js@4.2.0, a 30 de março, e depois substituiu pelo ficheiro malicioso plain-crypto-js@4.2.1 às 23:59 UTC. O sistema de deteção automática assinalou o incidente seis minutos depois. axios@1.14.1 foi lançado às 00:21 UTC do dia 31 de março, e axios@0.30.4 Seguiu-se às 01:00. O npm removeu ambas as versões do axios cerca de três horas após a primeira ter sido lançada. Um período de espera de 48 horas teria mantido as equipas a salvo de ambas, com cerca de 45 horas de margem.
O CanisterWorm republicou versões de patch incrementadas de todos os pacotes mantidos pelas suas vítimas, atingindo mais de 60 pacotes em 24 horas. A maioria foi sinalizada poucos minutos após a publicação, pelo que um filtro de 48 horas os teria mantido fora do seu resolvedor. Pelo menos um passou despercebido durante cerca de 53 horas, razão pela qual o filtro funciona melhor em conjunto com a deteção de malware durante a instalação.
Prenda tudo o que possa ser levado pelo vento
Envie um ficheiro de bloqueio e aplique-o no seu pipeline
Um ficheiro de bloqueio regista a versão exata e o hash de integridade de cada dependência, incluindo as transitivas. Aplicar esta regra significa que o seu pipeline executa o comando «npm ci» em vez de «npm install», uma vez que o «npm ci» realiza a instalação estritamente a partir do ficheiro de bloqueio e falha imediatamente se o ficheiro «package.json» se tiver desviado do mesmo. Todos os outros ecossistemas dispõem do mesmo modo sob um nome diferente, como --ficheiro-de-bloqueio-congelado no pnpm, --imutável em Yarn, --bloqueado na secção «Cargo», e --require-hashes no pip. Torna isso uma verificação obrigatória antes da fusão, para que a regra se aplique a toda a equipa.
Associe o seu pipeline aos SHA dos commits
Todas as plataformas de CI permitem-lhe importar dependências e, na maioria dos casos, estas são referenciadas através de uma etiqueta ou do nome de um ramo. Ambos são indicadores que quem controla o repositório de código-fonte pode alterar a qualquer momento. A fixação a um SHA de commit elimina a possibilidade de desvio, uma vez que um SHA se refere a uma árvore de código específica e não pode ser redirecionado. O GitHub Actions, o GitLab, o Buildkite e o Jenkins aceitam todos um SHA em vez de uma etiqueta. O CircleCI funciona de forma diferente, uma vez que as versões de orb publicadas são imutáveis após o lançamento, pelo que uma versão exata é suficiente.
O inconveniente é que deixas de receber automaticamente as correções do upstream; por isso, combina esta correção com um bot que abra PRs para atualizar o SHA. O Renovate suporta, entre outros, o Actions e o GitLab, e pode fazer por ti a conversão inicial de tags para SHAs. Dependabot Mantém as fixações de Actions existentes atualizadas, mas funciona apenas com o GitHub Actions.
Fixar imagens de base em resumos
Uma etiqueta de imagem do tipo « container » também é um ponteiro mutável. A etiqueta «node:22-alpine» aponta, este mês, para uma imagem diferente daquela a que apontava no mês passado, e nada no seu Dockerfile regista qual foi a imagem utilizada na compilação.
Fixa a linha «FROM» a um resumo para que a compilação seja reproduzível e as alterações do upstream exijam a tua aprovação. Em seguida, programa uma recompilação automática, uma vez que um resumo fixado também significa que deixas de receber patches do upstream até o alterares deliberadamente.
O que é que o «pinning» teria impedido?
Em março de 2025, os atacantes comprometeram o tj-actions/changed-files A Action redirecionou todas as etiquetas de versão para um commit malicioso que inseriu o código « secrets » nos registos do fluxo de trabalho da integração contínua (CI). Cerca de 23 000 repositórios faziam referência a esse código e, nos repositórios públicos, esses registos estavam acessíveis a qualquer pessoa.
Todos os fluxos de trabalho que faziam referência a uma etiqueta carregavam o código malicioso na sua execução seguinte. Os repositórios que tinham sido fixados a um SHA de commit não foram afetados.
Controlar o acesso e a identidade
Tokens de âmbito
Um token com direitos de publicação em toda a organização é perigoso, pois quem o obtiver pode publicar qualquer coisa que seja da sua autoria. Utilize tokens com permissões detalhadas, limitados a repositórios e pacotes específicos, e emita uma credencial separada para cada pipeline, em vez de partilhar uma única credencial entre executores e máquinas. Faça a rotação de acordo com um calendário definido e imediatamente em caso de qualquer suspeita, e revogue a credencial assim que alguém sair de um projeto.
Um programador da CrowdSec que já não trabalhava na empresa manteve o acesso ao GitHub para concluir alguns trabalhos, e o seu portátil foi comprometido no ataque TanStack. Um atacante utilizou o token dessa máquina para clonar 170 repositórios privados da CrowdSec em cerca de nove minutos. A empresa só descobriu o que tinha acontecido quatro meses depois, quando o código apareceu num fórum.
Mudar as contas dos responsáveis pela manutenção para FIDO2 ou chaves de acesso
Uma palavra-passe única baseada no tempo (TOTP) é melhor do que nada, mas está sujeita a phishing. Um atacante captura o código numa página de início de sessão falsa e convincente e reproduz-o no site verdadeiro dentro do intervalo de trinta segundos, o que é suficiente para a apropriação da conta sem que seja necessário qualquer malware. O FIDO2 e as chaves de acesso estão criptograficamente ligados ao domínio legítimo. Se mantiver um pacote amplamente utilizado, mantenha o endereço de e-mail da conta atualizado e esteja atento, uma vez que o npm congela contas de alto impacto durante 72 horas após uma alteração de e-mail ou uma recuperação da autenticação de dois fatores (2FA) e envia o alerta para o endereço anterior.
Trate o computador do programador como se fosse um ambiente de produção
Instale o sistema de deteção de terminais em todos os computadores dos programadores
Um portátil de programador contém código-fonte, credenciais de acesso à nuvem, tokens de publicação e uma sessão autenticada para a maior parte da sua infraestrutura, razão pela qual os terminais dos programadores são agora um dos principais alvos do ataques à Supply chain. As ferramentas EDR tradicionais detetam as ameaças só depois de estas estarem em execução, o que deixa uma janela de oportunidade durante a qual as credenciais podem ser roubadas ou pacotes maliciosos instalados antes de qualquer alerta ser acionado.
Procure ferramentas de endpoint que verifiquem as instalações do npm e do pip no momento em que estas ocorrem e que possam aplicar políticas de instalação, tais como limites mínimos de antiguidade dos pacotes ou listas de permissão para extensões de IDE e plug-ins de navegador.
Aplicar a lista de extensões autorizadas de forma centralizada
As extensões IDE e os plug-ins de navegador são executados com privilégios reais e atualizam-se automaticamente sem pedir autorização. Mantenha uma lista de extensões aprovadas e aplique-a a partir de uma política central. O nosso guia de segurança para extensões de navegador aborda este tema de forma mais aprofundada, especificamente no que diz respeito ao navegador.
O que isto teria evitado
Em abril de 2026, Aikido descobriu uma extensão falsa do WakaTime no OpenVSX que continha um binário nativo que era carregado antes de qualquer lógica legítima da extensão, descarregava uma segunda carga útil a partir de uma página do GitHub Releases e a instalava à força em todos os editores compatíveis na máquina, utilizando o próprio instalador de linha de comandos de cada editor. Bastou uma instalação para que o VS Code, o Cursor, o Windsurf e o VSCodium fossem todos infetados. Uma lista de permissões central teria impedido isto, uma vez que uma extensão WakaTime falsa publicada por uma conta desconhecida não constaria da lista de aprovados.
A limitação de uma lista de extensões autorizadas é que esta só é útil enquanto uma extensão aprovada se mantiver inofensiva. O GlassWorm também já comprometeu extensões legítimas que muitas equipas teriam aprovado, e essas atualizam-se sem deixar qualquer registo para que alguém possa analisar, razão pela qual a camada de verificação no momento da instalação é importante a par da lista.
Proteja os seus agentes
Verificar as permissões no momento da configuração e isolar o ambiente de execução
Um agente capaz de executar comandos de shell arbitrários e aceder à sua base de dados de produção está a um passo — basta uma ferramenta comprometida — de uma violação total. Conceda apenas as permissões necessárias para a tarefa específica e reveja-as da mesma forma que reveria uma conta de serviço. Em seguida, execute o agente numa sandbox com controlos de saída de rede, para que, mesmo que seja comprometido, o agente não consiga aceder a nada fora dos limites que definiu.
A definição do âmbito na fase de configuração e o ambiente isolado em tempo de execução resolvem duas vertentes diferentes do problema. A primeira limita o que o agente está autorizado a solicitar. A segunda limita o que acontece quando algo leva o agente a solicitar mais.
Tratar os servidores MCP como dependências
Os servidores MCP apresentam os mesmos riscos da cadeia de abastecimento que qualquer outra dependência; por isso, só deve instalar servidores MCP a partir de fontes verificadas, como o Registo MCP oficial do GitHub. No caso dos servidores MCP distribuídos pelo npm, fixe-os através do hash de integridade no seu ficheiro de bloqueio. Para os servidores baseados em git, fixe-os a um SHA de commit completo, em vez de a um ramo ou a uma etiqueta. Verifique se o repositório é mantido e se o editor é conhecido antes de proceder à instalação. Se estiver a obter o servidor de um registo, trate um servidor MCP não verificado da mesma forma que trataria um pacote npm não verificado.
Em setembro de 2025, surgiu no npm um pacote chamado «postmark-mcp», que se fazia passar pelo servidor MCP oficial que a ActiveCampaign mantém para o serviço de e-mail Postmark. A sua função era permitir que um assistente de IA enviasse e-mails através da sua conta Postmark e, durante quinze versões, fez exatamente isso e nada mais. A versão 1.0.16 adicionou uma linha. Todos os e-mails enviados pelo servidor eram copiados em cópia oculta para um endereço controlado pelo atacante, através da própria conta da vítima, o que significava que as redefinições de palavra-passe, as faturas e tudo o mais que fosse solicitado a um agente enviar também eram encaminhados para um estranho.
Tratar qualquer entrada não fiável que chegue a um agente como execução de código
AikidoA investigação «PromptPwnd» foi a primeira demonstração confirmada, no mundo real, de que a injeção de prompts pode comprometer pipelines de CI/CD¹, afetando pelo menos cinco empresas da Fortune 500. Um título de issue malicioso introduzido num fluxo de trabalho da CLI do Gemini levou o agente a escrever o repositório secrets num tópico público de issue, utilizando o seu próprio acesso legítimo.
Audite qualquer fluxo de trabalho que encaminhe o título de uma issue ou a descrição de um pedido de integração para um prompt de um agente. Considere a saída do agente que chegue a um comando de shell ou a uma gravação num ficheiro como não fiável até que seja validada.
Detetar pacotes maliciosos no momento da instalação e, posteriormente, no repositório
Os agentes de programação inventam nomes de pacotes que parecem plausíveis, mas que não existem, e os atacantes começaram a registar esses nomes antecipadamente e a aguardar. O agente instala-o sem pensar duas vezes, porque o nome corresponde ao que esperava encontrar.
Para prevenir o «slopsquatting», é necessária a deteção de malware em dois locais. O primeiro é no computador, no momento da instalação, onde se deteta se o agente está a descarregar algo durante uma sessão — trata-se do mesmo controlo referido anteriormente na secção relativa ao momento da instalação. O segundo é no repositório, onde um pedido de integração que introduza uma nova dependência é verificado antes de alguém o integrar. Esta segunda camada existe porque um nome de pacote incorreto pode entrar na base de código a partir do computador de um programador que nunca tenha tido o controlo na fase de instalação configurado.
Tenha um plano para a primeira hora de um ataque de malware
Registar registos de auditoria
Transmita o registo de auditoria da sua organização para um SIEM. Os eventos mais importantes são as alterações no registo e a utilização de tokens, uma vez que é aí que uma violação se torna visível antes de qualquer outro indício. Quanto aos aspetos específicos sobre os quais se deve alertar, a nossa lista de verificação de segurança do GitHub Actions abrange os eventos que vale a pena monitorizar.
O atacante do Axios efetuou a publicação manualmente utilizando um token do npm de longa duração obtido da máquina comprometida do responsável pela manutenção, pelo que não foi possível detetar qualquer início de sessão suspeito. O que permitiu aos responsáveis pela resposta estabelecer a cronologia do incidente foi o registo do repositório: a alteração do e-mail da conta para um endereço controlado pelo atacante e, em seguida, a publicação de duas versões com um intervalo de 39 minutos entre elas, ambas com data e hora registadas.
Gerar SBOMs assinadas para que a questão da exposição tenha uma resposta
Quando é publicado um novo CVE ou surge um pacote comprometido, as equipas que não dispõem de um « lista de materiais de software » (SBOM) atualizado passam horas a rastrear manualmente as dependências para descobrir se estão afetadas. Gere um para cada artefacto de compilação, incluindo dependências transitivas, uma vez que a maioria das vulnerabilidades se encontra a vários níveis de profundidade. A carga maliciosa do axios chegou através de um pacote que ninguém tinha instalado explicitamente. Assine o ficheiro de certificação de integridade ( SBOM ) no momento da compilação, para que fique criptograficamente vinculado à compilação que o produziu, e guarde-o juntamente com o artefacto no seu registo, para que ambos permaneçam sincronizados.
Ensaie o plano de rotação antes de precisar dele
Documente quais as credenciais que devem ser alternadas para cada pipeline e quem tem autoridade para alternar cada tipo. Em seguida, registe como confirma que uma rotação foi efetivamente concluída e realize o exercício de simulação. Conheça antecipadamente a sua opção de emergência. O GitHub Enterprise suporta a revogação em massa de credenciais para um utilizador comprometido ou para todos os utilizadores da empresa de uma só vez. É uma medida drástica, mas é preferível a alternar serviço a serviço quando ainda não se sabe até que ponto a violação se estendeu.
Como o « Aikido Security» ajuda a proteger contra ataques à Supply chain
Aikido A segurança abrange as camadas de instalação e de repositórios descritas neste artigo. O seu sistema de deteção funciona num processador Intel d Aikido , que analisa todos os novos pacotes numa média de seis minutos e, frequentemente, identifica os maliciosos no prazo de um ou dois minutos após o seu lançamento.
A Proteção de Dispositivos abrange o que é instalado nos computadores dos programadores e bloqueia pacotes e extensões maliciosas em toda a organização. O Safe Chain é a versão gratuita e de código aberto destinada a particulares, que bloqueia pacotes maliciosos no momento da instalação.
A mesma detecção «Aikido » da Intel é executada nos seus repositórios, pelo que uma dependência maliciosa que chegue a um pedido de integração é sinalizada antes de alguém a integrar, incluindo um nome de pacote «alucinado» proveniente de uma máquina sem proteção no momento da instalação. SAST abrange a camada de configuração, sinalizando entradas não confiáveis que chegam a um prompt do agente, o que corresponde ao padrão PromptPwnd.
