Como já comentamos em uma postagem anterior, o desenvolvimento de produtos de software modernos é praticamente impossível sem o uso de componentes de código aberto. Mas, nos últimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o código de uma empresa mais rapidamente do que são corrigidas; segundo, os dados são incompletos e pouco confiáveis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, não basta simplesmente verificar os números de versão e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger políticas de download de software, proteções para assistentes de IA e todo o pipeline de criação de software.

Um conjunto confiável de componentes de código aberto

A principal característica de uma solução é impedir o uso de código vulnerável e malicioso. As seguintes medidas devem ser implementadas:

• Ter um repositório interno de artefatos. A fonte única de componentes para desenvolvimento interno precisa ser um repositório unificado no qual os componentes são admitidos somente após uma série de verificações.
• Fazer uma triagem rigorosa dos componentes. Isso inclui verificações de versões conhecidas do componente, versões vulneráveis e maliciosas conhecidas, data de publicação, histórico de atividades e reputação do pacote e de seus autores. É obrigatório verificar todo o conteúdo do pacote, incluindo instruções de compilação, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingestão, use verificadores de código aberto especializados ou uma solução de segurança abrangente de carga de trabalho na nuvem.
• Fixar versões de dependências. Os processos de compilação, as ferramentas de IA e os desenvolvedores não devem usar modelos (como “o mais recente”) ao especificar versões. As compilações do projeto precisam ser baseadas em versões verificadas. Ao mesmo tempo, as dependências com versões fixas devem ser atualizadas com frequência para as versões verificadas mais recentes que mantêm a compatibilidade e não contêm vulnerabilidades conhecidas. Isso reduz significativamente o risco de ataques à cadeia de suprimentos por meio do comprometimento de um pacote conhecido.

Aperfeiçoamento dos dados de vulnerabilidades

Para identificar vulnerabilidades com mais eficácia e priorizá-las de forma adequada, uma organização precisa estabelecer vários processos de TI e segurança:

• Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organização, isso é necessário para enriquecer as informações combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de inteligência de vulnerabilidades comercial no qual os dados já estão agregados e enriquecidos. Em ambos os casos, também vale a pena monitorar os feeds de inteligência de ameaças para rastrear tendências de exploração reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades específicas. A Kaspersky fornece um feed de dados especializado especificamente focado em componentes de código aberto.
• Análise detalhada da composição do software. As ferramentas especializadas de análise de composição de software (SCA) permitem o mapeamento correto da cadeia de dependências no código-fonte aberto para realizar o inventário completo das bibliotecas que estão sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes íntegros também são úteis para enriquecer o registro de artefatos.
• Identificação do abandonware. Mesmo que um componente não apresente vulnerabilidades formais e o encerramento do suporte ainda não tenha sido declarado oficialmente, o processo de verificação deve sinalizar os componentes que não receberam atualizações há mais de um ano. Isso garante uma análise separada e uma possível substituição, assim como ocorre com os componentes em EOL (fim da vida útil).

Proteção do código e dos agentes de IA

As atividades dos sistemas de IA usados na codificação devem ser agrupadas em um conjunto abrangente de medidas de segurança: desde a filtragem de dados de entrada até o treinamento do usuário:

• Restrições de recomendações de dependências. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confiável. Se eles não contiverem as ferramentas corretas, o modelo deve acionar uma solicitação para incluir a dependência no registro em vez de extrair algo do PyPI que apenas corresponda à descrição.
• Filtragem das saídas do modelo. Apesar dessas restrições, tudo o que for gerado pelo modelo também deve ser verificado para garantir que o código de IA não contenha dependências desatualizadas, sem suporte, vulneráveis ou inventadas. Essa verificação deve ser integrada diretamente no processo de aceitação do código ou no estágio de preparação da compilação. Ela não substitui o processo de análise estática tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI/CD.
• Treinamento do desenvolvedor. As equipes de TI e de segurança devem estar extremamente familiarizadas com as características dos sistemas de IA, seus princípios operacionais e erros comuns. Para conseguir isso, os funcionários devem completar um curso de treinamento especializado, adaptados às suas funções específicas.

Remoção sistemática de componentes em EOL

Se os sistemas de uma empresa utilizarem componentes de código aberto desatualizados, deve-se adotar uma abordagem sistemática e consistente para lidar com as vulnerabilidades. Existem três métodos principais para fazer isso:

• Migração. Este é o método mais complexo e caro para uma organização, pois envolve a substituição total de um componente, seguida pela adaptação, reescrita ou substituição dos aplicativos construídos sobre ele. Decidir sobre uma migração é muito mais difícil quando se exige uma revisão geral de todo o código interno. Isso costuma afetar os componentes principais: é impossível migrar facilmente do Node.js 14 ou do Python 2.
• Suporte de longo prazo (LTS). Existe um mercado de serviços de suporte dedicado para projetos legados de larga escala. Às vezes, isso envolve uma bifurcação do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades específicas em versões mais antigas e sem suporte. A transição para o LTS geralmente exige custos de suporte contínuos, mas, em muitos casos, isso ainda pode ser mais econômico do que uma migração completa.
• Controles compensatórios. Com base nos resultados de análises detalhadas, é possível criar um conjunto de medidas de segurança abrangentes para mitigar o risco de exploração das vulnerabilidades de um produto legado. Tanto a eficácia quanto a viabilidade econômica dessa abordagem dependem da função do software na organização.

Os departamentos de segurança, TI e negócios devem trabalhar juntos para escolher um desses três métodos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.

Gerenciamento de vulnerabilidades de código aberto baseado em risco

Todos os métodos listados acima reduzem o volume de softwares e componentes vulneráveis que entram na organização, o que simplifica a detecção e a correção de falhas. Apesar disso, é impossível eliminar todos os defeitos: o número de aplicativos e componentes está crescendo muito rápido.

