Pular para o conteúdo

OpsCanopy 5 min de leitura

Um CVE, quatro arquivos de ignore: unificando Trivy, Grype, Snyk e osv-scanner

Uma única supressão de CVE já triada precisa ser recodificada em .trivyignore, .grype.yaml, .snyk e osv-scanner.toml — cada um com um formato diferente. Aqui está a mesma supressão nos quatro formatos, o que mapeia de forma limpa e o que é perdido.

  • security
  • vulnerability-management
  • devops

Compartilhar
Nesta página

Um CVE, quatro arquivos de ignore: unificando os formatos de supressão do Trivy, Grype, Snyk e osv-scanner

Você triou o CVE. Um scanner sinalizou CVE-2023-45853 no zlib, você leu o aviso de segurança, confirmou que o caminho de código vulnerável não é alcançável a partir da sua imagem e tomou a decisão: suprimir, com um motivo e uma data de revisão. Uma decisão.

Agora codifique essa única decisão quatro vezes.

Se o seu pipeline executa mais de um scanner — e muitos executam, porque Trivy, Grype, Snyk e osv-scanner cada um pega coisas que os outros deixam passar —, toda supressão de risco aceito precisa ser escrita no arquivo de ignore de cada ferramenta. Mesmo CVE, mesma justificativa, quatro arquivos diferentes com quatro schemas diferentes, quatro capacidades diferentes. Erre um e aquele scanner continuará falhando o build (ou, pior, silenciosamente deixará de falhar em algo que você nunca quis ignorar).

A mesma supressão, de quatro formas

Section 1 of 4 · ~1 min

Aqui está a versão mais simples dessa decisão — “ignorar CVE-2023-45853” — em cada formato.

.trivyignore é uma lista plana delimitada por quebras de linha. Um ID por linha, # para comentários:

# zlib MiniZip — not reachable from our build, re-review 2026-09-01
CVE-2023-45853

.grype.yaml usa um array ignore estruturado de regras de correspondência. Você pode delimitar o escopo pelo ID da vulnerabilidade e, opcionalmente, pelo pacote:

ignore:
  - vulnerability: CVE-2023-45853
    # zlib MiniZip — not reachable, re-review 2026-09-01
    package:
      name: zlib
      version: 1.2.13

.snyk é o arquivo de política do Snyk: um mapa YAML indexado pelo ID do problema, onde cada entrada é uma lista de objetos delimitados por caminho que carregam reason e expires como campos de primeira classe:

version: v1.25.0
ignore:
  CVE-2023-45853:
    - "*":
        reason: zlib MiniZip not reachable from our build
        expires: 2026-09-01T00:00:00.000Z

osv-scanner.toml usa um array de tabelas TOML [[IgnoredVulns]], com id, reason e um ignoreUntil no formato RFC 3339:

[[IgnoredVulns]]
id = "CVE-2023-45853"
ignoreUntil = 2026-09-01T00:00:00Z
reason = "zlib MiniZip not reachable from our build"

Quatro arquivos. O ID do CVE é a única coisa que sobrevive literalmente em todos eles.

Um único ID de CVE irradiando para os seus quatro formatos de arquivo de ignore para Trivy, Grype, Snyk e osv-scanner

O que mapeia de forma limpa

Section 2 of 4 · ~1 min

Um punhado de conceitos é genuinamente portável, e um conversor consegue movê-los sem perda:

  • O identificador. Um ID CVE-… é um ID CVE-… em qualquer lugar. A única ressalva: o osv-scanner fica mais à vontade com IDs OSV (GHSA-…, PYSEC-…), mas aceita CVEs e resolve aliases, enquanto os outros são CVE-first. Na maioria das vezes, o ID é uma cópia limpa.
  • Uma string de motivo. Grype, Snyk e osv-scanner todos têm algum lugar para colocar o “porquê”. O Trivy historicamente não tinha — em um .trivyignore puro, o único lar para uma justificativa é um comentário # na linha acima, que nenhuma ferramenta interpreta, mas todo revisor lê.
  • Expiração, em essência. O expires do Snyk e o ignoreUntil do osv-scanner são ambos timestamps reais e aplicados de fato: assim que a data passa, a supressão caduca e o achado volta. É a mesma ideia, e ela converte diretamente entre os dois.

O que é perdido

Section 3 of 4 · ~2 min

A parte interessante é tudo aquilo que não faz o caminho de ida e volta. Um conversor precisa ser honesto sobre isso, em vez de descartar silenciosamente.

A expiração é assimétrica. Snyk e osv-scanner aplicam uma data. O .trivyignore puro não tem campo de expiração algum — uma supressão ali é para sempre, até que alguém apague a linha. (O arquivo de ignore YAML mais novo do Trivy suporta um statement e correspondência mais rica, mas o .trivyignore clássico que a maioria dos repositórios ainda usa não suporta.) Converta um ignore do Snyk com uma expiração para .trivyignore e essa expiração só consegue sobreviver como um comentário — uma nota para um humano, não uma regra que o scanner aplica. Isso é uma perda real de segurança, e deveria ser sinalizado, não escondido.

O escopo de pacote varia. O Grype permite fixar package.name e package.version, de modo que a supressão se aplica apenas àquela dependência exata. O .trivyignore (clássico) indexa puramente pelo ID da vulnerabilidade — ele ignora aquele CVE em todos os lugares em que aparece no scan, o que é mais amplo do que você talvez pretendesse. Estreitar uma regra do Grype para .trivyignore amplia o raio de impacto; você não consegue expressar “apenas este pacote” em uma lista plana de IDs.

O escopo de caminho é majoritariamente uma ideia do Snyk. As entradas ignore do Snyk são listas indexadas por caminho — o "*" acima significa “em todos os lugares”, mas o Snyk também pode delimitar o escopo de uma supressão a um caminho de dependência específico, de modo que ela se aplique em um lugar e não em outro. Nenhum entre Trivy, Grype ou osv-scanner modela escopo em nível de caminho dessa forma, então um ignore do Snyk delimitado por caminho se achata para “este CVE, em todo o projeto” nos outros. A intenção (“apenas neste caminho transitivo”) se perde.

O motivo não tem lugar nativo onde pousar no Trivy clássico. Como acima — converter para .trivyignore rebaixa um motivo de primeira classe a um comentário. Convertendo a partir dele, normalmente não há motivo legível por máquina algum para recuperar, apenas o que quer que um humano tenha deixado em uma linha #.

O padrão em todos esses casos: converter na direção de um formato mais expressivo é seguro, e converter na direção de um mais plano silenciosamente amplia o escopo e descarta metadados. A única maneira responsável de fazer a conversão para o formato plano é expor exatamente o que foi perdido, para que um humano possa decidir se a supressão mais ampla é aceitável.

Faça uma vez, emita quatro

Section 4 of 4 · ~1 min

Manter quatro arquivos de ignore escritos à mão em sincronia é exatamente o tipo de escrituração repetitiva e propensa a erros que deveria ser mecânica. Descreva uma supressão uma vez — ID, motivo, expiração, escopo de pacote e de caminho — e deixe uma ferramenta emitir o formato correto para cada scanner, com avisos explícitos sempre que um formato de destino não conseguir reter um campo.

É isso que o CVE-Ignore Converter faz: cole qualquer um dentre .trivyignore, .grype.yaml, .snyk ou osv-scanner.toml, receba os outros três de volta e veja com precisão quais partes foram perdidas no ida e volta. Ele roda inteiramente no seu navegador — sua política de supressão nunca sai da página.

Experimente o CVE-Ignore Converter →