Prezado leitor,

Esta semana foi estranha. Nos últimos meses, vimos uma série de ataques à Supply chain significativos. A comunidade tem soado o alarme há algum tempo, e a verdade é que estamos pisando em ovos. Parece inevitável que algo maior, algo pior, esteja por vir.

Nesta publicação, quero compartilhar algumas das principais lições desta semana. Tive a oportunidade de conversar com Josh Junon, mais conhecido como Qix, e entrevistá-lo sobre sua experiência no meio desta provação. Josh é o mantenedor que foi comprometido no ataque de phishing, e ele também está por trás de alguns dos pacotes mais amplamente utilizados no ecossistema npm.

Antes de mergulhar nessa conversa (Veja a entrevista abaixo), vamos dar uma rápida olhada nos eventos que nos trouxeram até aqui.

Prólogo - Impacto

Na segunda-feira, quando vi pela primeira vez os alertas em nosso painel interno Aikido Intel, ficou imediatamente claro que este poderia ser um daqueles cenários de pior caso que me tiram o sono. Grandes pacotes como debug, chalk e outros dezesseis foram comprometidos com malware. O potencial impacto foi nada menos que catastrófico.

Os números falam por si:

• Coletivamente, os pacotes comprometidos são baixados cerca de 2,6 bilhões de vezes por semana.
• A JFrog estima que as versões maliciosas sozinhas foram baixadas aproximadamente 2,6 milhões de vezes.
• A Wiz relatou que 99% de seus ambientes Cloud dependem de pelo menos um desses pacotes, e em 10% dos casos, o código malicioso estava presente.

Por qualquer medida, foi por pouco. Como muitos notaram desde então, escapamos por um triz. A única razão pela qual o dano não foi muito pior se resume a dois fatores:

• Os atacantes estavam focados em roubar criptomoedas.
• Eles se esforçaram muito para permanecerem indetectáveis.

Mas a história nos lembra o quão frágil essa sorte pode ser. Basta olharmos para 26 de agosto de 2025 para ver o que acontece quando um atacante é menos cuidadoso em sua execução.

Prólogo - Comprometimento do Nx

Em 26 de agosto, o gerenciador de pacotes Nx foi comprometido, mas os atacantes escolheram uma abordagem muito diferente:

• Eles exfiltraram Secrets e tokens de máquinas de desenvolvedores e os despejaram publicamente no GitHub.
• Eles então usaram esses tokens para invadir contas do GitHub, tornando repositórios privados públicos.

Foi um clássico ataque rápido. Um lembrete contundente de que comprometer um pacote amplamente utilizado não causa apenas inconveniência. Pode causar danos reais e duradouros. De muitas maneiras, foi um tiro de advertência, mostrando o quão expostos estamos.

A conversa com Josh

Depois de entrar em contato com Josh para alertá-lo sobre o comprometimento e continuar nossas conversas, meu colega Mackenzie e eu percebemos que seria fascinante sentar com ele e ouvir em primeira mão como foi essa experiência. Felizmente, Josh estava aberto a isso. 

O que se seguiu foi uma conversa ponderada e franca que me deixou uma impressão real. Gostaria de compartilhar algumas das minhas maiores lições com você aqui. Se você quiser o contexto completo, pode assistir à discussão completa de 45 minutos aqui:

Insight: Confiança Através da Vulnerabilidade

A segurança geralmente visa eliminar vulnerabilidades. Mas, no open source, a confiança só é possível por causa da vulnerabilidade. Mantenedores disponibilizam seu código, e uma parte de si mesmos, para o mundo, expondo-o a bilhões de downloads e inúmeros usuários. Essa exposição exige um salto de fé.

Quando Josh falou abertamente sobre como foi vítima de phishing, ele demonstrou o tipo de vulnerabilidade que realmente fortalece a confiança. Ao admitir erros, ser transparente e manter-se engajado com a comunidade, ele nos lembrou que o open source não é gerido por corporações sem rosto, mas por pessoas. E a confiança nessas pessoas é o que faz todo o sistema funcionar.

No fim, o paradoxo é que a segurança busca remover a vulnerabilidade, mas a confiança no open source é construída sobre ela.