Portanto, é essencial priorizar as vulnerabilidades com base nos riscos reais que elas representam. O modelo de avaliação de risco deve ser expandido para considerar as características do código aberto, além de responder às seguintes perguntas:

• A ramificação do código vulnerável é realmente executada no ambiente da organização? Deve-se realizar uma análise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de código defeituosos nunca são realmente executados na implementação específica da organização, fazendo com que seja impossível explorar a vulnerabilidade. Certas soluções de SCA podem realizar esta análise. Esse mesmo processo permite avaliar um cenário alternativo: o que acontece se os procedimentos ou componentes vulneráveis forem removidos completamente do projeto? Às vezes, esse método de remediação é surpreendentemente indolor.
• O defeito está sendo explorado em ataques reais? Há um PoC disponível? As respostas a essas perguntas fazem parte de estruturas de priorização padrão, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de inteligência.
• A atividade de criminosos cibernéticos foi relatada nesse registro de dependência ou em componentes relacionados e semelhantes? Estes são fatores adicionais para a priorização.

A consideração desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.

A transparência nunca sai de moda

O padrão de segurança para softwares de código aberto só vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentarão pressões regulatórias que exigem segurança cibernética documentada e verificável nos seus sistemas. De acordo com as estimativas dos especialistas da Sonatype, 90% das empresas em todo o mundo já se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transparência “o pilar fundamental da segurança da cadeia de suprimento de software”.

Ao controlar o uso de componentes e aplicativos de código aberto, enriquecer a inteligência contra ameaças e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organizações podem introduzir as inovações que tanto desejam, ao mesmo tempo em que atingem o padrão elevado definido por reguladores e clientes.

Até bem pouco tempo, somente as empresas especializadas em software e as gigantes em tecnologia precisavam se preocupar com as vulnerabilidades de código aberto e os ataques direcionados contra a cadeia de suprimentos. Porém, os tempos mudaram. Hoje, até mesmo as pequenas empresas estão mantendo suas próprias lojas de desenvolvimento, e isso torna o problema significativo para todo mundo. De maneira ininterrupta, as equipes internas de TI das empresas estão ocupadas escrevendo código, configurando integrações e automatizando fluxos de trabalho, mesmo que o negócio principal não tenha absolutamente nada a ver com software. É o que a eficiência empresarial moderna exige. No entanto, como consequência disso, surge uma nova geração de vulnerabilidades de software, o tipo muito mais complicado de corrigir do que apenas instalar a atualização mais recente do Windows.

O desenvolvimento de software moderno é inseparável dos componentes de código aberto. Porém, os riscos associados proliferaram nos últimos anos, além de terem aumentado em variedade e sofisticação. Estamos testemunhado a injeção de código malicioso em repositórios populares, dados de vulnerabilidade fragmentados e com falhas, o uso sistemático de componentes desatualizados e vulneráveis e as cadeias de dependência cada vez mais complexas.

A escassez de dados de vulnerabilidade para código aberto

Mesmo que sua organização tenha um processo de gerenciamento de vulnerabilidades sólido para software comercial de terceiros, é possível constatar que o código aberto requer uma revisão completa desse processo. Os bancos de dados públicos mais usados geralmente são incompletos, imprecisos ou simplesmente lentos para obter atualizações quando se trata de código aberto. Isso transforma a priorização de vulnerabilidades em um jogo de adivinhação. Por mais automação que possa existir, ela será inútil se os dados de referência estiverem cheios de falhas.

De acordo com os dados da Sonatype, cerca de 65% das vulnerabilidades de código aberto atribuídas a um CVE ID não possuem uma pontuação de vulnerabilidade (CVSS) no NVD, a base de conhecimento de vulnerabilidades mais usada. Dessas vulnerabilidades não pontuadas, quase 46% seriam classificadas como alta, se analisadas adequadamente.

Mesmo quando uma pontuação CVSS está disponível, fontes diferentes estão de acordo apenas no que se refere à gravidade em cerca de 55% das vezes. Um banco de dados pode sinalizar uma vulnerabilidade como crítica, enquanto outro recebe uma pontuação média para ela. Metadados mais detalhados, como as versões de pacotes afetadas, também costumam estar repletos de erros e inconsistências. Seus verificadores de vulnerabilidades que comparam versões de software acabam gerando falsos positivos ou fornecendo falsamente um atestado de integridade.

O déficit nos dados de vulnerabilidade está crescendo e o processo de geração de relatórios está ficando mais lento. Nos últimos cinco anos, o número total de CVEs dobrou, mas o número de CVEs sem uma pontuação de gravidade explodiu por um fator de 37. De acordo com a Tenable, até 2025, o código de exploração de prova de conceito (PoC) esteve normalmente disponível dentro de uma semana após a descoberta de uma vulnerabilidade, mas obter a mesma vulnerabilidade listada no NVD levou em média 15 dias. Os processos de aprimoramento, como atribuir uma pontuação CVSS, são ainda mais lentos, a Sonatype no mesmo estudo estima que o tempo médio para atribuir uma pontuação CVSS é de 41 dias, com alguns defeitos permanecendo sem classificação por até um ano.

O problema do código aberto legado

Bibliotecas, aplicativos e serviços que não são mais mantidos, que foram abandonados ou que atingiram seu fim de vida útil (EOL), podem ser encontrados em 5 a 15% dos projetos corporativos, de acordo com a HeroDevs. Em cinco registros populares de código aberto, há pelo menos 81 mil pacotes que contêm vulnerabilidades conhecidas, mas pertencem a versões desatualizadas e sem suporte. Esses pacotes nunca verão os patches oficiais. Essa “bagagem legada” é responsável por cerca de 10% dos pacotes no Maven Central e no PyPI, e impressionantes 25% no npm.

