Bevindingen accepteren in de repository

Je kunt een bevinding van een scanner op twee manieren accepteren: in de repository, met een Trivy-ignore-bestand dat met de code meereist, of via de API, met een negering. Deze pagina gaat over de eerste manier.

Accepteren in de repository past beter wanneer de acceptatie een eigenschap van de code is: een kwetsbare bibliotheek die is meegeleverd in een tool die je niet kunt patchen, of een container die bewust als root draait. De reden staat dan naast wat ze beschrijft, en geldt voor elke scan vanaf het moment dat ze is samengevoegd.

De ene regel waar mensen over struikelen

Als je repository .trivyignore.yaml bevat, wordt de gewone .trivyignore volledig genegeerd.

Niet samengevoegd, niet als terugval geraadpleegd: genegeerd. Geen enkele regel erin onderdrukt dan nog iets.

Dat komt doordat onze scanners Trivy met --ignorefile naar het gestructureerde bestand wijzen, en die vlag vervangt de automatische detectie van het gewone bestand door Trivy in plaats van er iets aan toe te voegen. Dat is gedrag van Trivy, geen beleid van fremforge, en het is makkelijk over het hoofd te zien omdat een gewone .trivyignore in je repository eruitziet alsof hij iets doet.

Kies dus één bestand en gebruik alleen dat. Heb je iets nodig dat de gewone vorm niet kan uitdrukken, verplaats dan al je regels tegelijk naar het YAML-bestand.

Een acceptatie geldt zodra ze op de basisbranch staat

Een pull request wordt gescand met de ignore-bestanden van de branch waarin hij wordt samengevoegd, niet met zijn eigen. Een PR die in dezelfde diff een bevinding introduceert en accepteert, blijft dus rood: de nieuwe acceptatie wordt pas gelezen als ze is samengevoegd.

Wil je een bevinding accepteren, voeg dan eerst alleen de acceptatie samen en daarna de wijziging die ze dekt. De PR met alleen de acceptatie scant schoon, omdat hij op zichzelf niets toevoegt om te vinden.

Dat geldt voor elk bestand dat onze scanners anders van je branch zouden lezen: .trivyignore, .trivyignore.yaml en trivy.yaml (Trivy), .semgrepignore (SAST), .gitleaksignore (secret scanning) en osv-scanner.toml in elke map (afhankelijkheidsscan).

Wijzigingen die een scan alleen strenger kunnen maken, gelden wel al in de PR zelf:

• een ignore-bestand verwijderen;
• regels uit .trivyignore of .gitleaksignore verwijderen. De PR wordt gescand met de regels van de basisbranch min de regels die hij heeft verwijderd. Het verlengen van de exp:-datum van een regel telt als een nieuwe regel en geldt dus pas na het samenvoegen.

Elke andere wijziging aan een ignore-bestand, zoals het inperken van een .trivyignore.yaml of .semgrepignore, geldt na het samenvoegen. Tot dan wordt de PR gescand met de versie van de basisbranch.

Geplande herscans van je standaardbranch gebruiken altijd de ignore-bestanden op die branch.

Welke vorm je kiest

Beide vormen accepteren dezelfde identifiers: CVE-id’s, GHSA-id’s en id’s van misconfiguraties zoals DS-0002. Het verschil zit in wat je over een regel kunt zeggen.

Gebruik de gewone vorm voor een korte lijst. Gebruik het YAML-bestand wanneer je een acceptatie wilt beperken tot één meegeleverd pad, of wanneer je de onderbouwing als data wilt meenemen in plaats van als commentaar.

Gewone vorm

# 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

Gestructureerde vorm

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.

De secties op het hoogste niveau zijn vulnerabilities, misconfigurations, secrets en licenses.

Zet altijd een vervaldatum

Een acceptatie zonder datum is per ongeluk permanent. De meegeleverde bibliotheek wordt gepatcht, het kwetsbare bestand verdwijnt uit de image, en de regel blijft staan en onderdrukt alles wat later hetzelfde id krijgt.

Beide vormen ondersteunen een vervaldatum, en Trivy dwingt die zelf af: zodra de datum voorbij is, komt de bevinding terug. Zo wordt “dit moeten we ooit nog eens nakijken” een concrete dag waarop de controle het je vraagt.

Kies een datum waarop je het echt opnieuw zou nakijken: de volgende release van de upstream-tool, of een kwartaal verder.

Wanneer je beter via de API negeert

Kies voor een negering in plaats van een ignore-bestand wanneer:

• de bevinding verouderd is: je hebt het al bij de bron opgelost en wilt alleen de rij opruimen. Meestal heb je dit niet eens nodig; de automatische afhandeling per uur vervangt het zodra er een nieuwere scan draait.
• de acceptatie gaat over de situatie van deze repository op dit moment, niet over de code: bijvoorbeeld een bevinding op een branch die inmiddels is samengevoegd.
• je de reden in de auditlog wilt hebben. Negeringen worden vastgelegd met wie en waarom; een ignore-bestand wordt in plaats daarvan vastgelegd in de Git-geschiedenis.

Een ignore-bestand is de duurzame keuze; een negering is die voor één moment.

Controleren of het werkt

Draai de scan opnieuw en controleer dat de bevinding weg is; zie scans opnieuw uitvoeren. Lijkt de regel geen effect te hebben, kijk dan eerst naar de regel bovenaan deze pagina: een .trivyignore.yaml ergens in de root van de repository schakelt het gewone bestand volledig uit.

Zie ook

• Findings-API: bevindingen lezen en negeren via REST.
• Image-scans: wat een merge blokkeert, en de drempel voor ernst.
• Licentiescans: beleidscategorieën en allowlists.