ThiagoSoares
Voltar para o blog
DevSecOps•9 min•

Trivy no Ubuntu: vulnerabilidades, containers, IaC e secrets

Como instalar o Trivy no Ubuntu e analisar projetos, imagens Docker, configurações e dependências vulneráveis.

Compartilhar artigo

WhatsAppTelegramFacebookXLinkedIn

Trivy é uma ferramenta de segurança open source mantida pela Aqua Security. Ela ficou conhecida pela análise de imagens de container, mas hoje consegue examinar projetos, repositórios, sistemas de arquivos, Kubernetes, infraestrutura como código, secrets e SBOMs.

Gosto do Trivy porque o primeiro resultado exige pouco esforço: instalar, apontar para um alvo e executar. Ao mesmo tempo, ele possui formatos de saída e exit codes que permitem transformar a mesma análise em uma etapa do CI.

Neste artigo vou instalar o Trivy pelo repositório oficial no Ubuntu e experimentar os comandos que mais uso.

O que o Trivy encontra?

O resultado depende do alvo e dos scanners habilitados.

Vulnerabilidades

O Trivy identifica pacotes do sistema operacional e dependências da aplicação, compara versões com bases de vulnerabilidade e mostra:

  • identificador da vulnerabilidade, como um CVE;
  • severidade;
  • versão instalada;
  • versão que contém a correção, quando disponível;
  • origem e descrição do problema.

Ele consegue ler arquivos de lock de diferentes ecossistemas. Isso melhora a precisão porque a versão realmente resolvida costuma estar no lockfile, não apenas no manifesto.

Misconfigurations

O scanner de configuração verifica arquivos como:

  • Dockerfile;
  • Kubernetes YAML;
  • Terraform;
  • CloudFormation;
  • configurações de outros provedores e ferramentas de infraestrutura.

Ele procura práticas como container privilegiado, usuário root desnecessário, porta exposta, armazenamento público ou ausência de limites importantes.

Secrets

O Trivy procura credenciais em texto, incluindo tokens, chaves de API e senhas reconhecidas por regras internas.

Essa análise ajuda a detectar um vazamento antes do commit ou do deploy. Ela não substitui um gerenciador de secrets e não garante que todo formato possível será encontrado.

Licenças

Também é possível identificar licenças das dependências. Esse scanner não vem habilitado em todos os comandos por padrão e precisa ser solicitado quando fizer parte da política do projeto.

SBOM

Uma Software Bill of Materials é um inventário dos componentes de software. O Trivy gera documentos CycloneDX ou SPDX e também consegue receber um SBOM como alvo para procurar vulnerabilidades.

Instalando no Ubuntu

Primeiro instale as ferramentas usadas para adicionar o repositório:

code
sudo apt update
sudo apt install -y wget gnupg

Importe a chave oficial:

code
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null

Adicione o repositório:

code
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" \
  | sudo tee /etc/apt/sources.list.d/trivy.list

Atualize o índice e instale:

code
sudo apt update
sudo apt install -y trivy

Confirme:

code
trivy --version

Como o repositório ficou cadastrado no APT, atualizações futuras entram no fluxo normal do Ubuntu:

code
sudo apt update
sudo apt upgrade

Primeira análise de uma imagem

Não é necessário baixar uma imagem manualmente. O Trivy procura primeiro nos engines locais e, se necessário, consulta o registry:

code
trivy image node:22-alpine

Na primeira execução ele baixa a base de vulnerabilidades, então demora mais. As execuções seguintes aproveitam o cache.

Para mostrar apenas riscos mais altos:

code
trivy image \
  --severity HIGH,CRITICAL \
  node:22-alpine

Para ocultar vulnerabilidades que ainda não possuem correção publicada:

code
trivy image \
  --ignore-unfixed \
  --severity HIGH,CRITICAL \
  node:22-alpine

Uso --ignore-unfixed com cuidado. Ele reduz o ruído operacional, mas também esconde riscos que continuam existindo. Em relatórios de segurança, pode ser melhor manter esses itens visíveis.

Analisando uma imagem própria

Depois de construir a aplicação:

code
docker build -t minha-api:local .
trivy image minha-api:local