Usar esse tipo de código aberto quebra o ciclo de vida padrão do gerenciamento de patches: não é possível atualizar, automática ou manualmente, uma dependência que não é mais compatível. Além disso, quando as versões EOL são omitidas dos boletins de vulnerabilidades oficiais, os verificadores de segurança podem categorizá-las como “não afetadas” por um defeito e ignorá-las.

Um excelente exemplo disso é o Log4Shell, a vulnerabilidade crítica (CVSS 10) na popular biblioteca Log4j descoberta em 2021. A versão vulnerável foi responsável por 40 milhões dos 300 milhões de downloads do Log4j em 2025. É importante ressaltar que estamos falando de uma das vulnerabilidades mais infames e amplamente relatadas da história, uma que foi ativamente explorada, corrigida pelo desenvolvedor e tratada em todos os principais produtos derivados. A situação para os defeitos menos divulgados é significativamente pior.

Para agravar esse problema, existe a lacuna de visibilidade. Muitas organizações não têm as ferramentas necessárias para mapear uma árvore de dependências completa ou obter visibilidade total dos pacotes e versões específicos integrados em sua pilha de software. Desse modo, os componentes desatualizados geralmente permanecem invisíveis e nunca entram na fila de correção.

Malware em registros de código aberto

Os ataques que envolvem pacotes de código aberto infectados ou inerentemente maliciosos se tornaram uma das ameaças de crescimento mais rápida para a cadeia de fornecimento de software. De acordo com pesquisadores da Kaspersky, aproximadamente 14 mil pacotes maliciosos foram descobertos em registros populares até o final de 2024, um aumento de 48% a cada ano. A Sonatype relatou um aumento ainda mais explosivo ao longo de 2025 e detectou mais de 450 mil pacotes maliciosos.

A motivação por trás desses ataques varia muito: roubo de criptomoedas, coleta de credenciais de desenvolvedor, espionagem industrial, obtenção de acesso à infraestrutura por meio de pipelines de CI/CD ou comprometimento de servidores públicos para hospedar campanhas de spam e phishing. Essas táticas são empregadas tanto por grupos APT de espionagem quanto por criminosos virtuais motivados financeiramente. É cada vez mais comum a violação de um pacote de código aberto ser apenas o primeiro passo de uma violação corporativa em vários estágios.

Cenários de ataque comuns incluem comprometer as credenciais de um mantenedor de pacote de código aberto legítimo, publicar uma biblioteca “útil” com código malicioso integrado ou publicar uma biblioteca maliciosa com um nome quase idêntico a um popular. Uma tendência particularmente alarmante em 2025 foi o aumento de ataques automatizados semelhantes a worms. O exemplo mais notório é a campanha Shai-Hulud. Nesse caso, o código malicioso roubou os tokens do GitHub e npm e continuou infectando novos pacotes, eventualmente se espalhando para mais de 700 pacotes npm e dezenas de milhares de repositórios. Ele vazou segredos de CI/CD e chaves de acesso à nuvem para o domínio público no processo.

Embora esse cenário não esteja tecnicamente relacionado a vulnerabilidades, as ferramentas de segurança e as políticas necessárias para seu gerenciamento são as mesmas usadas para o gerenciamento de vulnerabilidades.

Como os agentes de IA aumentam os riscos do uso de código aberto

A integração apressada e onipresente de agentes de IA no desenvolvimento de software aumenta significativamente a velocidade do desenvolvedor, mas também amplifica qualquer erro. Sem supervisão rigorosa e proteções claramente definidas, o código gerado por IA fica excepcionalmente vulnerável. A pesquisa mostra que 45% do código gerado por IA contém falhas da lista OWASP Top 10, enquanto 20% dos aplicativos orientados por IA implementados abrigam erros de configuração perigosos. Isso acontece porque os modelos de IA são treinados em grandes conjuntos de dados que incluem grandes volumes de código desatualizado, demonstrativo ou puramente educacional. Esses problemas sistêmicos ressurgem quando um modelo de IA decide quais componentes de código aberto devem ser incluídos em um projeto. O modelo costuma não saber quais versões do pacote existem no momento, nem quais foram sinalizadas como vulneráveis. Em vez disso, ele sugere uma versão de dependência extraída de seus dados de treinamento, que, provavelmente, estará obsoleta. Em alguns casos, os modelos tentam chamar versões inexistentes ou bibliotecas totalmente alucinadas. Isso abre a porta para ataques de confusão de dependência.

Em 2025, mesmo os principais LLMs recomendaram versões de dependência incorretas, simplesmente inventando uma resposta, em 27% dos casos.

A IA pode simplesmente corrigir tudo?

É uma ideia simples e tentadora: basta apontar um agente de IA para sua base de código para que ele procure e corrija todas as vulnerabilidades. Infelizmente, a IA não pode resolver totalmente esse problema. Os obstáculos fundamentais que discutimos prejudicam os agentes de IA tanto quanto os desenvolvedores humanos. Se os dados de vulnerabilidade estiverem ausentes ou não forem confiáveis, em vez de encontrar vulnerabilidades conhecidas, será necessário redescobrir tudo do zero. Esse processo consome muitos recursos e requer conhecimento de nicho que permanece fora do alcance da maioria das empresas.

Além disso, se uma vulnerabilidade for descoberta em um componente obsoleto ou sem suporte, um agente de IA não poderá “corrigir automaticamente” a vulnerabilidade. Ainda será preciso desenvolver patches personalizados ou executar uma migração complexa. Se uma falha estiver profundamente oculta em uma cadeia de dependências, é provável que a IA ignore isso completamente.

O que fazer?

Para minimizar os riscos descritos acima, será necessário expandir o processo de gerenciamento de vulnerabilidades para incluir políticas de download de pacotes de código aberto, regras operacionais do assistente de IA e o processo de compilação do software. Isso inclui:

