Acceptera fynd i repot

Det finns två sätt att acceptera ett fynd från en skanner: i repot, med en Trivy-ignore-fil som följer med koden, eller via API:t, med ett avfärdande. Den här sidan handlar om det första.

I repot passar bäst när accepterandet är en egenskap hos koden: ett sårbart bibliotek som ingår i ett verktyg du inte kan patcha, en container som medvetet körs som root. Motiveringen står bredvid det den beskriver, och den gäller för varje skanning från det ögonblick den mergas.

Den enda regeln som brukar ställa till det

Om ditt repo innehåller .trivyignore.yaml ignoreras den vanliga .trivyignore helt.

Den slås inte ihop och används inte som reserv, den ignoreras. Ingen post i den undertrycker längre något.

Det beror på att våra skannrar pekar Trivy på den strukturerade filen med --ignorefile, och den flaggan ersätter Trivys automatiska upptäckt av den vanliga filen i stället för att lägga till den. Det är Trivys beteende, inte en fremforge-policy, och det är lätt att missa eftersom en vanlig .trivyignore i repot ser ut att göra något.

Välj alltså en fil och använd bara den. Om du behöver något som den vanliga formen inte kan uttrycka, flytta alla dina poster till YAML-filen på en gång.

Ett accepterande gäller när det finns på basbranchen

En pull request skannas med ignore-filerna från den branch den mergas in i, inte med sina egna. En pull request som både introducerar ett fynd och accepterar det i samma diff är alltså fortfarande röd: det nya accepterandet läses inte förrän det har mergats.

För att acceptera ett fynd landar du först accepterandet för sig, och sedan ändringen som det täcker. Pull requesten med bara accepterandet skannas utan fynd, eftersom den för sig själv inte tillför något att hitta.

Det gäller varje fil som våra skannrar annars skulle läsa från din branch: .trivyignore, .trivyignore.yaml och trivy.yaml (Trivy), .semgrepignore (SAST), .gitleaksignore (hemlighetsskanning) och osv-scanner.toml i valfri katalog (beroendeskanning).

Ändringar som bara kan göra en skanning strängare gäller direkt i pull requesten:

• att ta bort en ignore-fil;
• att ta bort poster ur .trivyignore eller .gitleaksignore. Pull requesten skannas med basbranchens poster minus de som den tog bort. Att förlänga en posts exp:-datum räknas som en ny post, så det gäller efter merge.

Alla andra ändringar i en ignore-fil, till exempel att snäva in en .trivyignore.yaml eller .semgrepignore, gäller efter merge. Fram till dess skannas pull requesten med basbranchens version.

Schemalagda omskanningar av standardbranchen använder alltid ignore-filerna på den branchen.

Vilken form du ska välja

Båda formerna accepterar samma identifierare: CVE-id:n, GHSA-id:n och id:n för felkonfigurationer som DS-0002. Skillnaden är vad du kan säga om en post.

Använd den vanliga formen för en kort lista. Använd YAML när du behöver avgränsa ett accepterande till en enda inkluderad sökväg, eller när du vill att motiveringen ska följa med som data i stället för som en kommentar.

Vanlig 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

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

Avsnitten på översta nivån är vulnerabilities, misconfigurations, secrets och licenses.

Ange alltid ett utgångsdatum

Ett accepterande utan datum blir permanent av misstag. Det inkluderade biblioteket patchas, den sårbara filen försvinner ur imagen, och posten blir kvar och undertrycker allt som senare får samma id.

Båda formerna stöder utgångsdatum, och Trivy tillämpar det själv: när datumet har passerat kommer fyndet tillbaka. Det gör “vi borde kontrollera det här någon gång” till en bestämd dag då spärren frågar dig.

Välj ett datum då du verkligen skulle kontrollera igen: nästa release av verktyget uppströms, eller ett kvartal framåt.

När du i stället ska avfärda via API:t

Använd ett avfärdande i stället för en ignore-fil när:

• fyndet är inaktuellt: du har redan åtgärdat det vid källan och vill bara få bort raden. Oftast behöver du inte ens det; den automatiska lösningen varje timme ersätter det när en nyare skanning körs.
• accepterandet gäller det här repots situation just nu, inte koden, till exempel ett fynd på en branch som sedan dess har mergats.
• du vill ha motiveringen i granskningsloggen. Avfärdanden registreras med vem och varför; en ignore-fil registreras i stället i Git-historiken.

En ignore-fil är det varaktiga valet; ett avfärdande är det som gäller vid en viss tidpunkt.

Kontrollera att det fungerade

Kör om skanningen och bekräfta att fyndet är borta, se köra om skanningar. Om posten inte verkar ha någon effekt, kontrollera först regeln högst upp på den här sidan: en .trivyignore.yaml någonstans i repots rot sätter den vanliga filen helt ur spel.

Se även

• Findings API: läs och avfärda fynd via REST.
• Image-skanning: vad som blockerar en merge, och tröskeln för allvarlighetsgrad.
• Licensskanning: policykategorier och tillåtelselistor.