Ataques supply chain agora miram confiança, não dependências

Mais de 454.000 novos pacotes maliciosos foram identificados em npm, PyPI, Maven Central e NuGet somente em 2025 — levando o total acumulado para além de 1,2 milhão de artefatos conhecidos de malware na cadeia de suprimentos. Mas o número esconde a mudança mais importante: ataques supply chain modernos não dependem mais de desenvolvedores instalando um pacote obviamente errado. Comprometem os sistemas que times já confiam — build pipelines, tokens OIDC, attestations de provenance, contas de maintainers — e publicam código malicioso por canais que parecem exatamente um release normal.

O modelo de ameaça mudou. Escanear dependências por vulnerabilidades conhecidas ainda importa, mas aborda a geração anterior de ataques. A geração atual falsifica os sinais de confiança nos quais o escaneamento se apoia. Um pacote com provenance SLSA Build Level 3 válido, publicado do repositório oficial pelas credenciais do maintainer oficial, passando todos os checks de CI — esse pacote pode ser malicioso. A superfície de ataque não é mais a árvore de dependências. É a infraestrutura que produz e certifica a árvore de dependências.

A cadeia de suprimentos é agora o ambiente de execução

Ataques supply chain evoluíram de envenenamento passivo — publicar um pacote com typosquatting e esperar alguém instalá-lo — para exploração ativa da infraestrutura de build. Os worms auto-replicantes descobertos em 2025 e 2026 se movem por pipelines de CI/CD de forma autônoma, roubando credenciais e se propagando para pacotes adicionais sem intervenção humana.

O padrão de ataque: comprometer uma conta de maintainer (frequentemente por reutilização de credenciais ou phishing), injetar um preinstall hook em um pacote popular, e usar esse hook para extrair secrets do CI runner executando npm install. Os tokens roubados — tokens de publicação do npm, tokens OIDC do GitHub Actions, credenciais AWS, tokens de service accounts do Kubernetes — se tornam o meio para comprometer o próximo pacote, que compromete o próximo projeto, que expõe o próximo conjunto de credenciais.

Isso não é uma cadeia teórica. Em maio de 2026, pacotes de visualização comprometidos dispararam impacto cascata em downstream para bibliotecas com mais de um milhão de downloads semanais. O payload extraiu memória de processo dos runners do GitHub Actions, exfiltrou credenciais multi-plataforma, e usou tokens npm roubados para publicar pacotes comprometidos adicionais — tudo dentro do contexto de execução legítimo do CI/CD.

Sinais de confiança podem ser sequestrados — incluindo provenance assinado

SLSA (Supply-chain Levels for Software Artifacts) foi projetado para resolver exatamente esse problema: provar que um pacote foi construído a partir de um commit específico, em um builder específico, sem manipulação. Mas provenance só prova origem. Não prova que a origem era segura.

Em maio de 2026, atacantes exploraram misconfigurações de pull_request_target no GitHub Actions para sequestrar pipelines de release e publicar dezenas de pacotes com attestations válidas de SLSA Build Level 3. A provenance era genuína — o build rodou na plataforma esperada, do repositório esperado, assinado pela identidade esperada. O pipeline em si foi o componente comprometido. Cada sinal de confiança verificou corretamente porque o ataque operou dentro dos limites do sistema confiado.

Isso quebra o modelo mental que a maioria dos times carrega: "se os checks de provenance passam, o artefato é seguro." Provenance prova que o artefato veio de um pipeline específico. Não prova que o pipeline não estava comprometido antes do artefato ser produzido. A resposta da verificação é "sim, isso foi construído aqui" — mas a pergunta que times realmente precisam responder é "esse ambiente de build era confiável no momento em que construiu esse artefato?"

Tokens de CI são credenciais de produção de alto valor