• usar uma solução abrangente de segurança de carga de trabalho na nuvem;
• verificar pacotes de código aberto usados no processo de desenvolvimento de software com feeds de inteligência de ameaças para componentes de código aberto;
• considerar medidas de segurança para proteger o código de IA e os agentes de IA;
• remover sistematicamente os componentes de código aberto obsoletos.

É possível ler mais detalhes sobre o gerenciamento de vulnerabilidades em código aberto em uma postagem de blog dedicada.

Os ataques a cadeias de suprimentos têm sido uma das categorias mais perigosas de incidentes de cibersegurança há anos. Se o ano de 2025 nos ensinou alguma coisa, é que os cibercriminosos estão aumentando sua capacidade de ataque. Nesta análise detalhada, veremos ataques a cadeias de suprimentos realizados em 2025 que, embora não sejam os que causaram maiores prejuízos financeiros, certamente foram os mais incomuns e chamaram a atenção do setor.

Janeiro de 2025: um RAT encontrado no repositório do GitHub do DogWifTools

Como um “aquecimento” após o fim de ano, os cibercriminosos realizaram inúmeros ataques de backdoor a várias versões do DogWifTools. Trata-se de um utilitário projetado para lançar e promover vigorosamente moedas de meme baseadas em Solana no Pump.fun. Depois de comprometer o repositório privado do GitHub para o DogWifTools, os invasores esperaram os desenvolvedores carregarem uma nova versão do utilitário, injetaram um RAT nela e trocaram o programa legítimo por uma versão maliciosa apenas algumas horas depois. De acordo com os desenvolvedores, os agentes de ameaças instalaram com êxito as versões 1.6.3 a 1.6.6 do DogWifTools para Windows.

O golpe final foi dado no fim de janeiro. Depois de usar o RAT para coletar uma grande quantidade de dados dos dispositivos infectados, os invasores esvaziaram as carteiras de criptomoedas das vítimas. As vítimas estimaram o total de mais de USD 10 milhões em criptomoedas, mas os invasores contestaram esse número, embora não tenham revelado exatamente o valor total roubado.

Fevereiro de 2025: roubo de USD 1,5 bilhão do Bybit

Se janeiro foi só o aquecimento, o mês de fevereiro foi um colapso total. A invasão da plataforma de câmbio de criptomoedas Bybit superou completamente os incidentes anteriores, tornando-se o maior roubo de criptomoedas da história. Os invasores conseguiram comprometer o software Safe{Wallet}, a solução de armazenamento a frio de múltiplas assinaturas na qual a empresa confiava para gerenciar os seus ativos.

Os funcionários da Bybit pensaram que estavam assinando uma transação de rotina. Na realidade, eles estavam autorizando um contrato inteligente malicioso. Uma vez executado, ele esvaziou os fundos de uma carteira fria principal e os distribuiu em várias centenas de endereços controlados pelo invasor. A transferência final ultrapassou 400 mil ETH/stETH, com um impressionante valor total de aproximadamente… USD 1,5 bilhão!

Março de 2025: Coinbase é alvo de comprometimento em cascata do GitHub Actions

O ano de 2025 seguiu com um ataque sofisticado que usou o comprometimento de vários GitHub Actions, os padrões de fluxo de trabalho usados para automatizar tarefas de DevOps padrão, como seu principal mecanismo de entrega. Tudo começou com o roubo de um token de acesso pessoal pertencente a um mantenedor da ferramenta de análise SpotBugs. Usando esse ponto de apoio, os invasores publicaram um processo malicioso e conseguiram sequestrar um token de um mantenedor do fluxo de trabalho reviewdog/action-setup, que também estava envolvido no projeto.

A partir daí, eles comprometeram uma dependência, o fluxo de trabalho tj-actions/changed-files, modificando-o para executar um script Python malicioso. Esse script foi projetado para procurar segredos de alto valor, como chaves da AWS, do Azure e do Google Cloud, tokens do GitHub e do NPM, credenciais de banco de dados e chaves privadas do RSA. Por incrível que pareça, o script gravou tudo o que encontrou diretamente nos registros de compilação acessíveis ao público em geral. Isso significa que os dados vazados não estavam disponíveis apenas para os invasores, mas também para qualquer pessoa experiente o suficiente para acessá-los.

O alvo original dessa operação era um repositório pertencente à plataforma de câmbio de criptomoedas Coinbase. Felizmente, os desenvolvedores detectaram a ameaça a tempo e impediram o comprometimento. Ao que tudo indica, depois de perceberem que estavam prestes a perder o controle do pipeline tj-actions/changed-files, os invasores adotaram uma abordagem indiscriminada. Isso colocou 23 mil repositórios em risco de vazamento de segredos. No final, várias centenas desses repositórios realmente tiveram suas credenciais confidenciais expostas ao público.

Abril de 2025: um backdoor em 21 extensões do Magento

Em abril, uma infecção foi descoberta em um amplo conjunto de extensões do Magento, uma das plataformas mais populares para a criação de lojas on-line. O backdoor foi incorporado em 21 módulos desenvolvidos por três fornecedores: Tigren, Meetanshi e MGS. As extensões faziam parte da infraestrutura de várias centenas de empresas de comércio eletrônico, incluindo pelo menos uma corporação multinacional.

De acordo com os pesquisadores que o descobriram, o backdoor na verdade foi implantado em 2019. Em abril de 2025, os invasores o acionaram para comprometer sites e fazer o upload de web shells. Isso foi feito por meio de uma função incorporada nas extensões que executava um código arbitrário extraído de um arquivo de licença.

Por ironia, os módulos infectados incluíam o MGS GDPR e o Meetanshi CookieNotice. Como os nomes sugerem, essas extensões foram projetadas para ajudar os sites a cumprir os regulamentos de privacidade e processamento de dados dos usuários. Por fim, em vez de garantir a privacidade, o uso deles provavelmente levou ao roubo de dados e ativos financeiros do usuário por meio de skimming digital.

