Como auditar vulnerabilidades em imagens Docker no CI com SBOM

Por que auditar imagens Docker antes do build final?

Quando construímos containers para colocar aplicações no ar, muitas vezes focamos apenas em fazer o código funcionar. No entanto, cada pacote que instalamos traz consigo uma bagagem de dependências que pode esconder portas dos fundos para invasores. Na prática, isso significa que uma biblioteca esquecida lá no fundo do sistema operacional pode colocar todo o seu servidor em risco. Para evitar surpresas desagradáveis em produção, precisamos checar a segurança muito antes de enviar a imagem para o ambiente final.

Fazer essa varredura diretamente na nossa esteira de integração contínua (o sistema automatizado que testa e empacota o código a cada alteração) muda completamente o jogo. Em vez de descobrir brechas quando o sistema já está rodando para clientes, pegamos o problema na raiz, bloqueando o processo de publicação caso algo perigoso seja encontrado. Isso garante que nenhum código vulnerável escape para o mundo real, mantendo a reputação do projeto intacta e poupando horas preciosas de correção emergencial.

O que é um SBOM e por que ele revolucionou a segurança

Para auditar um container de forma eficiente, a engenharia moderna abandonou a ideia de apenas escanear o binário pronto e passou a utilizar o conceito de SBOM, que significa Bill of Materials ou, em uma tradução livre, a lista de ingredientes do software. Pense nisso como a bula de um remédio ou a lista de componentes impressa na caixa de um eletrodoméstico. O SBOM cataloga cada biblioteca, módulo e ferramenta presentes no container, detalhando exatamente suas versões e origens.

Quando temos essa lista detalhada em mãos, a varredura deixa de ser um trabalho de adivinhação pesada e passa a ser uma consulta rápida a bases de dados públicas de vulnerabilidades conhecidas (as chamadas CVEs, ou exposições comuns de vulnerabilidades). É exatamente por isso que gerar essa lista antes de fechar o pacote final se tornou o padrão ouro da indústria. Ferramentas como o Syft, criado especificamente para essa finalidade, conseguem esmiuçar o sistema de arquivos em segundos e cuspir um inventário cirúrgico de tudo o que compõe a aplicação.

Passo a passo para integrar o Syft e o Grype no GitHub Actions

Para colocar essa teoria em prática no dia a dia, vamos configurar um fluxo automatizado utilizando o GitHub Actions, a ferramenta nativa de automação do GitHub. O processo consiste em gerar o SBOM do nosso projeto e, em seguida, passá-lo para um scanner analisar se há brechas críticas. Caso encontre problemas graves, o pipeline é interrompido imediatamente, funcionando de forma muito parecida com o controle rígido que aplicamos quando evitamos travas em ambientes complexos, a exemplo do que discutimos sobre como usar feature flags no ArgoCD para mitigar riscos de lançamento.

O primeiro passo é estruturar o arquivo YAML de configuração dentro da pasta de workflows do seu repositório. Abaixo, veja um exemplo prático de como declarar os passos de montagem, geração do inventário e auditoria de segurança usando as ferramentas da Anchore:

name: Seguranca de Containers
on: [push]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - name: Clonar Repositorio
        uses: actions/checkout@v4
      - name: Gerar SBOM com Syft
        uses: anchore/sbom-action@v0
        with:
          image: minha-app:latest
          format: spdx-json
          output-file: sbom.json
      - name: Auditar Vulnerabilidades com Grype
        uses: anchore/scan-action@v3
        with:
          sbom: sbom.json
          severity-cutoff: high

Esse fluxo roda de maneira totalmente autônoma a cada alteração enviada ao repositório. O utilitário Syft gera o arquivo espelho da estrutura, enquanto o Grype cruza esses dados com os boletins globais de segurança, aplicando um corte de severidade para barrar apenas o que realmente importa para a integridade da infraestrutura.

Lidando com falsos positivos e ajustes de severidade

Um dos maiores desafios ao implementar varreduras automatizadas de segurança é o volume de alertas falsos que aparecem logo nas primeiras execuções. Nem toda vulnerabilidade apontada por um scanner representa um risco real para o seu cenário específico. Na prática, muitas falhas ocorrem em pacotes do sistema operacional que nem sequer são executados pela sua aplicação. Se bloquearmos o build por qualquer aviso menor, a equipe de desenvolvimento rapidamente perderá a paciência com o processo.

Para contornar esse problema, é fundamental configurar políticas de exceção e utilizar limiares de corte bem definidos, como focarmos apenas em vulnerabilidades de nível crítico ou alto que possuam correção disponível. Além disso, manter as imagens base atualizadas regularmente — migrando para versões mais enxutas como Alpine ou distroless — reduz drasticamente a superfície de ataque e o número de alertas barulhentos no pipeline.

Considerações finais sobre segurança contínua em containers

A auditoria de vulnerabilidades baseada em SBOM no pipeline de CI não é apenas uma exigência burocrática de conformidade, mas uma camada indispensável de proteção para qualquer projeto moderno. Ao shift-left (ou seja, puxar a segurança para as etapas iniciais do desenvolvimento), economizamos tempo, evitamos incidentes constrangedores em produção e garantimos que a equipe de engenharia entregue valor com confiança e estabilidade.

Adotar essa cultura exige disciplina e ajustes finos constantes nas regras de bloqueio, mas o retorno sobre o investimento é imediato. Com o ecossistema atual de ferramentas open source, qualquer equipe pode implementar defesas robustas em poucas horas, transformando a segurança de containers de um problema invisível em um processo automatizado e transparente.