Um runner de GitHub Actions com permissões contents: write e packages: write pode publicar pacotes, fazer push para repositórios e modificar artefatos de release. Um runner com id-token: write pode emitir tokens OIDC aceitos por cloud providers. Esses não são conveniências de desenvolvimento. São credenciais de produção armazenadas no maior cofre de secrets que a maioria das organizações mantém — o sistema de CI em si.

As prioridades de hardening:

• Princípio do menor privilégio em permissões de workflow. Default permissions: {} no nível do workflow. Conceder contents: read ou id-token: write apenas a jobs específicos que necessitam. Nunca usar permissions: write-all fora de workflows de release explicitamente auditados.
• Pinear actions a SHAs de commit imutáveis, não tags. Tags podem sofrer force-push para apontar a commits diferentes. Um SHA é imutável. uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 sobrevive manipulação de tags; uses: actions/checkout@v4 não.
• Separar build e publish em jobs distintos. O job que compila código não precisa de credenciais de publicação. O job que publica deve ter acesso de leitura a outputs de build e acesso de escrita ao registry — nada mais.
• Usar pull_request ao invés de pull_request_target a menos que o workflow explicitamente precise de acesso a secrets para PRs de forks. O trigger pull_request_target roda no contexto do branch base com acesso completo a secrets — um arquivo de workflow mal configurado transforma cada fork PR em um vetor potencial de exfiltração de credenciais.
• Restringir audience e claims do token OIDC. Delimitar tokens OIDC ao mínimo set de recursos cloud e condições. Um token que autentica para * na AWS não é uma credencial temporária — é uma chave-mestra com data de expiração.

Dependências transitivas transformam exposição em um problema de grafos

Dependências diretas são auditáveis. Dependências transitivas — os pacotes dos quais seus pacotes dependem — formam um grafo que nenhum humano revisa por completo. Um único patch release comprometido cinco camadas abaixo se propaga para milhares de projetos durante a janela entre publicação e detecção.

As mitigações práticas:

• Lockear dependências em hashes exatos, não version ranges. Um package-lock.json ou bun.lockb pineado a hashes de integridade específicos significa que um patch release comprometido não entra silenciosamente no build até que alguém explicitamente atualize o lockfile e revise o diff.
• Desabilitar lifecycle scripts por padrão no CI. Usar --ignore-scripts durante instalação. Allow-list apenas os pacotes específicos cujos postinstall hooks são necessários (compilação nativa, por exemplo). A vasta maioria dos pacotes legítimos não precisa executar código durante a instalação.
• Monitorar mutações de dependências. Um patch release que não muda código-fonte mas adiciona um script preinstall é um sinal. Um release publicado de um IP ou região geográfica diferente do padrão histórico do maintainer é um sinal. Ferramentas que detectam essas anomalias no nível do registry existem — a questão é se times as integram antes ou depois do incidente.
• Manter inventário de cada pacote com acesso transitivo a secrets de CI. Se um pacote roda durante npm install em um job que tem permissões id-token: write, esse pacote tem acesso indireto ao token OIDC. O raio de explosão efetivo não é a árvore de dependências — é a interseção da árvore de dependências e o grafo de permissões.

A janela entre comprometimento e detecção é a variável crítica. Nos incidentes de maio de 2026, patch releases comprometidos ficaram ativos por horas a dias antes que os registries os removessem. Cada projeto que rodou npm install durante essa janela executou o payload. Os projetos usando lockfiles pineados na versão anterior não foram afetados — a versão comprometida nunca entrou no build até que um humano revisasse a atualização. Lockfiles não são uma otimização de performance. São uma fronteira de segurança que converte um comprometimento supply chain zero-day em um diff revisável.

Perguntas frequentes sobre ataques supply chain e confiança?

A prioridade depende do raio de explosão de um comprometimento. Começar com os alvos de maior valor: credenciais de publicação e permissões de tokens de CI/CD.

Qual é o primeiro passo para hardear CI/CD contra comprometimento supply chain?

