Uitzonderingen op de beveiligingsscan blijven staan nadat ze overbodig zijn #140

Aanleiding

Kwetsbaarheden waarvoor op dat moment geen oplossing bestaat, worden als uitzondering vastgelegd zodat de controle niet blijft blokkeren. Zo'n uitzondering krijgt een houdbaarheidsdatum van enkele maanden. Komt er eerder een oplossing beschikbaar, dan merkt niemand dat: de uitzondering blijft gewoon staan tot de datum verstrijkt.

Het enige wat er nu gebeurt, is een zin in het voorstel bij een nieuwe uitgave van het onderliggende pakket, met het verzoek aan de beoordelaar om de lijst na te lopen.

Effect

Een uitzondering die niets meer onderdrukt, verbergt wél. De regel geldt namelijk nog steeds: duikt dezelfde kwetsbaarheid op een andere plek op waar hij wél op te lossen is, dan wordt die stilgehouden zolang de regel binnen zijn houdbaarheidsdatum valt en op datzelfde pad slaat.

Daarnaast geeft de lijst een verkeerd beeld van hoeveel er werkelijk openstaat: wie hem leest, ziet uitzonderingen die er allang niet meer hoefden te zijn.

Wenselijk gedrag

Zodra een uitzondering niets meer onderdrukt, is dat zichtbaar en verdwijnt de regel — zonder te wachten tot de houdbaarheidsdatum verstrijkt.

Acceptatiecriteria

• Bij elke periodieke controle is vast te stellen welke uitzonderingen daadwerkelijk zijn toegepast en welke niet
• Een uitzondering die niets meer onderdrukt levert een zichtbaar signaal op
• Het opruimen ervan gebeurt zonder dat iemand de lijst handmatig hoeft te vergelijken
• De controle werkt voor beide gepubliceerde processorvarianten
• Een uitzondering die nog wél nodig is, blijft ongemoeid

Technische details

Vandaag bestaat er alleen een tijdslot: expired_at in .trivyignore.yaml (nu 2026-11-26 voor de vier npm-bundelregels). Verloopt die datum, dan rapporteert Trivy de bevinding weer en worden de gates in trivy.yml en build-image.yml rood; apt-security-refresh waarschuwt. .github/scripts/valideer-trivyignore.sh bewaakt uitsluitend de vorm. De enige inhoudelijke trigger is de tekst in de PR-body van de job npm-version.

Richting: apt-security-refresh in check-upstream.yml scant wekelijks al beide architecturen. Voeg daar --show-suppressed aan toe — Trivy rapporteert dan per scan welke suppressies zijn toegepast. Een id uit .trivyignore.yaml dat in geen van beide scans voorkomt, onderdrukt niets meer.

Alternatief zonder die vlag: één scan zonder ignorefile draaien en gesuppresste ID's − gevonden ID's nemen. Dat kost een extra scan en is daarmee duurder; de vlag verdient de voorkeur.

Let bij het verwerken op twee dingen:

• Een regel kan ook niet aanslaan omdat het pad niet meer klopt (bijvoorbeeld na een verplaatsing van usr/local/lib/node_modules/npm/**). Dat is geen reden om hem weg te halen maar om hem te corrigeren; onderscheid die twee gevallen in het signaal.
• De misconfig-regels (DS-0002, DS-0026) leggen een architectuurkeuze vast en horen niet mee te doen in deze opruiming.

Bouwt voort op #124, dat de uitzonderingen hun pad en houdbaarheidsdatum gaf; dit is de andere helft: een aanleiding om eerder te verdwijnen dan die datum.