Maio de 2025: ransomware distribuído por meio de um MSP comprometido

Em maio, os agentes de ransomware da gangue DragonForce obtiveram acesso à infraestrutura de um provedor de serviços gerenciados (MSP) não identificado e a usaram para distribuir um ransomware e roubar dados das organizações clientes do MSP.

Ao que tudo indica, os invasores exploraram várias vulnerabilidades (incluindo uma falha crítica) no SimpleHelp, a ferramenta de monitoramento e gerenciamento remoto usada pelo MSP. Essas vulnerabilidades foram descobertas em 2024 e divulgadas publicamente e corrigidas em janeiro de 2025. Infelizmente, ficou claro que o MSP optou por não acelerar o processo de atualização, um atraso que a gangue do ransomware ficou mais do que feliz em explorar.

Junho de 2025: um backdoor em mais de uma dúzia de pacotes npm populares

No início do verão, os invasores invadiram a conta de um dos mantenedores da biblioteca Glustack e usaram um token de acesso roubado para injetar backdoors em 17 pacotes npm. O mais popular desses pacotes, @react-native-aria/interactions, ostentava 125 mil downloads semanais, enquanto todos os pacotes comprometidos combinados totalizaram mais de um milhão.

O que é particularmente interessante nesse caso são as etapas que os desenvolvedores do Glustack seguiram após o incidente: primeiro, eles restringiram o acesso ao repositório GitHub para contribuidores secundários; segundo, eles ativaram a autenticação de dois fatores (2FA) para publicar novas versões; e terceiro, eles prometeram implementar práticas de desenvolvimento seguras, como fluxo de trabalho baseado em pull requests, revisões sistemáticas de código, registro de auditorias e assim por diante. Em outras palavras, antes do incidente, um projeto com centenas de milhares de downloads semanais não tinha tais medidas em vigor.

Julho de 2025: pacotes npm populares infectados por meio de um ataque de phishing

Em julho, os pacotes npm foram novamente as estrelas do show, incluindo o pacote amplamente usado chamado “is”, que possui 2,7 milhões de downloads semanais. Essa biblioteca de utilitários JavaScript fornece uma ampla variedade de funções de verificação de tipo e validação de valor. Para realizar um ataque de phishing contra um dos proprietários do projeto, os invasores utilizaram com êxito um truque antigo: o typosquatting (usar o domínio npnjs.com em vez de npmjs.com) e um clone do site oficial do npm.

Em seguida, eles usaram a conta comprometida para publicar várias das suas próprias versões do pacote com um backdoor incorporado. A infecção passou desapercebida por seis horas: tempo suficiente para um grande número de desenvolvedores baixarem os pacotes npm maliciosos.

A mesma tática de phishing foi usada contra outros desenvolvedores. Os invasores aproveitaram várias contas de desenvolvedores comprometidas para distribuir diferentes variantes de sua carga maliciosa. Há também uma forte suspeita de que eles podem ter guardado parte dessa carga para ataques futuros.

Agosto de 2025: o ataque s1ngularity e o vazamento de centenas de segredos dos desenvolvedores

No final de agosto, um incidente apelidado de “s1ngularity” continuou a tendência de atingir desenvolvedores de JavaScript. Os invasores comprometeram o Nx, um sistema de compilação popular e uma ferramenta de otimização de pipeline de CI/CD. O código malicioso injetado nos pacotes pesquisou diversos sistemas dos desenvolvedores infectados, acessando uma grande quantidade de dados confidenciais, como chaves de carteiras de criptomoedas, tokens do npm e do GitHub, chaves SSH, chaves de API e muito mais.

Curiosamente, os invasores usaram ferramentas de IA instaladas localmente, como Claude Code, Gemini CLI e Amazon Q, para detectar os segredos nas máquinas das vítimas. Tudo o que eles encontraram foi publicado nos repositórios públicos do GitHub criados em nome das vítimas, usando os títulos “s1ngularity-repository”, “s1ngularity-repository-0” e “s1ngularity-repository-1”. Como você deve ter adivinhado, é daí que vem o nome do ataque.

Consequentemente, os dados privados de centenas de desenvolvedores acabaram ficando à vista de todos e poderiam ser acessados não apenas pelos invasores, mas por absolutamente qualquer pessoa com uma conexão com a Internet.

Setembro de 2025: um stealer de criptomoedas ataca pacotes npm que têm 2,6 bilhões de downloads semanais

A tendência de comprometimentos de pacotes npm seguiu até setembro. Após uma nova campanha de phishing direcionada a desenvolvedores de JavaScript, os invasores conseguiram injetar código malicioso em algumas dezenas de projetos de alto nível. Alguns deles, especificamente “chalk” e “debug”, tiveram centenas de milhões de downloads semanais; coletivamente, os pacotes infectados estavam acumulando mais de 2,6 bilhões de downloads por semana no momento da violação, e eles se tornaram mais populares desde então.

A carga era um stealer de criptomoedas: um malware projetado para interceptar transações de criptomoeda e redirecioná-las para as carteiras dos invasores. Felizmente, apesar de infectar com sucesso alguns dos projetos mais populares do mundo, os invasores acabaram falhando no estágio final da operação. No final, eles ficaram com míseros USD 925.

Apenas uma semana depois, outro grande incidente ocorreu: a primeira onda do malware autopropagável Shai-Hulud, que infectou cerca de 150 pacotes npm, incluindo projetos da CrowdStrike. No entanto, a segunda onda, que ocorreu vários meses depois, provou ser muito mais destrutiva. Vamos analisar o Great Worm em mais detalhes a seguir.

Outubro de 2025: o GlassWorm infecta o ecossistema do Visual Studio Code

