Caro leitor,

Esta semana foi estranha. Nos últimos meses, assistimos a uma série de ataques à Supply chain significativos ataques à Supply chain. A comunidade vem a alertar há algum tempo, e a verdade é que temos andado a pisar em terreno instável. Parece inevitável que algo maior, algo pior, esteja a caminho.

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

Antes de mergulharmos 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 no nosso painel interno Aikido , ficou imediatamente claro que este poderia ser um daqueles piores cenários que me mantêm acordado à noite. Pacotes importantes como debug, chalk e outros dezasseis tinham sido comprometidos com malware. As consequências potenciais eram nada menos que catastróficas.

Os números falam por si:

• Coletivamente, os pacotes comprometidos são descarregados cerca de 2,6 mil milhões de vezes por semana.
• A JFrog estima que só as versões maliciosas foram descarregadas cerca de 2,6 milhões de vezes.
• Wiz que 99% dos seus ambientes de nuvem 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 observaram desde então, escapámos por pouco. A única razão pela qual os danos não foram muito piores resume-se a dois fatores:

• Os atacantes estavam totalmente focados em roubar criptomoedas.
• Eles fizeram de tudo para não serem descobertos.

Mas a história nos lembra como essa sorte pode ser frágil. Basta olharmos para trás , para 26 de agosto de 2025, para ver o que acontece quando um invasor é menos cuidadoso na sua execução.

Prólogo - Compromisso Nx

Em 26 de agosto, o gerenciador de pacotes Nx foi comprometido, mas os invasores escolheram uma estratégia muito diferente:

• Eles extraíram secrets tokens das máquinas dos programadores e os divulgaram publicamente no GitHub.
• Em seguida, eles usaram esses tokens para invadir contas do GitHub, tornando repositórios privados públicos.

Foi um clássico assalto relâmpago. Um lembrete contundente de que comprometer um pacote amplamente utilizado não causa apenas inconvenientes. Pode causar danos reais e duradouros. De muitas maneiras, foi um tiro de advertência, mostrando o quanto estamos expostos.

A conversa com Josh

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

O que se seguiu foi uma conversa ponderada e sincera que me deixou uma impressão muito positiva. Gostaria de partilhar aqui algumas das minhas principais conclusões. Se quiser ver o contexto completo, pode assistir à discussão de 45 minutos na íntegra aqui:

Perspectiva: Confiança através da vulnerabilidade

A segurança geralmente consiste em eliminar vulnerabilidades. Mas, no código aberto, a confiança só é possível devido à vulnerabilidade. Os mantenedores colocam o seu código, e uma parte de si mesmos, à disposição do mundo, expondo-o a bilhões de downloads e inúmeros utilizadores. Essa exposição requer um ato de fé.

Quando Josh falou abertamente sobre como foi vítima de phishing, ele mostrou o tipo de vulnerabilidade que, na verdade, fortalece a confiança. Ao admitir os erros, ser transparente e manter-se envolvido com a comunidade, ele lembrou-nos que o código aberto 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 final das contas, o paradoxo é que a segurança procura eliminar a vulnerabilidade, mas a confiança no código aberto é construída sobre ela.

Acho que o que fez uma grande diferença foi o tipo de resposta geral. Sei que foi apontado várias vezes que a vulnerabilidade foi apreciada. E acho que já sabia disso de antemão. Tive alguns casos em código aberto em que cometi erros, não em termos de segurança, mas apenas por ser transparente e honesto — e imediatamente poupei muitas pessoas de dores de cabeça, tempo e dinheiro. E isso é sempre apreciado.

Perspectiva: Entrando no mundo do código aberto

Josh nunca teve a intenção de se tornar um pilar do ecossistema JavaScript. Ele começou a programar ainda adolescente, experimentando PHP, C# e JavaScript, e o código aberto era apenas um lugar para partilhar projetos que lhe interessavam. Ele se sentia atraído por coisas como adicionar cores a terminais ou criar pequenos utilitários, sem imaginar que eles acabariam se tornando o núcleo do software moderno.

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

Anos mais tarde, Josh viu-se responsável por milhares de milhões de downloads semanais. O que antes eram pequenos projetos paralelos tornou-se uma infraestrutura crítica da Internet. Não por meio de um planeamento cuidadoso ou ambição, mas simplesmente por estar no lugar certo, na hora certa, e dizer «sim» quando lhe pediram ajuda.

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

Perspectiva: A impotência de perder o controlo

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 sensação de impotência que se seguiu. Assim que os invasores obtiveram a sua palavra-passe e o código 2FA, eles passaram a ser ele aos olhos do npm. Eles redefiniram os seus tokens 2FA, alteraram os detalhes de autenticação e bloquearam o acesso à sua própria conta. Mesmo ações básicas, como redefinir a sua palavra-passe ou recuperar o acesso, não funcionaram.

