Befunde im Repository akzeptieren

Es gibt zwei Wege, einen Scanner-Befund zu akzeptieren: im Repository, mit einer Trivy-Ignore-Datei, die mit dem Code mitwandert, oder über die API, mit einer Verwerfung. Diese Seite behandelt den ersten Weg.

Im Repository passt besser, wenn die Akzeptanz eine Eigenschaft des Codes ist: eine verwundbare Bibliothek, die in einem Tool mitgeliefert wird, das du nicht patchen kannst, oder ein Container, der absichtlich als root läuft. Die Begründung steht direkt neben dem, was sie beschreibt, und sie gilt ab dem Merge für jeden Scan.

Die eine Regel, über die viele stolpern

Enthält dein Repository eine .trivyignore.yaml, wird die einfache .trivyignore vollständig ignoriert.

Nicht zusammengeführt, nicht als Rückfallebene herangezogen: ignoriert. Kein Eintrag darin unterdrückt dann noch etwas.

Das liegt daran, dass unsere Scanner Trivy mit --ignorefile auf die strukturierte Datei verweisen, und dieses Flag ersetzt die automatische Erkennung der einfachen Datei durch Trivy, statt sie zu ergänzen. Das ist Trivy-Verhalten, keine Richtlinie von fremforge, und es wird leicht übersehen, weil eine einfache .trivyignore in deinem Repository so aussieht, als würde sie etwas bewirken.

Entscheide dich also für eine Datei und verwende nur diese. Wenn du etwas brauchst, das die einfache Form nicht ausdrücken kann, verschiebe alle deine Einträge gleichzeitig in die YAML-Datei.

Eine Akzeptanz gilt, sobald sie auf dem Basis-Branch ist

Ein Pull Request wird mit den Ignore-Dateien des Branches gescannt, in den er gemergt wird, nicht mit seinen eigenen. Ein PR, der einen Befund einführt und ihn im selben Diff akzeptiert, bleibt also rot: Die neue Akzeptanz wird erst gelesen, wenn sie gemergt ist.

Um einen Befund zu akzeptieren, merge zuerst die Akzeptanz für sich allein und danach die Änderung, die sie abdeckt. Der PR, der nur die Akzeptanz enthält, scannt sauber, denn für sich allein fügt er nichts hinzu, was gefunden werden könnte.

Das gilt für jede Datei, die unsere Scanner sonst aus deinem Branch lesen würden: .trivyignore, .trivyignore.yaml und trivy.yaml (Trivy), .semgrepignore (SAST), .gitleaksignore (Secret-Scanning) und osv-scanner.toml in jedem Verzeichnis (Abhängigkeits-Scanning).

Änderungen, die einen Scan nur strenger machen können, gelten bereits im PR selbst:

• das Löschen einer Ignore-Datei;
• das Entfernen von Einträgen aus .trivyignore oder .gitleaksignore. Der PR wird mit den Einträgen des Basis-Branches gescannt, abzüglich der von ihm entfernten. Wird das exp:-Datum eines Eintrags verlängert, zählt das als neuer Eintrag und gilt daher erst nach dem Merge.

Jede andere Bearbeitung einer Ignore-Datei, etwa das Eingrenzen einer .trivyignore.yaml oder .semgrepignore, gilt nach dem Merge. Bis dahin wird der PR mit der Version des Basis-Branches gescannt.

Geplante erneute Scans deines Standard-Branches verwenden immer die Ignore-Dateien auf diesem Branch.

Welche Form du wählst

Beide Formen akzeptieren dieselben Kennungen: CVE-IDs, GHSA-IDs und Kennungen für Fehlkonfigurationen wie DS-0002. Der Unterschied liegt darin, was du über einen Eintrag aussagen kannst.

Verwende die einfache Form für eine kurze Liste. Verwende die YAML-Datei, wenn du eine Akzeptanz auf einen mitgelieferten Pfad eingrenzen musst oder die Begründung als Daten statt als Kommentar führen willst.

Einfache Form

# grpc is statically linked into the pulumi binary and only speaks over
# localhost, so this server-side advisory is not reachable in CLI use.
GHSA-hrxh-6v49-42gf exp:2026-08-30

Strukturierte Form

vulnerabilities:
  - id: GHSA-hrxh-6v49-42gf
    expired_at: 2026-08-30
    paths:
      - usr/local/bin/pulumi
    statement: >-
      grpc is statically linked into the pulumi binary as its engine<->plugin
      transport and only speaks over localhost, so this server-side advisory is
      not reachable in CLI use. Fixed in grpc 1.82.1; drop this when pulumi
      ships it.

misconfigurations:
  - id: DS-0002
    expired_at: 2027-01-23
    statement: >-
      CI runner base image; it must run as root to drive the container runtime.

Die Abschnitte auf oberster Ebene sind vulnerabilities, misconfigurations, secrets und licenses.

Setze immer ein Ablaufdatum

Eine Akzeptanz ohne Datum ist aus Versehen dauerhaft. Die mitgelieferte Bibliothek wird gepatcht, die verwundbare Datei verschwindet aus dem Image, und der Eintrag bleibt stehen und unterdrückt alles, was später dieselbe ID trägt.

Beide Formen unterstützen ein Ablaufdatum, und Trivy setzt es selbst durch: Sobald das Datum verstrichen ist, kommt der Befund zurück. Aus „Das sollten wir irgendwann noch einmal prüfen" wird so ein konkreter Tag, an dem die Prüfung dich fragt.

Wähle ein Datum, an dem du wirklich noch einmal nachprüfen würdest: das nächste Release des Upstream-Tools oder ein Quartal später.

Wann du stattdessen über die API verwirfst

Greife zu einer Verwerfung statt zu einer Ignore-Datei, wenn:

• der Befund veraltet ist: Du hast ihn an der Quelle bereits behoben und willst nur die Zeile loswerden. Meist brauchst du nicht einmal das; die stündliche automatische Auflösung erledigt das, sobald ein neuerer Scan läuft.
• die Akzeptanz die aktuelle Situation dieses Repositorys betrifft und nicht den Code, etwa ein Befund auf einem Branch, der inzwischen gemergt ist.
• du die Begründung im Audit-Log haben willst. Verwerfungen werden mit wer und warum erfasst; eine Ignore-Datei steht stattdessen in der Git-Historie.

Eine Ignore-Datei ist die dauerhafte Wahl, eine Verwerfung die zeitpunktbezogene.

Prüfen, ob es funktioniert hat

Führe den Scan erneut aus und prüfe, ob der Befund verschwunden ist; siehe Scans erneut ausführen. Scheint der Eintrag keine Wirkung zu haben, prüfe zuerst die Regel oben auf dieser Seite: Eine .trivyignore.yaml im Wurzelverzeichnis des Repositorys schaltet die einfache Datei vollständig ab.

Siehe auch

• Befund-API: Befunde über REST lesen und verwerfen.
• Image-Scanning: was einen Merge blockiert, und der Schwellenwert für den Schweregrad.
• Lizenz-Scanning: Richtlinienkategorien und Allowlisting.