Cada pacote instalado é um fornecedor sem contrato

Aprovar a política de dependências com janela de quarentena, tratamento de scripts de instalação, registro intermediário, inventário de componentes por build e responsável nomeado.

• Dimensionar quantos autores sem contrato executam código dentro da nossa esteira a cada publicação.
• Aprovar os cinco controles de dependência que os incidentes de 2026 provaram necessários.
• Antecipar a exigência de inventário de componentes legível por máquina antes do prazo regulatório.

Em linguagem simples

Software moderno não é escrito do zero. Ele monta peças prontas, publicadas por pessoas desconhecidas em um catálogo público, e cada peça costuma trazer outras dez atrás de si. Um projeto comum instala centenas ou milhares dessas peças, escritas por centenas de autores que a sua empresa nunca contratou, nunca avaliou e não consegue nomear.

O detalhe que muda tudo é o momento da instalação. Muitas dessas peças conseguem executar código durante a própria instalação, dentro da máquina que monta o seu produto, com o mesmo privilégio da esteira. É a máquina que carrega a credencial de publicação, o acesso à nuvem e as chaves do produto. Foi exatamente por aí que os ataques de 2026 entraram.

1. 01A árvore de dependências é maior do que a lista que alguém escolheu. O time escolhe algumas dezenas de peças. Cada uma traz as suas, recursivamente. O número final de autores com código executado no seu build costuma passar de mil e quase nunca foi medido.
2. 02Instalar já é executar. Scripts de ciclo de vida rodam automaticamente durante a instalação, antes do código da aplicação. Em vários incidentes de 2026 foi esse o gatilho, e a vítima só descobriu depois.
3. 03A janela crítica é de minutos a horas. Nos casos de 2026 a detecção externa levou de vinte a trinta minutos e a remoção levou horas. Quem instala imediatamente após a publicação pega a versão envenenada; quem espera um dia, não pega.
4. 04O alvo é o cofre da sua esteira. O código malicioso procura credenciais de nuvem, de registro e de publicação na máquina que constrói o produto. Um pipeline com acessos amplos é um ponto único de coleta.

Confusão mais comum: Acreditar que travar as versões no arquivo de bloqueio resolve. O arquivo de bloqueio garante que todo mundo instale exatamente a mesma coisa, o que é bom para reprodutibilidade e neutro para segurança: se a versão travada for a envenenada, todo mundo instala a envenenada, de forma perfeitamente reproduzível.

Explique em voz alta: Escreva no papel, antes de perguntar a alguém, quantos autores diferentes executam código dentro do build do seu produto e como a sua empresa descobriria, hoje, que um deles foi comprometido.

O fornecedor que entrou sem passar pelo departamento de compras

A Nortis tem processo de compras. Fornecedor de software passa por avaliação, assina contrato, responde questionário de segurança e tem cláusula de responsabilidade. Isso vale para os oito fornecedores que aparecem na planilha do jurídico. Não vale para os mais de mil autores cujo código é executado toda vez que alguém do time publica.

A diferença entre os dois grupos é de visibilidade. O fornecedor com contrato entrega uma tela que alguém vê. O mantenedor de uma biblioteca entrega código que roda dentro da máquina que constrói o produto, com o mesmo privilégio da esteira, ao lado da credencial que publica em produção e das chaves de acesso à nuvem.

Entre abril e julho de 2026, seis campanhas relevantes atacaram exatamente esse ponto. Não é cauda longa nem azar estatístico: é cadência. E o código do programa que automatiza o ataque foi publicado abertamente em 12 de maio de 2026, o que reduziu o custo de entrada para copiadores. A pergunta de comitê deixou de ser se acontece e passou a ser em quanto tempo detectamos e em quanto tempo revertemos.

Quatro casos que derrubaram quatro controles considerados suficientes

Quatro das seis campanhas contadas pela Unit 42 entre abril e julho de 2026, em atualização de 15 de julho de 2026, detalhadas a partir dos relatos primários de cada caso. A coluna da direita é a que importa para a política: cada incidente derrubou um controle que muita empresa considerava suficiente.

Evidência pública

Caso documentado: o pipeline legítimo publicando malware

