Você sabe o que está rodando dentro da sua imagem? Cadeia de suprimentos de software

Seu código pode ter 2 mil linhas. A imagem que vai para produção pode ter centenas de pacotes que ninguém do time escolheu. Uma reflexão sobre confiança em tudo aquilo que você não escreveu.

Fala pessoal, tudo bem?

Em março de 2024 um engenheiro da Microsoft percebeu que o login por SSH estava cerca de meio segundo mais lento que o normal. Curioso, foi investigar. Encontrou uma backdoor no xz, uma biblioteca de compressão presente em praticamente toda distribuição Linux.

O atacante passou cerca de dois anos ganhando a confiança do mantenedor do projeto até conseguir publicar versões com código malicioso. Por pouco aquilo não chegou às versões estáveis das grandes distros.

A lição: o ataque não foi no código da empresa. Foi em uma dependência da dependência, mantida por uma pessoa só, no tempo livre. Isso é cadeia de suprimentos de software.

O iceberg da sua aplicação

Seu código Bibliotecas que você declarou Dependências transitivas Imagem base: SO, libc, openssl, xz... O que você revisa O que vai junto para produção

Exemplo: olhando por baixo d'água

Duas ferramentas abertas ajudam a responder "o que tem aqui dentro?". O syft gera a lista de componentes (o SBOM, a "lista de ingredientes"). O grype ou o trivy cruzam essa lista com vulnerabilidades conhecidas.

# quantos pacotes existem na imagem?
$ syft nginx:latest -q | wc -l

# gerar o SBOM em formato padrão (SPDX)
$ syft nginx:latest -o spdx-json > sbom-nginx.json

# vulnerabilidades conhecidas, só as graves
$ trivy image --severity HIGH,CRITICAL nginx:latest

Faça o teste com a imagem que o seu time usa em produção. O número costuma assustar na primeira vez.

💡 Menos é mais seguro: imagens mínimas (distroless, slim, alpine) têm muito menos pacotes. Menos pacotes significa menos coisa para atualizar, menos CVE no relatório e menos ferramentas à disposição de um invasor.

Quatro hábitos que reduzem o risco

1. Fixe versões. FROM nginx:latest muda sem avisar. Use uma tag específica ou, melhor ainda, o digest (nginx@sha256:...).
2. Escaneie na pipeline, não só uma vez. Uma imagem limpa hoje pode ter CVE crítica amanhã.
3. Gere e guarde o SBOM de cada versão publicada. Quando sair a próxima "xz", você responde em minutos se foi afetado.
4. Atualize a imagem base com frequência, mesmo sem mudança no código. Rebuild também é manutenção.

# exemplo de etapa no GitHub Actions: falha o build se houver CVE crítica
- name: Scan da imagem
  run: |
    trivy image --exit-code 1 --severity CRITICAL \
      --ignore-unfixed minha-app:${{ github.sha }}

⚠️ Cuidado com a fadiga de alerta: um relatório com 300 CVEs é ignorado. Comece bloqueando só o crítico com correção disponível (--ignore-unfixed) e vá apertando. Mesma lógica de alertas do SRE: alerta que ninguém age é ruído.

Considerações Finais

Ninguém consegue revisar todo o código que roda em produção. Mas dá para saber o que está lá, reduzir o que não precisa estar e reagir rápido quando algo for descoberto.

E, como vimos no caso do Ingress NGINX, vale lembrar: muitas peças críticas são mantidas por pouquíssimas pessoas. Contribuir, patrocinar ou ao menos conhecer quem mantém o que você usa também é segurança.

Abs e até a próxima!!!

:wq!