Confiança na cadeia de suprimentos

Avançado14 min de leituraseguranca

Você revisa o seu código. O que roda em produção contém, além dele, centenas de bibliotecas de terceiros, uma imagem base com dezenas de pacotes do sistema, as ferramentas que constroem o artefato, as actions do pipeline e o runner que executa tudo isso.

Cada um desses é um caminho para colocar código na sua produção sem passar por revisão nenhuma. Confiança na cadeia de suprimentos é sobre tornar esse grafo visível e reduzi-lo.

O grafo de dependência real

Um package.json com 30 dependências diretas costuma resolver para mais de mil pacotes transitivos. Você escolheu 30; herdou o resto — junto com os mantenedores de cada um, suas práticas de segurança e a chance de que alguma conta seja comprometida.

npm ls --all | wc -l
go mod graph | wc -l
syft imagem:tag -o table | wc -l      # inclui os pacotes do sistema operacional

O número costuma surpreender. E ele é a superfície real, não a lista que você mantém.

Como a confiança é quebrada

Os padrões que aparecem em incidentes reais:

Conta de mantenedor comprometida. O pacote legítimo recebe uma versão maliciosa. Quem tinha ^1.2.0 atualizou sozinho.
Transferência de manutenção. O autor original entrega o projeto a um desconhecido, que publica a mudança meses depois.
Typosquatting. Um pacote com nome parecido (requets em vez de requests) captura erros de digitação.
Confusão de dependência. Um pacote público com o mesmo nome do seu pacote interno, com versão maior, é resolvido pelo gerenciador antes do privado.
Comprometimento do build. O fonte está limpo; o artefato distribuído, não. É o caso que só reprodutibilidade detecta.
Ferramenta de CI. Uma action referenciada por tag móvel muda de conteúdo sem que ninguém aprove.

Repare que a maioria não explora vulnerabilidade técnica: explora confiança concedida por padrão.

Procedência e atestação

A resposta moderna tem três peças, que respondem a perguntas diferentes:

SBOM — o que tem dentro do artefato. Responde “usamos essa biblioteca?” em minutos, no dia da CVE.
Assinatura — quem produziu. Com Sigstore, a identidade é o workflow, sem chave para guardar.
Proveniência — como foi produzido: qual commit, qual pipeline, quais entradas. É o que os níveis do SLSA formalizam.

E a peça que falta na maioria das implementações: verificar. Assinar sem verificar na admissão é cerimônia. É por isso que a política de admissão fecha o ciclo — veja assinar e verificar imagem.

Reduzir é melhor que verificar

O ponto mais importante desta página. Toda a maquinaria de verificação atua sobre uma superfície que você mesmo escolheu — e reduzir a superfície tem retorno maior e custo menor:

Menos dependências. Uma função de 20 linhas copiada e mantida por você é menos risco que um pacote com 40 transitivos. Nem sempre, mas com mais frequência do que se admite.
Imagem base mínima. Distroless elimina de uma vez a maior parte dos CVEs de sistema — que não estão no seu código e você é obrigado a tratar.
Multi-stage: compilador e ferramentas de build não vão para produção.
Espelho interno dos registries públicos: você deixa de depender de um pacote continuar existindo, e ganha um ponto de controle.
Prazo de quarentena para versões novas: adotar uma versão publicada há 24 ou 48 horas evita boa parte dos pacotes maliciosos, que são removidos rapidamente.

Higiene mínima que cabe em qualquer time

Sem projeto de um ano, e com efeito real:

Lockfile versionado, instalação com npm ci / --require-hashes / go.sum.
Actions do CI fixadas por commit SHA, não por tag.
Imagem base por digest, não por tag.
SBOM gerado no build, guardado ao lado do artefato.
SCA no pipeline, priorizando o que é alcançável e tem correção.
Atualização de dependência automatizada na abertura do PR, nunca no merge.
Revisão de dependência nova com os mesmos olhos de código próprio: quem mantém, quantos usam, quando foi o último commit.

O item 6 merece ênfase: automatizar o merge de atualizações é entregar ao ecossistema a chave da sua produção.

O limite honesto

Verificação completa de toda a cadeia é inviável para qualquer time — você não vai auditar mil pacotes. E existe risco de teatro: gerar SBOM que ninguém consulta, exigir assinatura sem verificar, acumular relatórios de CVE que ninguém prioriza.

O objetivo realista é reduzir a superfície, tornar o resto rastreável, e conseguir agir rápido quando algo aparecer. Se você consegue responder “usamos esse pacote? onde? qual versão?” em minutos, e substituir a versão em horas, você está em melhor posição que a maioria — mesmo sem SLSA nível 3.