Un CVE, quatre fichiers d’exclusion : unifier Trivy, Grype, Snyk et osv-scanner

Vous avez trié le CVE. Un scanner a signalé CVE-2023-45853 dans zlib, vous avez lu l’avis de sécurité, confirmé que le chemin de code vulnérable n’est pas atteignable depuis votre image, et pris la décision : le supprimer, avec une justification et une date de réexamen. Une seule décision.

Maintenant, encodez cette décision unique quatre fois.

Si votre pipeline exécute plus d’un scanner — et c’est le cas de beaucoup, parce que Trivy, Grype, Snyk et osv-scanner détectent chacun des choses que les autres ratent — chaque suppression de risque accepté doit être inscrite dans le fichier d’exclusion de chaque outil. Même CVE, même justification, quatre fichiers différents avec quatre schémas différents, quatre ensembles de capacités différents. Faites-en une de travers et ce scanner continuera de faire échouer le build (ou pire, cessera silencieusement de signaler quelque chose que vous n’avez jamais eu l’intention d’ignorer).

La même suppression, de quatre façons

Section 1 of 4 · ~1 min

Voici la version la plus simple de cette décision — « ignorer CVE-2023-45853 » — dans chaque format.

.trivyignore est une liste plate délimitée par des sauts de ligne. Un identifiant par ligne, # pour les commentaires :

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

.grype.yaml utilise un tableau ignore structuré de règles de correspondance. Vous pouvez définir la portée par identifiant de vulnérabilité et, en option, par paquet :

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

.snyk est le fichier de politique de Snyk : une table YAML indexée par identifiant de problème, où chaque entrée est une liste d’objets délimités par chemin portant reason et expires comme champs de premier ordre :

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 utilise un tableau de tables TOML [[IgnoredVulns]], avec id, reason et un ignoreUntil au format RFC 3339 :

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

Quatre fichiers. L’identifiant du CVE est la seule chose qui survit à l’identique dans tous.

Ce qui se transpose proprement

Section 2 of 4 · ~1 min

Une poignée de concepts sont réellement portables, et un convertisseur peut les déplacer sans perte :

• L’identifiant. Un identifiant CVE-… est un identifiant CVE-… partout. La seule subtilité : osv-scanner préfère les identifiants OSV (GHSA-…, PYSEC-…) mais accepte les CVE et résout les alias, tandis que les autres privilégient les CVE. La plupart du temps, l’identifiant se recopie tel quel.
• Une chaîne de justification. Grype, Snyk et osv-scanner ont tous un endroit où indiquer le « pourquoi ». Historiquement, ce n’était pas le cas de Trivy — dans un .trivyignore brut, le seul foyer pour une justification est un commentaire # sur la ligne au-dessus, qu’aucun outil n’analyse mais que tout relecteur lit.
• L’expiration, dans l’esprit. Le champ expires de Snyk et le ignoreUntil d’osv-scanner sont tous deux des horodatages réels et appliqués : une fois la date passée, la suppression devient caduque et la détection réapparaît. C’est la même idée, et elle se convertit directement de l’un à l’autre.

Ce qui se perd

Section 3 of 4 · ~2 min

La partie intéressante, c’est tout ce qui ne fait pas l’aller-retour. Un convertisseur doit être honnête à ce sujet plutôt que de les abandonner silencieusement.

L’expiration est asymétrique. Snyk et osv-scanner appliquent une date. Le .trivyignore simple n’a aucun champ d’expiration — une suppression y reste valable pour toujours jusqu’à ce que quelqu’un supprime la ligne. (Le fichier d’exclusion YAML plus récent de Trivy prend en charge un statement et une correspondance plus riche, mais le .trivyignore classique que la plupart des dépôts utilisent encore ne le fait pas.) Convertissez une exclusion Snyk assortie d’une expiration vers .trivyignore et cette expiration ne peut survivre que sous forme de commentaire — une note destinée à un humain, et non une règle que le scanner applique. C’est une perte de sécurité réelle, et elle devrait être signalée, et non dissimulée.

La portée par paquet varie. Grype vous laisse épingler package.name et package.version, de sorte que la suppression ne s’applique qu’à cette dépendance exacte. .trivyignore (classique) s’indexe purement sur l’identifiant de vulnérabilité — il ignore ce CVE partout où il apparaît dans l’analyse, ce qui est plus large que vous ne l’aviez peut-être prévu. Réduire une règle Grype vers .trivyignore élargit le rayon d’impact ; vous ne pouvez pas exprimer « seulement ce paquet » dans une liste plate d’identifiants.

La portée par chemin est surtout une idée propre à Snyk. Les entrées ignore de Snyk sont des listes indexées par chemin — le "*" ci-dessus signifie « partout », mais Snyk peut aussi limiter la portée d’une suppression à un chemin de dépendance spécifique afin qu’elle s’applique à un endroit et pas à un autre. Ni Trivy, ni Grype, ni osv-scanner ne modélisent ainsi la portée au niveau du chemin, de sorte qu’une exclusion Snyk délimitée par chemin s’aplatit en « ce CVE, à l’échelle du projet » dans les autres. L’intention (« seulement sur ce chemin transitif ») disparaît.

La justification n’a aucun emplacement natif où atterrir dans le Trivy classique. Comme ci-dessus — convertir vers .trivyignore rétrograde une justification de premier ordre en commentaire. En convertissant à partir de ce fichier, il n’y a généralement aucune justification lisible par machine à récupérer, seulement ce qu’un humain a laissé dans une ligne #.

Le motif commun à tous ces cas : convertir vers un format plus expressif est sûr, et convertir vers un format plus plat élargit discrètement la portée et abandonne des métadonnées. La seule façon responsable d’effectuer la conversion vers le format plat est de mettre en évidence exactement ce qui a été perdu, afin qu’un humain puisse décider si la suppression élargie est acceptable.

Faites-le une fois, produisez-en quatre

Section 4 of 4 · ~1 min

Maintenir à la main quatre fichiers d’exclusion synchronisés est exactement le genre de tenue de registre répétitive et sujette aux erreurs qui devrait être mécanique. Décrivez une suppression une seule fois — identifiant, justification, expiration, portée par paquet et par chemin — et laissez un outil produire la forme correcte pour chaque scanner, avec des avertissements explicites partout où un format cible ne peut pas contenir un champ.

C’est ce que fait le CVE-Ignore Converter : collez n’importe lequel des fichiers .trivyignore, .grype.yaml, .snyk ou osv-scanner.toml, récupérez les trois autres, et voyez précisément quelles parties ont été perdues lors de l’aller-retour. Il s’exécute entièrement dans votre navigateur — votre politique de suppression ne quitte jamais la page.

Essayez le CVE-Ignore Converter →