Accept af fund i repositoriet

Der er to måder at acceptere et fund fra en scanner på: i repositoriet, med en Trivy-ignore-fil, der følger koden, eller via API’et, med en afvisning. Denne side handler om den første.

Accept i repositoriet passer bedst, når accepten er en egenskab ved koden: et sårbart bibliotek, der er vendoret ind i et værktøj, du ikke kan patche, eller en container, der bevidst kører som root. Begrundelsen står ved siden af det, den handler om, og den gælder for alle scanninger fra det øjeblik, den er merget.

Den ene regel, folk falder over

Hvis dit repository indeholder .trivyignore.yaml, ignoreres den almindelige .trivyignore fuldstændigt.

Den flettes ikke ind og bruges heller ikke som reserve. Den ignoreres. Ingen af dens linjer undertrykker noget længere.

Det sker, fordi vores scannere peger Trivy på den strukturerede fil med --ignorefile, og det flag erstatter Trivys automatiske opdagelse af den almindelige fil i stedet for at supplere den. Det er Trivys adfærd, ikke en fremforge-politik, og det er let at overse, fordi en almindelig .trivyignore i dit repo ser ud til at gøre noget.

Vælg derfor én fil, og brug kun den. Har du brug for noget, den almindelige form ikke kan udtrykke, så flyt alle dine linjer til YAML-filen på én gang.

En accept gælder, når den ligger på base-branchen

En pull request scannes med ignore-filerne fra den branch, den merges ind i, ikke med sine egne. En PR, der både introducerer et fund og accepterer det i samme diff, er derfor stadig rød: den nye accept læses først, når den er merget.

Vil du acceptere et fund, så få accepten merget for sig selv først og derefter den ændring, den dækker. PR’en med kun accepten scanner rent, fordi den alene ikke tilføjer noget at finde.

Det gælder alle filer, vores scannere ellers ville læse fra din branch: .trivyignore, .trivyignore.yaml og trivy.yaml (Trivy), .semgrepignore (SAST), .gitleaksignore (hemmelighedsscanning) og osv-scanner.toml i enhver mappe (afhængighedsscanning).

Ændringer, der kun kan gøre en scanning strengere, gælder i selve PR’en:

• sletning af en ignore-fil;
• fjernelse af linjer fra .trivyignore eller .gitleaksignore. PR’en scannes med base-branchens linjer minus dem, den fjernede. At rykke datoen i en linjes exp: længere ud tæller som en ny linje og gælder derfor efter merge.

Alle andre ændringer af en ignore-fil, fx at indsnævre en .trivyignore.yaml eller .semgrepignore, gælder efter merge. Indtil da scannes PR’en med base-branchens version.

Planlagte genscanninger af din standardbranch bruger altid ignore-filerne på den branch.

Hvilken form du skal vælge

Begge former accepterer de samme id’er: CVE-id’er, GHSA-id’er og id’er for fejlkonfigurationer som DS-0002. Forskellen er, hvad du kan sige om en linje.

Brug den almindelige form til en kort liste. Brug YAML, når du vil afgrænse en accept til én vendoret sti, eller når begrundelsen skal følge med som data i stedet for som en kommentar.

Almindelig 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

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

Sektionerne på øverste niveau er vulnerabilities, misconfigurations, secrets og licenses.

Sæt altid en udløbsdato

En accept uden dato bliver permanent ved et uheld. Det vendorede bibliotek bliver patchet, den sårbare fil forsvinder fra imaget, men linjen bliver stående og undertrykker alt, der senere får samme id.

Begge former understøtter udløb, og Trivy håndhæver det selv: når datoen er passeret, kommer fundet tilbage. Så bliver “det bør vi tjekke igen en dag” til en bestemt dag, hvor gaten spørger dig.

Vælg en dato, hvor du reelt vil kontrollere det igen: den næste release af værktøjet opstrøms eller et kvartal frem.

Hvornår du hellere skal afvise via API’et

Brug en afvisning i stedet for en ignore-fil, når:

• fundet er forældet: du har allerede rettet det ved kilden og vil bare have rækken ryddet. Som regel behøver du ikke engang det. Den timevise automatiske lukning erstatter det, så snart en nyere scanning har kørt.
• accepten handler om repositoriets situation lige nu, ikke om koden, fx et fund på en branch, der siden er merget.
• du vil have begrundelsen i revisionsloggen. Afvisninger registreres med hvem og hvorfor; en ignore-fil registreres i stedet i Git-historikken.

En ignore-fil er det varige valg; en afvisning er valget for et bestemt tidspunkt.

Kontrollér, at det virkede

Kør scanningen igen, og bekræft, at fundet er væk. Se Kør scanninger igen. Ser linjen ikke ud til at have nogen effekt, så tjek først reglen øverst på denne side: en .trivyignore.yaml et sted i roden af repositoriet slår den almindelige fil helt fra.

Se også

• Findings-API: læs og afvis fund via REST.
• Image-scanning: hvad der blokerer en merge, og grænsen for alvorlighed.
• Licensscanning: politikkategorier og tilladelseslister.