AsyncAPI, projeto de especificação de APIs

Em 14 de julho de 2026, quatro pacotes do projeto foram publicados com código malicioso. O atacante obteve permissão de envio em um ramo de pré-produção desprotegido às 06h58 UTC e o próprio workflow oficial de publicação enviou os pacotes ao registro às 07h10 UTC. Nenhum token foi roubado e os pacotes saíram com atestação de proveniência válida.

• Os ramos principais tinham proteção e revisão obrigatória; os ramos de pré-produção usados para publicar estavam desprotegidos.
• Quatro pacotes afetados, com mais de 2,9 milhões de descargas semanais somadas.
• A carga é disparada no carregamento do módulo pela aplicação, e não durante a instalação, o que contorna a mitigação de desligar scripts de instalação.
• O intervalo entre o envio ao ramo e a publicação no registro foi de doze minutos.

Proteção de ramo aplicada só no ramo principal é teatro de governança. Qualquer ramo com permissão de publicar é ramo de produção e precisa do mesmo controle. E qualquer mitigação única, inclusive desligar scripts de instalação, é derrubada assim que o atacante muda o momento do disparo.

Análise de fornecedor especializado em segurança de integração contínua, com dados de horário e versões conferidos contra o registro público de pacotes.

Modelo operacional

Os cinco controles da política de dependências

Escritos na ordem de retorno por real investido. Os dois primeiros custam quase nada e cobrem a maior parte dos casos de 2026. Cada um recebe um responsável nomeado e uma data de entrada em vigor.

• Janela de quarentena para versão recém-publicada: Nenhuma versão publicada há menos de 24 a 72 horas entra no build, salvo exceção nominal para correção de vulnerabilidade ativamente explorada. É o controle de maior retorno, porque nos incidentes de 2026 a detecção externa veio em dezenas de minutos e a remoção em horas. Exemplo: A Nortis adotou 48 horas. A exceção precisa de aprovação escrita do dono da política, com o motivo registrado.
• Scripts de instalação desligados por padrão: A instalação passa a não executar código de terceiro automaticamente. Onde algum pacote realmente precisar, a permissão é nominal, com o pacote listado e justificado. Não cobre o caso em que a carga dispara no carregamento do módulo, e por isso não é mitigação única. Exemplo: Configuração no arquivo de preferências do gerenciador de pacotes, aplicada também às máquinas de construção, não apenas às máquinas dos desenvolvedores.
• Registro intermediário como procurador: As peças passam a ser buscadas em um registro sob controle da empresa, que espelha o público. Ele é o lugar onde a quarentena é aplicada de fato, onde uma versão pode ser bloqueada em minutos para toda a empresa e onde fica o registro do que foi baixado e quando. Exemplo: Bloquear uma versão comprometida deixa de depender de cada time atualizar o próprio arquivo de bloqueio e passa a ser uma ação central.
• Saída de rede restrita na máquina de construção: A máquina que monta o produto só fala com os destinos previstos. Isso não impede a execução do código malicioso e impede o envio do que ele coletou, que é o passo que transforma comprometimento em vazamento. Exemplo: No Cloudflare, o tráfego de Workers para a internet pública pode ser filtrado por política com registro de DNS, HTTP e rede desde 05/06/2026. O mesmo princípio se aplica à máquina de construção.
• Inventário de componentes gerado e arquivado por build: Lista legível por máquina de tudo que entrou no artefato, com versão, gerada automaticamente e guardada junto com o artefato. É o que permite responder em minutos se a empresa foi atingida por uma campanha divulgada hoje. Exemplo: Sob o Cyber Resilience Act, o inventário passa a ser documentação técnica obrigatória, cobrindo no mínimo as dependências de primeiro nível, com aplicabilidade plena em 11 de dezembro de 2027. Gerar agora custa perto de zero; reconstruir sob prazo regulatório, não.

Nenhum dos cinco impede o comprometimento de conta de mantenedor legítimo, que foi o vetor de pelo menos dois dos casos de 2026. Eles reduzem a probabilidade de instalar na janela quente, impedem execução automática, limitam a saída dos dados e encurtam o tempo de resposta. A política precisa declarar esse limite.