Durante quase 12 horas, tudo o que Josh podia fazer era assistir de fora enquanto versões maliciosas dos 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 confiar nos fóruns públicos de ajuda e esperar. 

A sensação de impotência foi o que ficou gravado nele. Como ele mesmo disse, não havia transparência, nem ferramentas para um mantenedor em crise retomar o controlo. No meio de uma das maiores violações da cadeia de abastecimento da história recente, a pessoa mais confiável para lidar com esses pacotes foi deixada de lado.

O botão para redefinir a palavra-passe não funcionou. Não recebi nenhum e-mail durante todo esse processo. A redefinição da palavra-passe não surtiu efeito. Portanto, mesmo que o e-mail ainda fosse o mesmo na conta, o que eu ainda acredito que era, a redefinição da palavra-passe não estava a funcionar... Não havia outra solução a não ser entrar em contacto com o npm através do formulário de ajuda público não autenticado.

Perspectiva: Uma bala evitada

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

Como Josh disse, isso poderia facilmente ter sido catastrófico. Esses pacotes são executados em todos os lugares: computadores portáteis, servidores empresariais, pipelines de CI/CD e ambientes de nuvem. Eles poderiam ter exfiltrado chaves da AWS, vazado secrets ou criptografado ficheiros para resgate. Em vez disso, os atacantes limitaram-se a um objetivo específico.

Poderia ter feito qualquer coisa e estava a ser executado... em máquinas empresariais, máquinas pessoais, pequenas empresas, pipelines de CI/CD. E o facto de não ter feito nada [pior] foi a bala que conseguimos desviar.

A lição não é que o sistema funcionou. É que a sorte esteve do nosso lado desta vez. Tratar isso como algo sem importância é perder o foco. O próximo invasor pode não ser tão moderado.

Perspectiva: O custo humano do código aberto

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

Isso foi na segunda-feira. Quando recuperei a minha conta naquela tarde ou noite, pensei: «Ok, posso desligar o interruptor e agora posso simplesmente deitar na cama, olhar para o teto e pensar no que acabou de acontecer...» No dia seguinte, foi só vergonha. Não queria mostrar a cara. Não queria sair de casa.

Essa é a realidade oculta do código aberto. Pequenos projetos criados «por diversão» tornam-se infraestruturas críticas, com bilhões de downloads. Os mantenedores nunca pediram essa responsabilidade, mas são eles que suportam o stress quando algo dá 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 resume apenas a uma autenticação multifator mais forte ou a uma resposta mais rápida a incidentes. Trata-se também de apoiar os mantenedores que assumem essa responsabilidade — respeitando limites, demonstrando empatia e reconhecendo que a confiança depende das pessoas por trás do código.

Chamada à ação

Este incidente destacou como um único comprometimento pode causar um efeito cascata na cadeia de fornecimento de software. Desta vez, não foi catastrófico, mas poderia facilmente ter sido. A lição não é entrar em pânico, mas agir.

• Para registos (npm, PyPI, etc.): Imponha MFA resistente a phishing para mantenedores de alto impacto e forneça canais de resposta rápida e clara quando as contas forem comprometidas.
• Para organizações: Melhore a higiene das dependências. Fixe versões, monitore contra adulterações e integre verificações de segurança da cadeia de suprimentos em pipelines de CI/CD.
  Para mantenedores: Use chaves de hardware, evite decisões rápidas de segurança tomadas sob pressão e conte com a transparência se algo der errado.
• Para a comunidade: Apoie as pessoas por trás do código aberto. Respeite os limites delas, forneça recursos sempre que possível e responda com empatia quando ocorrerem erros.

O verdadeiro apelo à ação é simples: tratar a segurança do ecossistema como uma responsabilidade partilhada. 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, estar no olho do furacão que atraiu tanta imprensa e atenção, e por um bom motivo. Assistir aos acontecimentos em tempo real, desde os primeiros alertas no nosso painel até a enxurrada de relatórios públicos, foi como estar numa falha geológica enquanto o chão se movia sob os nossos pés. Isso é um lembrete de como o nosso ecossistema é frágil.

O que aconteceu aproximou-se desconfortavelmente do pior cenário possível, aquele com o qual passo os meus dias preocupado em relação à segurança do código aberto. Mas o que mais temo não é o e-mail de phishing, o malware ou mesmo as manchetes. É deixarmos este momento passar sem mudanças.

Se a indústria ignorar, tratar isso como 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 a mesma sorte. Na primeira vez, a culpa é dos atacantes. Na 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.

‍