Cerca de um mês após o ataque do Shai-Hulud, um malware autopropagável semelhante denominado GlassWorm começou a infectar extensões do Visual Studio Code no Open VSX Registry e no Microsoft Extension Marketplace. Os invasores estavam procurando contas do GitHub, Git, npm e Open VSX, bem como chaves de carteiras de criptomoedas.

Os criadores do GlassWorm adotaram uma abordagem altamente criativa para sua infraestrutura de comando e controle: eles usaram uma carteira de criptomoedas no blockchain Solana como seu C2 principal, com o Google Agenda servindo como um canal de comunicação de backup.

Além de esvaziar as carteiras de criptomoedas das vítimas e sequestrar suas contas para espalhar o worm ainda mais, os invasores também injetaram um RAT chamado Zombi nos dispositivos infectados, obtendo controle total sobre os sistemas comprometidos.

Novembro de 2025: a campanha IndonesianFoods e 150 mil pacotes de spam no npm

Em novembro, um novo incômodo emergiu do repositório do npm. Uma campanha maliciosa coordenada apelidada de IndonesianFoods fez os invasores inundarem o repositório com dezenas de milhares de pacotes inúteis.

O objetivo principal era jogar com o sistema para inflar as métricas e os tokens de farm no tea.xyz, uma plataforma de blockchain projetada para recompensar os desenvolvedores de código aberto. Para conseguir isso, os invasores construíram uma enorme rede de projetos interdependentes com nomes que fazem referência à culinária indonésia, como zul-tapai9-kyuki e andi-rendang23-breki.

Os criadores da campanha não se deram ao trabalho de invadir contas. Estritamente falando, os pacotes de spam nem sequer continham um contêiner malicioso, a menos que você considere um script projetado para gerar automaticamente novos contêineres a cada sete segundos. No entanto, o incidente serviu como um lembrete de como a infraestrutura npm é vulnerável a campanhas de spam em larga escala.

Dezembro de 2025: Shai-Hulud 2.0 e o vazamento de 400 mil segredos de desenvolvedores

O destaque absoluto do ano, não apenas de ataques a cadeias de suprimentos, mas provavelmente para todo o campo de segurança cibernética, foi o malware autopropagável Shai-Hulud (também conhecido como Sha1-Hulud) contra desenvolvedores.

Esse malware foi a evolução lógica do ataque s1ngularity mencionado anteriormente: ele também vasculhou os sistemas em busca de todos os tipos de segredos e os publicou em repositórios GitHub abertos. No entanto, o Shai-Hulud adicionou um mecanismo de autopropagação à linha de base: o worm infectou projetos controlados por desenvolvedores já comprometidos usando as credenciais roubadas.

A primeira onda do Shai-Hulud ocorreu em setembro, infectando várias centenas de pacotes npm. No final do ano, a segunda onda chegou e foi batizada como Shai-Hulud 2.0.

Dessa vez, o worm foi atualizado com a funcionalidade de wiper. Se o malware não encontrasse tokens npm ou GitHub válidos em um sistema infectado, ele acionava uma carga destrutiva que apagava os arquivos do usuários.

Aproximadamente 400 mil segredos foram vazados no total como resultado do ataque. Vale a pena notar que, assim como no s1ngularity, todos os dados confidenciais acabaram publicados em repositórios públicos, onde poderiam ser baixados não apenas pelos invasores, mas por qualquer outra pessoa. E é altamente provável que as consequências desse ataque ainda sejam sentidas por um longo tempo.

Um dos primeiros casos confirmados de uma exploração usando segredos vazados pelo Shai-Hulud foi um roubo de criptomoeda visando vários milhares de usuários da Trust Wallet. Os invasores usaram esses segredos na véspera de Natal para carregar uma versão maliciosa da extensão Trust Wallet com um drenador de criptomoedas integrado para a Chrome Web Store. No final, eles conseguiram se safar com USD 8,5 milhões em criptomoedas.

Como se proteger contra ataques a cadeias de suprimentos

Ao elaborar uma retrospectiva semelhante para 2024, descobrimos que manter uma estrutura de “um mês, uma ameaça” é bastante fácil. Para 2025, no entanto, o caso foi muito mais grave. Houve tantos ataques maciços a cadeias de suprimentos no ano passado, que não conseguimos encaixá-los em uma visão geral.

O ano de 2026 está se mostrando igualmente intenso, por isso recomendamos verificar nossa postagem sobre a prevenção de ataques a cadeias de suprimentos. Enquanto isso, aqui estão as conclusões mais importantes:

• Avalie minuciosamente seus fornecedores e faça uma auditoria cuidadosa do código que você integra em seus projetos.
• Implemente requisitos de segurança rígidos diretamente em seus contratos de serviço.
• Desenvolva um plano abrangente de resposta a incidentes.
• Monitore atividades suspeitas em sua infraestrutura corporativa usando uma solução de XDR.
• Se a sua equipe de segurança interna estiver sobrecarregada, procure um serviço externo de identificação proativa de ameaças e resposta rápida.

Se quiser saber mais detalhes sobre os ataques a cadeias de suprimentos, confira o nosso relatório analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência). Ele se baseia em insights de especialistas técnicos e revela com que frequência as organizações enfrentam riscos relacionados à cadeia de suprimentos e a relações de confiança, onde ainda existem lacunas de proteção e quais estratégias adotar para aumentar a resiliência contra esse tipo de ameaça.

Milhões de pipelines de desenvolvimento de software automatizados dependem de ferramentas de segurança, como Trivy e Checkmarx AST, integradas ao processo de compilação. E foram essas soluções confiáveis que recentemente se tornaram o ponto de entrada para um dos maiores e mais perigosos ataques contra a cadeia de suprimentos da história moderna. Nesta postagem, discutiremos como auditar os fluxos de trabalho automatizados e como proteger a infraestrutura de nuvem corporativa.

Linha do tempo do ataque e as consequências conhecidas

