Godta funn i repositoryet

Det finnes to måter å godta et funn fra en skanner på: i repositoryet, med en Trivy-ignore-fil som følger koden, eller via API-et, med en avvisning. Denne siden handler om den første.

Å godta i repositoryet passer best når godkjenningen er en egenskap ved koden – et sårbart bibliotek som er vendret inn i et verktøy du ikke kan patche, en container som kjører som root med vilje. Begrunnelsen står ved siden av det den beskriver, og den gjelder for hver skanning fra det øyeblikket den er merget.

Regelen som overrasker folk

Hvis repositoryet ditt inneholder .trivyignore.yaml, blir den enkle .trivyignore ignorert fullstendig.

Ikke slått sammen, ikke brukt som reserveløsning – ignorert. Ingen av oppføringene i den undertrykker noe lenger.

Dette skjer fordi skannerne våre peker Trivy mot den strukturerte filen med --ignorefile, og det flagget erstatter Trivys automatiske oppdagelse av den enkle filen i stedet for å komme i tillegg. Det er Trivys oppførsel, ikke en fremforge-policy, og det er lett å overse fordi en enkel .trivyignore i repositoryet ser ut som den gjør noe.

Velg derfor én fil og bruk bare den. Hvis du trenger noe den enkle formen ikke kan uttrykke, flytter du alle oppføringene til YAML-filen samtidig.

En godkjenning gjelder når den er på base-branchen

En pull request skannes med ignore-filene til branchen den merges inn i, ikke med sine egne. En PR som innfører et funn og godtar det i den samme diffen, er derfor fortsatt rød: den nye godkjenningen leses ikke før den er merget.

For å godta et funn lander du godkjenningen alene først, og deretter endringen den dekker. PR-en med bare godkjenningen skanner rent, fordi den alene ikke tilfører noe å finne.

Dette gjelder alle filer skannerne våre ellers ville lest fra branchen din: .trivyignore, .trivyignore.yaml og trivy.yaml (Trivy), .semgrepignore (SAST), .gitleaksignore (skanning etter secrets) og osv-scanner.toml i hvilken som helst mappe (avhengighetsskanning).

Endringer som bare kan gjøre en skanning strengere, gjelder i selve PR-en:

• å slette en ignore-fil;
• å fjerne oppføringer fra .trivyignore eller .gitleaksignore. PR-en skannes med base-branchens oppføringer minus dem den fjernet. Å forlenge exp:-datoen til en oppføring regnes som en ny oppføring, så den gjelder etter merge.

Alle andre endringer i en ignore-fil, for eksempel å snevre inn en .trivyignore.yaml eller .semgrepignore, gjelder etter merge. Inntil da skannes PR-en med base-branchens versjon.

Planlagte nye skanninger av standardbranchen bruker alltid ignore-filene på den branchen.

Hvilken form du bør velge

Begge formene godtar de samme identifikatorene – CVE-id-er, GHSA-id-er og id-er for feilkonfigurasjoner som DS-0002. Forskjellen er hva du kan si om en oppføring.

Bruk den enkle formen for en kort liste. Bruk YAML-filen når du må avgrense en godkjenning til én vendret sti, eller når du vil ha begrunnelsen som data i stedet for som en kommentar.

Enkel 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

Strukturert 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.

Seksjonene på øverste nivå er vulnerabilities, misconfigurations, secrets og licenses.

Angi alltid en utløpsdato

En godkjenning uten dato er permanent ved et uhell. Det vendrede biblioteket blir patchet, den sårbare filen forsvinner fra imaget – og oppføringen blir stående og undertrykker alt som senere får samme id.

Begge formene støtter utløp, og Trivy håndhever det selv: når datoen er passert, kommer funnet tilbake. Det gjør «vi burde sjekke dette igjen en gang» om til en bestemt dag der sperren spør deg.

Velg en dato du faktisk ville sjekket på nytt – neste utgivelse av upstream-verktøyet, eller et kvartal frem i tid.

Når du heller bør avvise via API-et

Velg en avvisning i stedet for en ignore-fil når:

• funnet er utdatert – du har allerede rettet det i kilden og vil bare fjerne raden. Vanligvis trenger du ikke engang dette; den automatiske løsningen hver time overtar så snart en nyere skanning kjører.
• godkjenningen handler om situasjonen i dette repositoryet akkurat nå, ikke om koden – for eksempel et funn på en branch som siden er merget.
• du vil ha begrunnelsen i revisjonsloggen. Avvisninger registreres med hvem og hvorfor; en ignore-fil registreres i stedet i Git-historikken.

En ignore-fil er det varige valget; en avvisning gjelder et bestemt tidspunkt.

Sjekke at det virket

Kjør skanningen på nytt og bekreft at funnet er borte – se kjøre skanninger på nytt. Hvis oppføringen ikke ser ut til å ha noen effekt, sjekker du først regelen øverst på denne siden: en .trivyignore.yaml hvor som helst i roten av repositoryet slår av den enkle filen helt.

Se også

• Findings-API – les og avvis funn via REST.
• Skanning av imager – hva som blokkerer en merge, og terskelen for alvorlighetsgrad.
• Lisensskanning – policykategorier og tillatelseslister.