Auditar cada arquivo de workflow por permissões excessivas. Default todos os workflows para permissions: {} e conceder permissões específicas apenas a jobs que precisam. Remover triggers pull_request_target a menos que sejam essenciais e tenham sido revisados por um engenheiro de segurança. Pinear todas as actions de terceiros a SHAs de commit. Essa única passada elimina o ponto de entrada mais comum para ataques em nível de pipeline sem requerer tooling novo.

Provenance SLSA protege contra ataques supply chain?

Provenance SLSA prova que um artefato foi construído por um builder específico a partir de uma fonte específica. Não prova que o ambiente de build não estava comprometido no momento do build. Provenance é uma camada necessária — elimina classes de manipulação que acontecem depois do build. Mas não é suficiente quando o ataque ocorre dentro do build pipeline em si. Tratar provenance como um sinal em um stack de verificação multi-camada, não como uma decisão binária de confiança.

Times devem bloquear pacotes sem attestations de provenance?

Bloquear pacotes sem attestations é uma política defensável para deployments de produção — mas o ecossistema ainda não está lá. A maioria dos pacotes em npm e PyPI não publica provenance SLSA. Um passo intermediário prático: requerer attestations para dependências diretas, monitorar dependências transitivas por anomalias, e gatear apenas o pipeline de deployment (não cada install de desenvolvimento) com verificação de provenance.

Um ponto de vista oposto

Um argumento comum sustenta que ferramentas de escaneamento de dependências — Snyk, Socket, Dependabot, npm audit — capturam a vasta maioria das ameaças supply chain antes que cheguem a produção. Para times sem capacidade dedicada de engenharia de segurança, investir em hardening de pipeline e verificação de provenance é uma distração de práticas de maior impacto como habilitar MFA em contas de maintainers, manter dependências atualizadas, e rodar scans básicos de vulnerabilidades.

Essa visão está correta sobre prioridade relativa para times pequenos. Um time sem escaneamento algum deveria adicionar escaneamento antes de se preocupar com attestations SLSA. Mas a geração atual de ataques especificamente mira o gap entre o que scanners detectam e o que o build pipeline confia. Um pacote comprometido publicado por uma conta legítima, sem CVE conhecido, e com provenance válido — esse pacote passa por todos os scanners. A postura defensiva que depende exclusivamente de escaneamento é a postura que os ataques atuais são projetados para evadir.

O que vale a pena lembrar

• Ataques supply chain modernos miram sistemas de confiança — tokens de CI, attestations de provenance, contas de maintainers — não apenas dependências.
• Provenance prova origem. Não prova segurança. Um pacote com attestations SLSA válidas pode ser malicioso se o build pipeline estava comprometido.
• Runners de CI com permissões amplas são credenciais de produção. Default todas as permissões de workflow para vazio e conceder acesso por job.
• Pinear actions a SHAs de commit, desabilitar lifecycle scripts no CI, e lockear dependências em hashes exatos — esses três controles eliminam os vetores de propagação mais comuns.
• Dependências transitivas intersectadas com grafos de permissões de CI definem o raio de explosão real. Auditar essa interseção, não apenas a árvore de dependências.
• Scanners de dependências capturam ameaças conhecidas. A geração atual de ataques é projetada para evadi-los operando dentro de limites confiados.

Conclusão

O modelo de ameaça da cadeia de suprimentos mudou de "alguém pode instalar um pacote ruim" para "alguém pode publicar um pacote ruim por um sistema que a organização já confia." As defesas que funcionavam contra typosquatting e vulnerabilidades conhecidas — escaneamento, atualização, higiene básica — são necessárias mas não mais suficientes. A próxima camada requer tratar a infraestrutura de CI/CD como um perímetro de segurança, tratar cada token como um path potencial de movimentação lateral, e aceitar que provenance é um sinal, não uma garantia. O ataque que chega por um pacote assinado, attestado, verificado pelo CI, de uma conta de maintainer que era legítima ontem — esse é o ataque que o tooling atual não captura por padrão, e para o qual todo time de produção precisa de um plano de resposta.