Rotina real

O aviso chega às 19h30 de uma sexta-feira

Responsável nomeado por acompanhar alertas de dependência, na Nortis · Verificação diária dos avisos de segurança do ecossistema, quinze minutos, com plantão definido para fim de semana e feriado.

Situação: Um boletim público informa que um pacote com milhões de descargas semanais teve versões maliciosas publicadas há cerca de uma hora. A pergunta que chega ao plantão é uma só: nós usamos isso, e desde quando.

Entradas: O boletim com nome do pacote e faixa de versões afetadas, mais o inventário de componentes arquivado a cada build dos últimos noventa dias.

Processo: Buscar o nome do pacote e a faixa de versões nos inventários arquivados; se houver correspondência, identificar quais builds e quais artefatos publicados a contêm; bloquear a versão no registro intermediário para toda a empresa; verificar se algum build ocorreu dentro da janela quente; se sim, tratar como comprometimento de credencial da esteira e acionar o procedimento de revogação do módulo 13.

Saída: Resposta escrita em menos de trinta minutos, com a lista de artefatos afetados ou a confirmação de que não há correspondência, e a decisão de acionar ou não a revogação de credenciais.

Verificação humana: A ausência de correspondência no inventário não encerra o caso sozinha. Uma pessoa confirma que o inventário cobre o período inteiro e que nenhum build recente ficou de fora do arquivamento, porque o silêncio de um sistema mal configurado se parece muito com boa notícia.

Como se mede: Tempo entre a publicação do boletim e a resposta escrita sobre exposição, medido a cada ocorrência e apresentado no comitê trimestral.

Guardrail

As frases que aparecem antes de todo incidente de cadeia de suprimentos

As cinco já foram ditas em reuniões que terminaram bem e em reuniões que terminaram mal. O que separa uma da outra é a existência de um controle escrito por trás da frase. Use a lista como roteiro de pergunta na próxima revisão de segurança, e não como acusação.

• Está medido, e não estimado, quantos autores distintos têm código executado dentro do build do produto principal.
• A janela de quarentena está escrita em horas, com dono da exceção nomeado, e vale também para correção de defeito comum, não só para funcionalidade nova.
• Os scripts de instalação estão desligados por padrão nas máquinas de construção, e não apenas nas máquinas dos desenvolvedores.
• Existe um lugar único onde uma versão pode ser bloqueada para toda a empresa em minutos, sem depender de cada time atualizar o próprio arquivo.
• A saída de rede da máquina de construção é restrita a destinos previstos, com registro do que foi tentado fora da lista.
• O inventário de componentes é gerado e arquivado a cada build, e alguém já testou responder a um boletim usando apenas ele.
• Está escrito quem responde pelos alertas em fim de semana e feriado, com nome e suplente.

Conexão com o portal

Do ambiente de execução para a mesa do CISO: instalar é executar

O gerenciador de pacotes do ecossistema permite que uma dependência declare comandos executados automaticamente antes e depois da instalação. Eles rodam com o privilégio do processo que instalou, antes de qualquer código da aplicação.

Tradução executiva: A ação que o time chama de instalar dependências é, tecnicamente, executar código de terceiros na máquina que carrega as credenciais de produção. Isso reposiciona o assunto: deixa de ser tarefa de rotina de desenvolvimento e passa a ser execução de código não confiável dentro de um ambiente privilegiado, que é a definição de um risco que exige controle aprovado.

Use quando: alguém apresentar a atualização de dependências como manutenção rotineira que não precisa de política.

Fronteira: Desligar esses comandos reduz a superfície e não a elimina. No caso de 14 de julho de 2026 o disparo aconteceu no carregamento do módulo pela aplicação, e não na instalação, o que mantém a quarentena e a restrição de saída de rede como controles necessários.

Node.js na prática

Caso Nortis · Semana 9, quinta-feira

O time levanta quantos autores diferentes têm código executado durante um build da Nortis. O número passa de mil, e nenhum deles tem contrato com a empresa.

