Traduisez vos fichiers d’ignore de vulnérabilités en un clic.

C’est un outil gratuit, exécuté dans le navigateur, qui traduit une politique de suppression de vulnérabilités entre les quatre formats de scanner courants : Trivy (.trivyignore), Grype (.grype.yaml), Snyk (.snyk) et osv-scanner (osv-scanner.toml). Collez un fichier d’ignore, choisissez un format cible et obtenez le fichier équivalent — ainsi, une suppression décidée une seule fois n’a pas à être ressaisie pour chaque scanner.

Non. Le convertisseur s’exécute à 100 % côté client. Votre fichier d’ignore est analysé puis réémis à l’intérieur de l’onglet de votre navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez coller en toute sécurité des politiques de CVE internes et les commentaires qui les justifient.

Les quatre directions sont prises en charge : .trivyignore (Trivy), .grype.yaml (Grype), .snyk (politique Snyk) et osv-scanner.toml (osv-scanner). N’importe quel format source peut être traduit vers n’importe quel format cible, si bien qu’il fait aussi office d’unificateur lorsque vous adoptez un nouveau scanner.

Collez le contenu .trivyignore et sélectionnez .snyk comme format cible. Le convertisseur fait correspondre chaque identifiant de vulnérabilité à un bloc d’ignore YAML Snyk indexé par identifiant d’issue, en utilisant une portée de chemin avec joker, et reporte tout commentaire de ligne dans le champ reason. La conversion s’exécute entièrement dans votre navigateur, sans rien envoyer.

Oui. Les matchers d’ignore structurés de Grype — identifiant de vulnérabilité, nom de paquet facultatif et portée de version — sont réduits à une liste plate d’identifiants au format .trivyignore. Comme .trivyignore ne dispose d’aucune portée de paquet ou de version exploitable par une machine, ces champs ne peuvent pas être représentés dans la cible ; le convertisseur les signale par des avertissements plutôt que de les abandonner silencieusement.

Maintenez un seul fichier d’ignore source et utilisez le convertisseur pour le traduire dans chaque format de scanner que vous exécutez. Cela évite le problème de politique fragmentée, où la même décision de risque accepté doit être réexprimée séparément pour Trivy, Grype, Snyk et osv-scanner, et empêche la dérive où une CVE est supprimée dans un outil mais toujours active dans un autre.

C’est un fichier TOML contenant un tableau de tables [[IgnoredVulns]]. Chaque table comporte un champ id (par exemple CVE-2023-12345, GHSA-xxxx-yyyy-zzzz, RUSTSEC-2023-0001), une date d’expiration ignoreUntil facultative au format RFC3339, et une chaîne reason facultative. Le convertisseur lit et écrit ce format aux côtés de Trivy, Grype et Snyk.

Les formats ne transportent pas les mêmes métadonnées. Le .trivyignore de Trivy est une liste d’identifiants avec des commentaires facultatifs ; le .snyk de Snyk est une politique YAML avec une portée par chemin et des dates d’expiration ; le .grype.yaml de Grype et l’osv-scanner.toml se situent entre les deux. Les champs sans équivalent dans la cible — dates d’expiration, portée de paquet ou de chemin, métadonnées de raison — sont signalés par des avertissements plutôt qu’abandonnés silencieusement, afin que vous sachiez toujours ce qui n’a pas été transposé.

Partout où le format cible le prend en charge. Trivy et Snyk transportent tous deux des raisons lisibles par un humain (Trivy sous forme de commentaires de ligne, Snyk via un champ reason dédié), de sorte que les justifications survivent à ces conversions. Lorsqu’un format cible n’a nulle part où stocker la raison, le convertisseur la conserve sous forme de commentaire lorsque c’est possible et émet un avertissement lorsqu’il ne le peut pas.

Non. Il s’agit d’un outil communautaire indépendant, qui n’est ni affilié ni approuvé par Aqua Security (Trivy), Anchore (Grype), Snyk ou Google (osv-scanner). Les noms des éditeurs et des formats ne sont utilisés que pour décrire ce que l’outil lit et écrit.