Português (BR)
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
Nesta página
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
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.
O que mapeia de forma limpa
Um punhado de conceitos é genuinamente portável, e um conversor consegue movê-los sem perda:
- O identificador. Um ID
CVE-…é um IDCVE-…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
.trivyignorepuro, 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
expiresdo Snyk e oignoreUntildo 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
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
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.
Posts relacionados
-
8 min de leitura
Aprenda DevOps em 90 dias: o caminho gratuito e guiado por incidentes de desenvolvedor a engenheiro DevOps
Por que criamos o Mission: 90 Days DevOps — um caminho gratuito, dia a dia, do Linux ao Kubernetes com missões de incidente jogáveis. O plano completo, as decisões de design e os tradeoffs honestos.
-
6 min de leitura
Lendo expressões cron: um guia campo a campo
Um guia prático, campo a campo, para ler expressões cron — os cinco campos de tempo, intervalos, passos, listas e @macros — além das pegadinhas que fazem os agendamentos dispararem quando você menos espera.
-
7 min de leitura
Os erros de segurança no GitHub Actions que os linters não detectam
Validadores de YAML detectam sintaxe, não exposição. Aqui estão as cinco configurações incorretas de alto impacto do GitHub Actions — pull_request_target, injeção de script, actions sem pin, escopos amplos do GITHUB_TOKEN e curl|bash — com o padrão ruim e a correção para cada uma.