Acho que o que fez uma enorme diferença foi o tipo de resposta geral. Sei que foi apontado várias vezes que a vulnerabilidade foi apreciada. E acho que eu já sabia disso. Tive alguns casos em open source onde eu mesmo cometi erros, não em termos de segurança, mas apenas sendo transparente e honesto – e isso imediatamente poupou muitas dores de cabeça, tempo e dinheiro para muitas pessoas. E isso é sempre apreciado.

Insight: Adentrando o Open Source

Josh nunca teve a intenção de se tornar um pilar do ecossistema JavaScript. Ele começou a programar na adolescência, experimentando com PHP, C# e JavaScript, e o open source era apenas um lugar para compartilhar projetos que o interessavam. Ele se sentia atraído por coisas como adicionar cores a terminais ou construir pequenos utilitários, nunca imaginando que eles acabariam no cerne do software moderno.

Com o tempo, suas contribuições levaram a maiores responsabilidades. Para algumas bibliotecas, como chalk, ele foi convidado a se juntar como mantenedor após contribuir com correções. Para outras, como debug, ele herdou a gestão de mantenedores anteriores. O que começou como um passatempo divertido gradualmente se tornou a manutenção de alguns dos pacotes mais amplamente utilizados no ecossistema.

Anos depois, Josh se viu responsável por bilhões de downloads semanais. O que antes eram pequenos projetos paralelos havia se tornado infraestrutura crítica da internet. Não por meio de planejamento cuidadoso ou ambição, mas simplesmente por estar no lugar certo na hora certa e dizer “sim” quando solicitado a ajudar.

Eles começaram a ser usados em cada vez mais lugares, provavelmente até em alguns onde nunca deveriam ter sido. Honestamente, alguns desses pacotes nem deveriam existir, e serei o primeiro a admitir isso. Então, um dia você acorda e percebe que um pequeno utilitário que você escreveu para mover valores de array é usado por 55.000 pessoas e baixado 300 milhões de vezes por semana. Você nunca pediu por essa responsabilidade.

Insight: A Impotência de Perder o Controle

Talvez a parte mais difícil do incidente para Josh não tenha sido perceber que ele havia sido vítima de phishing. Foi a impotência que se seguiu. Uma vez que os atacantes tinham sua senha e o código 2FA, eles eram essencialmente ele aos olhos do npm. Eles redefiniram seus tokens 2FA, alteraram os detalhes de autenticação e o bloquearam de sua própria conta. Mesmo ações básicas como redefinir sua senha ou recuperar o acesso não funcionaram.

Por quase 12 horas, tudo o que Josh pôde fazer foi observar de fora enquanto versões maliciosas de seus pacotes se espalhavam pela internet. Ele não tinha como intervir diretamente, nenhum botão para apertar, nenhum canal rápido para o suporte do npm. Em vez disso, ele foi forçado a depender de fóruns públicos de ajuda e esperar. 

A sensação de impotência foi o que o marcou. Como ele descreveu, não havia transparência, nem ferramentas para um mantenedor em crise retomar o controle. No meio de um dos maiores comprometimentos de supply chain da memória recente, a pessoa mais confiável com esses pacotes foi deixada de lado.

O botão de redefinição de senha não funcionou. Não recebi nenhum e-mail durante todo o processo. A redefinição de senha não fez nada. Então, mesmo que o e-mail ainda fosse o mesmo na conta, o que eu ainda meio que acredito que era, a redefinição de senha não estava funcionando… Não havia outro recurso além de contatar o npm através do formulário de ajuda público não autenticado.

Insight: Uma Bala Desviada

O malware plantado em chalk, debug e nos outros pacotes comprometidos era sério, mas seu escopo era estranhamente limitado. Ele tentava roubar criptomoedas injetando-se em contextos de navegador. Essa decisão dos atacantes, seja por ganância ou miopia, é a única razão pela qual as consequências não foram muito piores.

Como Josh colocou, isso poderia facilmente ter sido catastrófico. Esses pacotes rodam em todos os lugares: laptops, servidores corporativos, pipelines de CI/CD e ambientes Cloud. Eles poderiam estar exfiltrando chaves AWS, vazando Secrets ou criptografando arquivos para resgate. Em vez disso, os atacantes se limitaram a um objetivo restrito.