Em 19 de março, um ataque direcionado e bem-sucedido contra a cadeia de suprimentos foi realizado por meio do Trivy, uma ferramenta de verificação de vulnerabilidades de código aberto amplamente usada em pipelines de CI/CD. Os invasores, um grupo conhecido como TeamPCP, conseguiram injetar malware nos fluxos de trabalho oficiais do GitHub Actions e nas imagens do Docker associadas ao Trivy. Com isso, cada verificação automatizada de pipeline feita acionou um malware que roubou chaves SSH, tokens de acesso à nuvem, carteiras de criptomoedas e outros dados valiosos dos sistemas comprometidos. Dada a natureza crítica do incidente, o identificador CVE-2026-33634 foi atribuído a ele, com uma pontuação CVSS4B, praticamente máxima, de 9,4.

Mais tarde, naquele mesmo dia, a equipe do Trivy detectou o ataque, removeu os artefatos maliciosos dos canais de distribuição e interrompeu aquela fase do ataque. No entanto, os invasores já tinham conseguido acessar os ambientes de muitos usuários do Trivy.

Em 23 de março, um incidente semelhante foi descoberto em outra ferramenta de segurança do aplicativo: um GitHub Action para Checkmarx KICS, e também, para Checkmarx AST. Três horas depois, o código malicioso foi então removido do ambiente. O TeamPCP também conseguiu comprometer as extensões do OpenVSX compatíveis com Checkmarx: cx-dev-assist 1.7.0 e ast-results. Os relatórios que indicam quando ocorreu o momento da resolução dessa parte do incidente variam.

Em 24 de março, um projeto popular que usa a verificação de código do Trivy (o gateway LiteLLM AI, que nada mais é do que uma biblioteca universal para acesso a vários provedores de LLM) foi atacado. As versões 1.82.7 e 1.82.8, carregadas no repositório PyPI, foram comprometidas. Essas versões ficaram disponíveis publicamente por cerca de cinco horas.

Mas o fato do ataque ter durado apenas algumas horas não é motivo para desconsiderar o evento. Dada a popularidade dos projetos afetados, o código malicioso pode ter sido executado milhares de vezes, inclusive dentro da infraestrutura de empresas muito grandes.

Isso permitiu que os invasores não só implementassem backdoors persistentes em clusters do Kubernetes, mas também iniciassem o CanisterWorm autorreplicante no ecossistema npm do JavaScript.

O código dos invasores tem recursos destrutivos que eliminam um cluster Kubernetes, e todos os seus nós, se o fuso horário de Teerã ou o farsi for detectado como idioma principal no sistema comprometido. Em outras regiões, o malware simplesmente rouba dados com o uso do CanisterWorm.

De acordo com especialistas, mais de 20 mil repositórios são considerados suscetíveis a ataques. Os invasores alegam ter roubado centenas de gigabytes de dados e mais de 500 mil contas.

Como o Trivy foi atacado

Para comprometer o Trivy, os invasores usaram as credenciais roubadas em um incidente anterior. O comprometimento anterior do Trivy, ocorrido no final de fevereiro, provavelmente não foi contido de forma plena, e os invasores, ou seja, o mesmo grupo TeamPCP, retornaram com um novo ataque. A Aqua Security, por meio de sua equipe de desenvolvedores do Trivy, especula que, como as credenciais estavam sendo eliminadas gradualmente após o incidente anterior, os invasores conseguiram gerar novos tokens de acesso para si mesmos antes que os antigos comprometidos fossem revogados.

Com isso, os invasores do grupo TeamPCP conseguiram comprometer o GitHub Actions usado em pipelines de CI/CD. Com o uso de credenciais com privilégios de gravação de tags, os invasores forçaram a substituição de 76 das 77 tags de versão no aquasecurity/trivy-action, além de todas as 7 tags no aquasecurity/setup-trivy, e redirecionaram as versões confiáveis existentes para as versões maliciosas. Essa tática de ataque se assemelha com as táticas observadas na campanha Shai-Hulud 2.0. Com isso, os fluxos de trabalho em todo o pipeline começaram a executar o código dos invasores, porém, os metadados da versão não mostravam as alterações visíveis.

Paralelamente a isso, os invasores publicaram um binário Trivy infectado (v0.69.4) nos canais de distribuição oficiais, inclusive com versões do GitHub e registros de contêiner.

Comprometimento da ferramenta LiteLLM

O comprometimento da popular ferramenta de acesso ao modelo de linguagem LiteLLM pode desencadear, por si só, uma grande onda de ataques em toda a cadeia de projetos que utiliza o recurso. O ataque ocorreu em 24 de março de 2026, quando os invasores do TeamPCP publicaram diretamente as versões maliciosas da biblioteca (1.82.7 e 1.82.8) no PyPI. Entre 10:39 UTC e 16:00 UTC, esses pacotes comprometidos continham malware que roubava credenciais. Ele foi integrado no arquivo proxy_server.py, e a versão 1.82.8 também continha um arquivo litellm_init malicioso. Os dados roubados foram exfiltrados para o servidor models.litellm[.]cloud.

Os clientes que usam o LiteLLM Cloud ou a imagem oficial do LiteLLM Proxy Docker não foram afetados devido ao bloqueio estrito da versão, enquanto os desenvolvedores e os projetos de downstream que instalaram as versões não fixadas pelo pip, durante a janela de tempo especificada, foram comprometidos.

Em três horas, os pacotes maliciosos foram removidos do repositório PyPI, e a equipe do LiteLLM suspendeu as novas versões, atualizou as credenciais e envolveu um processo externo de resposta a incidentes. As equipes que usam o LiteLLM em seus projetos são aconselhadas a verificar imediatamente o indicador de comprometimento litellm_init.pth e atualizar rotineiramente todos os segredos que possam estar comprometidos.

Recursos do malware TeamPCP Cloud Stealer