O relatório costuma separar pacotes do sistema e bibliotecas da aplicação. Isso ajuda a descobrir se o problema está na imagem base, em um pacote instalado com apt ou em uma dependência do projeto.

Quando a vulnerabilidade está na base, o primeiro teste é reconstruir com uma tag atualizada. Quando está na aplicação, atualizo a dependência e executo os testes antes de gerar outra imagem.

Analisando o projeto no disco

Na raiz de um repositório:

code
trivy fs .

Para declarar exatamente os scanners desejados:

code
trivy fs \
  --scanners vuln,secret,misconfig \
  .

O Trivy percorre o diretório em busca de manifestos, lockfiles, arquivos de configuração e possíveis secrets. Evite apontá-lo sem necessidade para uma pasta enorme como todo o diretório pessoal.

Pastas que não fazem parte do resultado podem ser ignoradas:

code
trivy fs \
  --skip-dirs node_modules \
  --skip-dirs .git \
  .

Verificando infraestrutura como código

Para analisar somente configurações:

code
trivy fs --scanners misconfig .

Podemos limitar o alvo a uma pasta:

code
trivy fs --scanners misconfig ./infra

Cada achado inclui a regra, severidade, arquivo, trecho e uma explicação. Antes de ignorar uma regra, verifico se o contexto realmente possui outra proteção equivalente.

Procurando secrets

Para executar apenas o scanner de secrets:

code
trivy fs --scanners secret .

Se um secret real aparecer, apagar a linha não é suficiente. Uma credencial que entrou no Git deve ser considerada exposta:

  1. revogue ou rotacione a credencial;
  2. remova o valor do código e do histórico quando necessário;
  3. coloque o novo valor em um gerenciador de secrets;
  4. revise logs e uso da credencial antiga.

Uma allowlist só deve ser usada para um falso positivo conhecido, nunca para silenciar uma chave válida.

Gerando uma SBOM

Para gerar CycloneDX a partir de uma imagem:

code
trivy image \
  --format cyclonedx \
  --output sbom.cdx.json \
  minha-api:local

Para um projeto no sistema de arquivos:

code
trivy fs \
  --format spdx-json \
  --output sbom.spdx.json \
  .

Depois, o próprio documento pode ser analisado:

code
trivy sbom sbom.spdx.json

O SBOM é um inventário, não uma prova de segurança. Seu valor aparece quando ele é atualizado, armazenado e usado para responder rapidamente a novas vulnerabilidades.

Salvando resultados

Para consumo humano, a tabela padrão funciona bem. Para automação, prefiro JSON ou SARIF:

code
trivy image \
  --format json \
  --output trivy-results.json \
  minha-api:local

SARIF pode ser importado por plataformas de código e ferramentas de segurança:

code
trivy fs \
  --format sarif \
  --output trivy-results.sarif \
  .

Fazendo o CI falhar

Por padrão, encontrar vulnerabilidades não precisa encerrar o comando com erro. Para bloquear riscos altos e críticos:

code
trivy image \
  --exit-code 1 \
  --severity HIGH,CRITICAL \
  minha-api:local

Em uma pipeline, costumo seguir esta ordem:

code
instalar dependências e testar
construir a imagem
analisar filesystem e configurações
analisar a imagem final
publicar relatórios
enviar a imagem ao registry

Escanear antes do push evita publicar uma imagem que a própria política já reprovaria.

O que priorizar no relatório

Se o resultado for grande, começo por:

  1. secrets válidos;
  2. vulnerabilidades críticas exploráveis e com correção;
  3. vulnerabilidades altas no caminho exposto da aplicação;
  4. configurações que aumentam privilégio ou exposição;
  5. atualização da imagem base e dependências diretas.

Severidade é importante, mas contexto também. Um pacote vulnerável pode nem ser carregado; outro problema médio pode estar diretamente acessível pela internet.

Fechamento

Trivy entrega valor rápido porque analisa vários pontos da cadeia com uma única CLI. Ele é simples o bastante para uso local e estruturado o bastante para participar da pipeline.

O objetivo não deve ser produzir um relatório sem itens, mas criar um ciclo confiável: detectar, entender, corrigir, registrar exceções justificadas e analisar novamente. Quando a execução vira rotina, novas vulnerabilidades deixam de aparecer apenas perto do deploy.

Referências