Entre abril e julho de 2026 houve pelo menos seis campanhas relevantes contra o registro de pacotes que a Nortis usa, com centenas de versões maliciosas publicadas em janelas de minutos. Não é cauda longa, é cadência.

Aprovar a política de dependências: janela de quarentena para versão recém-publicada, tratamento de scripts de instalação, registro intermediário, inventário de componentes por build e responsável nomeado por acompanhar alertas.

Exemplo trabalhado

Mais de mil autores e nenhum contrato

CISO da Nortis, preparando a política de dependências para o comitê

A pergunta feita ao time de plataforma foi: quantas pessoas diferentes têm código executado durante um build do nosso produto. Ninguém sabia. O levantamento levou uma tarde e o número passou de mil.

Resultado: A política sai da reunião com cinco controles aprovados, um responsável nomeado por acompanhar alertas e a janela de quarentena escrita em horas. O número de mais de mil autores vira o primeiro slide, e nenhuma discussão sobre custo dos controles sobrevive a ele.

Continua sob responsabilidade humana: Nenhum dos cinco controles impede um ataque que entre por conta comprometida de mantenedor legítimo, que foi o vetor de pelo menos dois casos de 2026. O que eles fazem é reduzir a probabilidade de instalar a versão envenenada na janela quente, impedir a execução automática no momento da instalação, limitar a saída dos dados coletados e encurtar o tempo de resposta quando o aviso chegar. A política precisa dizer isso, para que ninguém saia da reunião achando que o problema foi resolvido.

Laboratório de decisão

O time pede exceção à quarentena para aplicar uma correção de segurança

Uma correção de vulnerabilidade alta em uma biblioteca do produto foi publicada há quarenta minutos. A política aprovada exige 48 horas de quarentena. O time de segurança quer aplicar imediatamente; o time de plataforma lembra que aplicar agora é exatamente a janela em que as versões maliciosas de 2026 foram distribuídas.

Como decidir entre o risco conhecido da vulnerabilidade e o risco de instalar dentro da janela quente?

• A. Aplicar imediatamente, porque correção de segurança tem prioridade sobre política interna.: Fecha uma vulnerabilidade e abre a janela que os ataques de 2026 exploraram. Se a decisão for tomada por reflexo, a empresa terá criado um caminho permanente de contorno da política: basta chamar qualquer atualização de correção de segurança.
• B. Aguardar as 48 horas sem exceção, mantendo a política íntegra.: Preserva a regra e deixa a vulnerabilidade em aberto por dois dias. É defensável quando a vulnerabilidade não é ativamente explorada e a exposição real é baixa, e é indefensável quando há exploração em curso contra o seu perfil de produto.
• C. Aplicar com exceção nominal aprovada pelo dono da política, exigindo verificação da atestação de origem da versão e mitigação temporária enquanto a quarentena corre.: Trata a exceção como decisão registrada, com nome, motivo e prazo. A mitigação temporária, quando existe, compra tempo sem instalar na janela quente, e a verificação de origem reduz, sem eliminar, a chance de pegar artefato envenenado.

Recomendação: A terceira opção, com a exceção escrita e o critério de exploração ativa como gatilho declarado na política.

A escolha é entre dois riscos com probabilidades diferentes e o mesmo dono. Aplicar por reflexo cria precedente que esvazia a política, porque quase toda atualização pode ser descrita como correção de segurança. Esperar sempre ignora que existe um caso real, a vulnerabilidade sob exploração ativa, em que a espera é a decisão errada. A saída é escrever o gatilho na política antes de precisar dele: exploração ativa documentada dispensa a quarentena mediante aprovação nominal, tudo o mais espera. E vale reconhecer o limite honesto da verificação de origem, que é o assunto do módulo seguinte: ela prova onde o artefato foi construído, não que ele seja limpo.

• Eu sei dizer quantos autores sem contrato executam código dentro do build do meu produto, com número medido.
• Eu tenho a janela de quarentena escrita em horas e sei quem aprova exceção a ela.
• Eu consigo responder, usando só o inventário arquivado, se a empresa foi atingida por um boletim publicado hoje.

Com a política escrita, o time propõe confiar no selo de proveniência do fornecedor, e é aí que a conversa fica interessante.