Os invasores adicionaram uma nova lógica ao GitHub Actions, ao executável do Trivy e preservaram a funcionalidade original. Os resultados da verificação de vulnerabilidades por meio do Trivy pareciam normais, mas, ao mesmo tempo, dados valiosos estavam sendo pesquisados e extraídos. O código malicioso atuava da seguinte maneira:

• realizando reconhecimento (coletando dados de rede e variáveis de ambiente);
• procurando tokens e credenciais para acessar ambientes de nuvem AWS e GCP;
• verificando a memória (/proc/*/mem ) para extrair segredos armazenados na memória dos processos Runner.Worker e Runner.Listener;
• extraindo segredos do Kubernetes (/run/secrets/kubernetes.io/serviceaccount);
• coletando dados para conexão com servidores de banco de dados (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• coletando quaisquer outras chaves e segredos de API de arquivos de ambiente e arquivos de configuração de CI/CD (.env, .json, .yml);
• pesquisando webhooks para canais Slack e Discord;
• procurando dados relativos às carteiras de criptomoedas (variáveis relativas ao blockchain Solana, além de dados rpcuser e rpcpassword).

Os dados coletados foram criptografados e carregados em um servidor com um nome semelhante ao dos desenvolvedores do Trivy (scan.aquasecurtiy[.]org). Como se fosse um mecanismo de backup, os invasores forneceram um método para carregar os dados em um repositório denominado docs-tpcp.

O ataque ao CheckMarx e ao LiteLLM usou uma tática semelhante aos outros domínios de typosquatting: models.litellm[.]cloud e checkmarx[.]zone.

Uma análise técnica detalhada do malware, juntamente com indicadores de comprometimento, pode ser encontrada no artigo de nosso especialista no blog Securelist.

Estratégias de resposta e defesa ao CVE-2026-33634

As verificações baseadas em assinatura e as verificações de dependência existentes em registros públicos não são mais suficientes, pois o código malicioso foi injetado diretamente em ações confiáveis e assinadas, o que fez com que a detecção fosse burlada até que o monitoramento comportamental fosse aplicado. Os pipelines de CI/CD se tornaram o “novo perímetro” de segurança.

Ações imediatas. Verifique e confirme se todos os fluxos de trabalho usam versões seguras (Trivy binary 0.69.3, trivy-action 0.35.0 e setup-trivy 0.2.6).

Os administradores de pipeline de CI/CD e as equipes de segurança devem revisar imediatamente as dependências das soluções Checkmarx (kics-github-action e ast-github-action) e Trivy (setup-trivy e trivy-action). Se os fluxos de trabalho fizerem referência a uma tag de versão em vez de um hash SHA específico, revise cuidadosamente os logs de execução do fluxo de trabalho durante o ataque ativo contra a cadeia de suprimentos.

Também é necessário verificar os logs de rede quanto ao tráfego para os domínios scan.aquasecurtiy[.]org, checkmarx[.]zone e models.litellm[.]cloud. A presença desse tráfego indica que os dados confidenciais foram exfiltrados com êxito.

Se um repositório denominado docs-tpcp tiver aparecido no GitHub da organização, isso também poderá indicar uma violação bem-sucedida de dados.

Verifique os hosts e clusters quanto aos sinais de comprometimento, ou seja, a presença de arquivos ~/.config/sysmon/sysmon.py, isto é, pods suspeitos no Kubernetes.

Limpe o cache e realize um inventário dos módulos PyPI: verifique se há módulos maliciosos e reverta para versões limpas.

Em qualquer caso, uma identificação proativa de ameaças deve ser realizada, tendo em vista que os sistemas tenham sido comprometidos com êxito e que os invasores avançaram rapidamente dentro dos sistemas afetados.

É recomendável restaurar os ambientes afetados por meio de backups verificados.

Fixação de dependências e gerenciamento de segredos. Verifique e confirme se as versões de dependência exatas estão fixadas com o uso de hashes criptográficos em todos os pipelines e Dockerfiles. Aconselhamos fazer a transição de tokens de longa duração para credenciais de curta duração com o uso de uma ferramenta de gerenciamento de segredos e fazer a implementação de integrações OIDC onde houver compatibilidade. Minimize a injeção de segredos no ambiente de tempo de execução, faça isso apenas quando for absolutamente necessário. Verifique e confirme se os segredos não estão armazenados em disco ou em arquivos temporários, e se eles não estão sendo reutilizados em processos diferentes.

Atualize todas as credenciais que possam estar comprometidas, ou seja, chaves de API, variáveis de ambiente, chaves SSH, tokens de conta de serviço do Kubernetes e outros segredos.

Outras medidas de segurança. Permita apenas o uso do GitHub Actions originado por uma lista aprovada pela organização e bloqueie os processos novos e não verificados. Configure o GITHUB_TOKEN e outras chaves de acesso de acordo com o princípio do privilégio mínimo. Não conceda permissões de gravação, a menos que seja absolutamente necessário.

Para aumentar a segurança do GitHub Actions, há várias ferramentas de código aberto disponíveis:

• zizmor: uma ferramenta para análise estática e detecção de erros de configuração no GitHub Actions;
• gato e Gato-X: duas versões de uma ferramenta que ajuda a identificar pipelines estruturalmente vulneráveis;
• allstar: um aplicativo do GitHub, desenvolvido pelo OpenSSF, para configurar e aplicar políticas de segurança em organizações e repositórios do GitHub.

Se quiser saber mais detalhes sobre os ataques contra a cadeia de suprimentos, deixamos aqui o nosso convite para consultar o relatório analítico Reação da cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência. Ele é baseado em insights de especialistas técnicos e revela com que frequência as organizações enfrentam os riscos para a cadeia de suprimentos e de relacionamento confiável, onde permanecem as lacunas de proteção e quais são as estratégias que devem ser empregadas para melhorar a resiliência contra esses tipos de ameaças.