Ein CVE, vier Ignore-Dateien: Trivy, Grype, Snyk und osv-scanner vereinheitlichen

Sie haben das CVE triagiert. Ein Scanner hat CVE-2023-45853 in zlib markiert, Sie haben das Advisory gelesen, bestätigt, dass der verwundbare Codepfad aus Ihrem Image nicht erreichbar ist, und die Entscheidung getroffen: unterdrücken, mit einer Begründung und einem Überprüfungsdatum. Eine Entscheidung.

Kodieren Sie diese eine Entscheidung nun viermal.

Wenn Ihre Pipeline mehr als einen Scanner ausführt — und das tun viele, denn Trivy, Grype, Snyk und osv-scanner finden jeweils Dinge, die die anderen übersehen — muss jede Unterdrückung eines akzeptierten Risikos in die Ignore-Datei jedes Tools geschrieben werden. Dasselbe CVE, dieselbe Begründung, vier verschiedene Dateien mit vier verschiedenen Schemata, vier verschiedenen Fähigkeiten. Machen Sie eine davon falsch, lässt dieser Scanner den Build weiterhin fehlschlagen (oder schlimmer: er hört stillschweigend auf, bei etwas fehlzuschlagen, das Sie nie ignorieren wollten).

Dieselbe Unterdrückung, auf vier Arten

Section 1 of 4 · ~1 min

Hier ist die einfachste Version dieser Entscheidung — „CVE-2023-45853 ignorieren” — in jedem Format.

.trivyignore ist eine flache, durch Zeilenumbrüche getrennte Liste. Eine ID pro Zeile, # für Kommentare:

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

.grype.yaml verwendet ein strukturiertes ignore-Array aus Match-Regeln. Sie können nach Schwachstellen-ID und optional nach Paket eingrenzen:

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

.snyk ist Snyks Policy-Datei: eine YAML-Map mit dem Issue-Schlüssel als Key, wobei jeder Eintrag eine Liste pfadbezogener Objekte ist, die reason und expires als erstklassige Felder tragen:

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 verwendet ein TOML-[[IgnoredVulns]]-Array aus Tabellen, mit id, reason und einem ignoreUntil im Format RFC 3339:

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

Vier Dateien. Die CVE-ID ist das Einzige, was über alle hinweg wortgetreu erhalten bleibt.

Was sich sauber abbilden lässt

Section 2 of 4 · ~1 min

Eine Handvoll Konzepte ist wirklich portabel, und ein Konverter kann sie ohne Verlust übertragen:

• Der Bezeichner. Eine CVE-…-ID ist überall eine CVE-…-ID. Der eine Haken: osv-scanner ist am zufriedensten mit OSV-IDs (GHSA-…, PYSEC-…), akzeptiert aber CVEs und löst Aliase auf, während die anderen CVE-zuerst arbeiten. Meistens ist die ID eine saubere Kopie.
• Eine Begründungs-Zeichenkette. Grype, Snyk und osv-scanner haben alle einen Ort für das „Warum”. Trivy hatte das historisch nicht — in einer reinen .trivyignore ist der einzige Platz für eine Begründung ein #-Kommentar in der Zeile darüber, den kein Tool parst, aber jeder Prüfer liest.
• Ablauf, dem Sinne nach. Snyks expires und osv-scanners ignoreUntil sind beide echte, erzwungene Zeitstempel: Sobald das Datum verstrichen ist, verfällt die Unterdrückung und der Fund kommt zurück. Das ist dieselbe Idee, und sie lässt sich direkt zwischen den beiden konvertieren.

Was verlustbehaftet ist

Section 3 of 4 · ~2 min

Der interessante Teil ist alles, was nicht verlustfrei hin und zurück übersetzt werden kann. Ein Konverter muss bei diesen Dingen ehrlich sein, statt sie stillschweigend zu verwerfen.