Poderia ter feito qualquer coisa e estava sendo executado… em máquinas corporativas, máquinas pessoais, pequenas empresas, pipelines de CI/CD. E o fato de não ter feito nada [pior] foi a bala que desviamos.

A lição não é que o sistema funcionou. É que a sorte estava do nosso lado desta vez. Tratar isso como um “nada demais” perde o sentido. O próximo atacante pode não ser tão contido.

Insight: O Custo Humano do Código Aberto

Por trás de cada pacote amplamente utilizado há um ser humano, muitas vezes trabalhando silenciosamente e sem alarde. Para Josh, a parte mais desafiadora não foi apenas o comprometimento técnico. Foi o impacto emocional que se seguiu. Ele descreveu o primeiro dia como puro piloto automático, correndo para conter os danos. Só depois o peso o atingiu: vergonha, ansiedade e o pensamento inquietante de que seu erro poderia ter prejudicado pessoas.

Isso foi na segunda-feira. Assim que recuperei minha conta naquela tarde ou noite, foi como, ok, posso desligar o interruptor e agora posso apenas deitar na cama e olhar para o teto e pensar no que acabou de acontecer… O dia seguinte foi só vergonha. Eu não queria mostrar meu rosto. Eu não queria sair.

Esta é a realidade oculta do código aberto. Pequenos projetos criados “por diversão” tornam-se infraestrutura crítica, movimentando bilhões de downloads. Os mantenedores nunca pediram essa responsabilidade, mas suportam o estresse quando as coisas dão errado. A comunidade vê o código, mas muitas vezes ignora o custo humano de mantê-lo.

A experiência de Josh é um lembrete de que a segurança do ecossistema não se trata apenas de MFA mais forte ou resposta a incidentes mais rápida. É também sobre apoiar os mantenedores que assumem essa responsabilidade — respeitando limites, mostrando empatia e reconhecendo que a confiança depende das pessoas por trás do código.

Chamada para Ação

Este incidente destacou como um único comprometimento pode se propagar pela cadeia de suprimentos de software. Não foi catastrófico desta vez, mas poderia ter sido facilmente. A lição não é entrar em pânico, mas agir.

• Para registros (npm, PyPI, etc.): Implementar MFA resistente a phishing para mantenedores de alto impacto e fornecer canais claros de resposta rápida quando as contas são comprometidas.
• Para organizações: Melhorar a higiene de dependências. Fixar versões, monitorar adulterações e integrar verificações de segurança da cadeia de suprimentos em pipelines de CI/CD.
  Para mantenedores: Usar chaves de hardware, evitar decisões rápidas de segurança tomadas sob estresse e apostar na transparência se algo der errado.
• Para a comunidade: Apoiar os humanos por trás do código aberto. Respeitar seus limites, fornecer recursos sempre que possível e responder com empatia quando erros acontecem.

O verdadeiro apelo à ação é simples: tratar a segurança do ecossistema como responsabilidade compartilhada. Plataformas, empresas e comunidades têm um papel a desempenhar para garantir que o próximo incidente não se transforme em algo pior.

Epílogo

Foi uma semana surreal, estando no olho de uma tempestade que atraiu tanta imprensa e atenção, e por uma boa razão. Observar os eventos se desenrolarem em tempo real, desde os primeiros alertas em nosso dashboard até a enxurrada de relatórios públicos, parecia estar em uma falha geológica enquanto o chão se movia sob nós. Isso é um lembrete de quão frágil é o nosso ecossistema.

O que se desenrolou chegou perigosamente perto do tipo de pior cenário com o qual passo meus dias me preocupando na segurança de código aberto. Mas o que mais temo não é o e-mail de phishing, o malware, ou mesmo as manchetes. É que deixemos este momento passar sem mudanças.

Se a indústria encolher os ombros, tratar isso como apenas mais um incidente e voltar ao normal, não teremos aprendido nada. E da próxima vez, porque haverá uma próxima vez, talvez não tenhamos tanta sorte. Da primeira vez, a culpa é dos atacantes. Da segunda vez, a culpa é nossa.

E se não tomarmos medidas para aprender com isso, a erosão silenciosa da confiança no código aberto pode acabar sendo a consequência mais prejudicial de todas.

‍