GitHub reforça defaults de segurança em npm e Actions e reacende debate sobre delays versus assinatura

O GitHub reuniu em um único comunicado as mudanças que aplicou em npm e GitHub Actions entre março e julho de 2026 para dificultar ataques à cadeia de suprimentos de software, segundo reportagem da InfoQ. Nada ali é inédito, já que cada item foi anunciado individualmente no changelog, mas o texto deixa claro quantas dessas mudanças alteram defaults em vez de apenas oferecer novas opções.

Greg Ose, principal product security engineer, e Zachary Steindler, principal software engineer, descrevem o problema como um que não tem correção única: esses ataques encadeiam várias fraquezas, então o GitHub priorizou as mitigações que quebram os elos mais críticos.

O que muda no comportamento padrão

Entre as mudanças principais relatadas pela fonte:

• Contas de alto impacto no npm entram em modo somente leitura por 72 horas ao trocar o e-mail ou usar um código de recuperação de 2FA.
• actions/checkout mudou o comportamento padrão para não fazer checkout de código de forks não confiáveis em gatilhos comumente explorados, a menos que a equipe opte explicitamente por sair. A mudança foi backported, alcançando pipelines que fixaram releases anteriores.
• Políticas de execução de workflow permitem que admins controlem quem dispara workflows e quais tipos de gatilho são permitidos; o cache do Actions passou a ser somente leitura para gatilhos não confiáveis.
• npm trusted publishing agora suporta CircleCI, e um firewall de rede do Actions está em preview técnico, registrando tráfego de saída para detectar destinos incomuns.
• npm v12 desabilita scripts de instalação por padrão, além de dependências obtidas via git ou URLs remotas.
• Dependabot passou a esperar três dias antes de abrir um pull request de atualização de versão.

O debate: delay ou assinatura

As reações no Hacker News, segundo a InfoQ, se dividiram menos sobre os controles individuais e mais sobre se atrasos de tempo são o instrumento certo. O congelamento de 72 horas gerou discussão sobre como o número foi escolhido. O comentarista datakan argumentou que mantenedores viajam e adoecem, e que ataques costumam ser cronometrados para sextas-feiras: "3 dias é absurdo. Até apps de senha com kill switch usam 7 dias por padrão."

Uma objeção mais dura veio de lrvick, que relatou ter comprado por oito dólares o domínio de e-mail expirado do autor único de um pacote npm, colocando a capacidade de publicar código para cerca de 70 mil empresas ao alcance de um reset de senha. "72 horas não fariam diferença aqui." Ele defende assinatura de pacotes pelo autor, como distribuições Linux têm desde os anos 1990, algo que o npm teria rejeitado por uma década.

A réplica veio de acdha, para quem o que mantém distribuições Linux mais seguras é ter menos pessoas com acesso de push somado a um atraso de tempo, não a assinatura em si: se a infraestrutura de build for comprometida, ela assinará alegremente os pacotes comprometidos também. Já pimterry explicou por que o staged publishing ajuda: é preciso comprometer o workflow e completar um fluxo separado de 2FA como mantenedor, e o workflow nunca vê chaves capazes de publicar sozinho.

O que isso muda para quem constrói software no Brasil

A InfoQ aponta uma assimetria: as mudanças que chegam automaticamente são as moderadas, enquanto as proteções mais fortes (staged e trusted publishing) continuam opt-in e com adoção desigual.

Na prática, para times brasileiros que dependem de npm e GitHub Actions nos seus pipelines, vale atenção a dois pontos concretos citados na reportagem. Primeiro, a mudança de default no actions/checkout foi backported, então pode alterar o comportamento de workflows mesmo em versões fixadas. Segundo, a desativação de scripts de instalação por padrão no npm v12 pode quebrar builds que nunca auditaram o que roda no momento da instalação.

Se as reações forem representativas, a discórdia não é sobre se os controles ajudam, mas sobre o que eles substituem: o GitHub escolheu mecanismos que funcionam sem participação do mantenedor, enquanto o mecanismo que os praticantes seguem pedindo, a assinatura pelo autor, exige exatamente essa participação. As mudanças estão em rollout agora, com o GitHub apontando para o changelog para o restante.

Fonte: InfoQ