- O GitHub atualizou os comportamentos padrão do npm e do Actions para interromper múltiplos elos em ataques à cadeia de suprimentos.
- Contas do npm que sofrerem alterações sensíveis como e-mail ou 2FA terão as permissões reduzidas para leitura por 72 horas automaticamente.
- A versão npm v12 desativará scripts automáticos de instalação por padrão para evitar a execução silenciosa de malwares.
- Desenvolvedores questionam a eficácia dos prazos de resfriamento, sugerindo que assinaturas de código criptográficas dos autores seriam mais robustas.
Restrições automáticas no npm e no GitHub actions<\/h2>
Para conter os comprometimentos iniciais de contas, o npm agora coloca contas de alto impacto em modo somente-leitura por 72 horas imediatamente após a alteração do endereço de e-mail ou o uso de códigos de recuperação de autenticação multifator (2FA). Do lado do GitHub Actions, o comportamento padrão do utilitário 'actions/checkout' foi modificado para que os fluxos de trabalho não façam checkout de código de forks não confiáveis em gatilhos comumente explorados, a menos que os desenvolvedores desativem explicitamente essa regra. Essa mudança foi aplicada retroativamente até mesmo para pipelines que utilizavam versões anteriores fixadas.
Duas novas camadas de controle visam impedir a escalada de privilégios dentro das plataformas. As políticas de execução de workflows agora permitem que administradores decidam quem e quais eventos podem disparar ações automáticas. Além disso, o cache do Actions passou a ser configurado como somente-leitura para gatilhos de repositórios não confiáveis, fechando o vetor de ataque onde invasores envenenavam caches compartilhados para alcançar pipelines de publicação com privilégios elevados.
Eliminação de credenciais e mudanças no npm v12<\/h2>
A recomendação para mitigar a exfiltração de credenciais é direta: remover credenciais de longa duração dos pipelines de desenvolvimento. Para facilitar esse processo, a publicação confiável (Trusted Publishing) do npm agora suporta o CircleCI. Adicionalmente, um firewall de rede para o Actions está em fase de visualização técnica (technical preview), permitindo monitorar o tráfego de saída dos fluxos de trabalho para identificar destinos suspeitos.
# publicidade
No quesito propagação de pacotes, o recurso de publicação em etapas (staged publishing) do npm retém as novas versões até que uma aprovação adicional e um fluxo de 2FA sejam concluídos. Já o npm v12 trará uma mudança impactante: os scripts de instalação pós-instalação (install scripts) virão desativados por padrão, assim como dependências buscadas diretamente via Git ou URLs remotas. O Dependabot também passará a aguardar três dias antes de abrir pull requests de atualização de versão.
Comunidade debate prazos de resfriamento versus assinaturas digitais<\/h2>
As discussões em fóruns como o Hacker News expuseram divergências significativas. O período de congelamento de 72 horas para contas após mudanças críticas foi alvo de ceticismo. Críticos apontam que desenvolvedores viajam ou tiram folgas frequentes, e que ataques costumam ocorrer estrategicamente nas sextas-feiras à noite, tornando o prazo de três dias curto demais para ações corretivas. Alguns sugeriram que um período de até 30 dias seria mais realista para a maioria dos cenários organizacionais.
Outro ponto crítico levantado foi a vulnerabilidade de domínios de e-mail expirados de autores antigos de pacotes. Casos reais demonstram que atacantes conseguem comprar esses domínios por valores irrisórios, assumindo o controle de pacotes populares que impactam dezenas de milhares de empresas. Para esse tipo de ataque, um resfriamento de 72 horas é irrelevante. Com isso, muitos desenvolvedores defendem a introdução de assinaturas digitais por parte do autor — padrão no ecossistema Linux há muito tempo — em vez de barreiras processuais temporárias. O contra-argumento operacional aponta que as assinaturas não evitam a invasão se o ambiente de compilação ou build estiver comprometido, pois a própria máquina de build assinaria o pacote malicioso automaticamente.
| Recurso de Segurança | Plataforma | Tipo de Configuração | Impacto de Segurança |
|---|---|---|---|
| Congelamento de Contas (72h) | npm | Padrão Automático | Evita sequestro imediato de pacotes de alto impacto após troca de e-mail ou reset de 2FA. |
| Bloqueio de Checkout de Forks | GitHub Actions | Padrão Automático | Impede execução automática de código malicioso vindo de repositórios não confiáveis. |
| Desativação de Install Scripts | npm v12 | Padrão do Sistema | Mitiga riscos de infecção no momento de download e instalação de pacotes. |
| Trusted Publishing (CircleCI) | npm / Provedores | Opcional (Opt-in) | Elimina a necessidade de senhas e tokens permanentes armazenados em pipelines de CI. |
Arraste para o lado para ver toda a tabela.
Perguntas frequentes (faq)<\/h2>
Por que o npm congelará contas por 72 horas?<\/h3>
Para impedir que invasores publiquem pacotes maliciosos imediatamente após comprometerem uma conta de desenvolvedor, limitando as permissões à leitura temporariamente após mudanças de e-mail ou 2FA.
O que muda nos scripts de instalação com o npm v12?<\/h3>
Os scripts que rodam automaticamente no momento de instalação de um pacote serão desativados por padrão, reduzindo o risco de códigos maliciosos agirem silenciosamente na máquina do desenvolvedor.
Qual a diferença entre a publicação confiável (trusted publishing) e métodos antigos?<\/h3>
A publicação confiável utiliza tokens efêmeros de curto prazo e integrações com provedores de CI/CD para autenticação, eliminando o uso de senhas ou chaves de longa duração gravadas nos sistemas.