Ablauf ist asymmetrisch. Snyk und osv-scanner erzwingen ein Datum. Die einfache .trivyignore hat überhaupt kein Ablauffeld — eine Unterdrückung darin gilt für immer, bis jemand die Zeile löscht. (Trivys neuere YAML-Ignore-Datei unterstützt ein statement und reicheres Matching, aber die klassische .trivyignore, die die meisten Repos noch verwenden, tut das nicht.) Konvertieren Sie ein Snyk-Ignore mit Ablauf in .trivyignore, kann dieser Ablauf nur als Kommentar überleben — ein Hinweis für einen Menschen, keine Regel, die der Scanner erzwingt. Das ist ein echter Verlust an Sicherheit, und er sollte gekennzeichnet, nicht versteckt werden.

Paket-Geltungsbereich variiert. Grype lässt Sie package.name und package.version festlegen, sodass die Unterdrückung nur für genau diese Abhängigkeit gilt. .trivyignore (klassisch) verwendet rein die Schwachstellen-ID als Schlüssel — sie ignoriert dieses CVE überall dort, wo es im Scan auftaucht, was breiter ist, als Sie vielleicht beabsichtigt haben. Eine Grype-Regel auf .trivyignore herunterzubrechen vergrößert den Wirkungsradius; „nur dieses Paket” lässt sich in einer flachen ID-Liste nicht ausdrücken.

Pfad-Geltungsbereich ist überwiegend eine Snyk-Idee. Snyks ignore-Einträge sind Listen mit dem Pfad als Schlüssel — das "*" oben bedeutet „überall”, aber Snyk kann eine Unterdrückung auch auf einen bestimmten Abhängigkeitspfad eingrenzen, sodass sie an einer Stelle gilt und an einer anderen nicht. Weder Trivy, noch Grype, noch osv-scanner modellieren einen Geltungsbereich auf Pfadebene auf diese Weise, sodass ein pfadbezogenes Snyk-Ignore in den anderen auf „dieses CVE, projektweit” zusammenfällt. Die Absicht („nur auf diesem transitiven Pfad”) ist verloren.

Begründung hat in klassischem Trivy keinen nativen Landeplatz. Wie oben — die Konvertierung in .trivyignore degradiert eine erstklassige Begründung zu einem Kommentar. Bei der Konvertierung aus ihr heraus gibt es meist überhaupt keine maschinenlesbare Begründung zurückzugewinnen, sondern nur, was ein Mensch in einer #-Zeile hinterlassen hat.

Das Muster über all dies hinweg: Die Konvertierung hin zu einem ausdrucksstärkeren Format ist sicher, und die Konvertierung hin zu einem flacheren erweitert stillschweigend den Geltungsbereich und verwirft Metadaten. Der einzig verantwortungsvolle Weg, die flache Konvertierung durchzuführen, besteht darin, genau das offenzulegen, was verloren ging, damit ein Mensch entscheiden kann, ob die breitere Unterdrückung akzeptabel ist.

Einmal machen, viermal ausgeben

Section 4 of 4 · ~1 min

Vier handgeschriebene Ignore-Dateien im Gleichschritt zu pflegen ist genau die Art von repetitiver, fehleranfälliger Buchhaltung, die mechanisch ablaufen sollte. Beschreiben Sie eine Unterdrückung einmal — ID, Begründung, Ablauf, Paket- und Pfad-Geltungsbereich — und lassen Sie ein Tool die korrekte Form für jeden Scanner ausgeben, mit expliziten Warnungen überall dort, wo ein Zielformat ein Feld nicht aufnehmen kann.

Genau das tut der CVE-Ignore Converter: Fügen Sie eine beliebige von .trivyignore, .grype.yaml, .snyk oder osv-scanner.toml ein, erhalten Sie die anderen drei zurück und sehen genau, welche Teile beim Hin- und Zurückkonvertieren verlustbehaftet waren. Er läuft vollständig in Ihrem Browser — Ihre Unterdrückungs-Policy verlässt die Seite nie.

CVE-Ignore Converter ausprobieren →