CVE-remediatie: van advisory tot een gerepareerde, geleverde build

Het CVE-remediatieproces

CVE-remediatie verwijdert een openbaar gemaakte kwetsbaarheid uit software die u gebruikt of levert. Voor uw eigen code betekent dat een patch. Voor open-sourceafhankelijkheden, waar de meeste CVE's in een doorsneeproduct vandaan komen, betekent het overstappen op een versie waarin de kwetsbaarheid is verholpen. Hoe dan ook zijn de stappen hetzelfde:

1. Vind elk product, elke build en elke release die het getroffen pakket en de getroffen versie bevat.
2. Beoordeel of de kwetsbaarheid u raakt, en hoe ernstig.
3. Prioriteer ten opzichte van al het andere dat openstaat.
4. Repareer door te upgraden, te patchen, te vervangen of, als er geen fix bestaat, te mitigeren.
5. Verifieer dat de nieuwe build echt de gerepareerde versie bevat.
6. Leg vast wat er was getroffen, wat u hebt besloten en wanneer de fix is geleverd.

Stap 1: vind elke getroffen build

De eerste vraag na een advisory is waar het pakket zit. Die beantwoorden vanuit bronrepositories gaat traag en klopt vaak niet: de versie in een lockfile, de versie die een build heeft geresolved en de versie in een uitgebrachte containerimage kunnen allemaal verschillen. Transitieve afhankelijkheden en pakketten die een build buiten de pakketbeheerder om downloadt, staan helemaal niet in manifests.

Het betrouwbare antwoord komt van een SBOM van elke release, die doorlopend met advisories wordt vergeleken. Als die SBOM tijdens de build wordt vastgelegd, toont hij wat de build echt heeft gebruikt, dus de match vertelt u welke geleverde builds de kwetsbare versie bevatten, niet welke repositories die noemen.

Stap 2: prioriteer op ernst en misbruik

Ernst alleen bestempelt te veel kwetsbaarheden als urgent. De meeste teams combineren drie signalen:

Signaal	Wat het u vertelt	Gepubliceerd door
CVSS	Hoe ernstig de kwetsbaarheid is als die wordt misbruikt, gescoord van 0 tot 10	FIRST (de standaard); NVD en leveranciers publiceren scores
EPSS	De geschatte kans op misbruik in de komende 30 dagen	FIRST
KEV	Of bekend is dat de kwetsbaarheid in de praktijk wordt misbruikt	De Known Exploited Vulnerabilities-catalogus van CISA

Voeg daar uw eigen context aan toe: of het getroffen pakket naar klanten gaat of alleen in een testjob draait, en of de kwetsbare functie überhaupt wordt gebruikt. Een bekend misbruikte kwetsbaarheid in een pakket dat wordt geleverd, gaat bovenaan de lijst. Kwetsbaarheden prioriteren maakt van deze signalen een methode.

Hersteltermijnen

• CISA BOD 26-04. Sinds 10 juni 2026 bepalen Amerikaanse federale instanties elke termijn aan de hand van vier vragen: is het bedrijfsmiddel publiek blootgesteld, staat de kwetsbaarheid in de KEV-catalogus, kan misbruik worden geautomatiseerd, en geeft ze gedeeltelijke of volledige controle. De antwoorden lopen uiteen van 3 dagen, met forensische triage voor de ergste gevallen, tot repareren bij de volgende systeemupgrade. De richtlijn verving BOD 22-01, die twee weken gaf voor de meeste KEV-vermeldingen.
• EU Cyber Resilience Act. Fabrikanten moeten kwetsbaarheden onverwijld aanpakken en verhelpen, onder meer via beveiligingsupdates (bijlage I, deel II). Sinds 11 september 2026 gelden bij een actief misbruikte kwetsbaarheid in een product ook meldtermijnen: een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur en een eindrapport binnen 14 dagen nadat een fix beschikbaar is.
• Uw eigen beleid. De meeste beveiligingsprogramma's stellen interne doelen per ernst vast. Wat die ook zijn, u haalt ze alleen als stap 1 snel gaat.

Stap 3: kies de fix

Optie	Wanneer u die gebruikt
Upgraden	Er bestaat een gerepareerde versie. Kies de kleinste upgrade die de fix bevat, om breaking changes te beperken.
De parent upgraden	Het kwetsbare pakket is transitief. Een nieuwere release van de directe afhankelijkheid haalt vaak de fix binnen.
Overschrijven	De parent heeft geen fix uitgebracht. Forceer de transitieve versie met npm overrides, Yarn resolutions of pnpm.overrides, en test het.
Patchen of backporten	U kunt nog niet naar de gerepareerde hoofdversie. Pas de upstream-fix toe op de versie die u gebruikt.
Vervangen	Het pakket wordt niet onderhouden of blijft CVE's opleveren. Stap over op een alternatief.
Mitigeren en documenteren	Er bestaat nog geen fix, of uw product is niet getroffen. Verklein de blootstelling en leg de beoordeling vast, bijvoorbeeld als VEX-verklaring.

Het grootste deel van deze stap kan worden geautomatiseerd, van het kiezen van de versie tot het openen van de pull request. Geautomatiseerd herstel van kwetsbaarheden behandelt wat u automatiseert en wat u aan een mens overlaat.

Stap 4: een gemergede fix is nog geen geleverde fix

De pull request is gemerged, dus de CVE is gesloten. Niet per se. De fix staat in de repository, maar een build zet een verouderde cache terug, een base image bevat nog het oude pakket, of een releasebranch heeft de wijziging nooit overgenomen. Het ticket staat op opgelost, terwijl het product nog steeds de kwetsbare versie levert.

Sluit de cirkel vanaf de andere kant: controleer de SBOM van de volgende build en bevestig dat de kwetsbare versie weg is. Wanneer die SBOM vastlegt wat de build echt heeft opgehaald, inclusief pakketten die uit caches zijn teruggezet, beantwoordt de controle de vraag die de klant, de auditor en de toezichthouder echt stellen.

Hoe CRACI CVE-remediatie ondersteunt

• Vinden. CRACI legt de pakketten vast die elke GitHub Actions-job heeft opgehaald, inclusief transitieve afhankelijkheden en pakketten die uit caches zijn teruggezet, en beoordeelt gemonitorde SBOM's doorlopend opnieuw. Weergaven op organisatieniveau bundelen bevindingen over builds en repositories heen, zodat u ziet welke builds een nieuwe CVE raakt.
• Toewijzen. Securityteams triëren elke bevinding en sturen die naar het team dat verantwoordelijk is voor de fix. CRACI ondersteunt VEX om vast te leggen hoe een kwetsbaarheid uw product raakt.
• Verifiëren. Elke nieuwe build krijgt zijn eigen SBOM met een volledigheidsstatus, zodat u kunt bevestigen dat de build de gerepareerde versie heeft gebruikt.
• Melden. Voor actief misbruikte kwetsbaarheden onder de CRA dient CRACI de meldingen namens de fabrikant in bij de autoriteiten.

Zie het volgen van kwetsbaarheden voor de volledige functionaliteit.

CVE-remediatie: veelgestelde vragen

Wat is CVE-remediatie?

CVE-remediatie is het verwijderen van een openbaar gemaakte kwetsbaarheid, herkenbaar aan haar CVE-ID, uit de software die u gebruikt of levert. Voor een afhankelijkheid betekent dat meestal upgraden naar een versie waarin de kwetsbaarheid is verholpen. Voor uw eigen code betekent het patchen.

Hoe bepaal ik welke CVE's ik het eerst moet repareren?

Combineer ernst met bewijs van misbruik. CVSS beschrijft hoe erg een kwetsbaarheid is, EPSS schat hoe waarschijnlijk misbruik in de komende 30 dagen is, en de Known Exploited Vulnerabilities-catalogus van CISA vermeldt de kwetsbaarheden die al worden misbruikt. Een bekend misbruikte kwetsbaarheid in een pakket dat u levert, gaat bovenaan.

Hoe snel moeten CVE's worden hersteld?

Dat hangt ervan af wie het vraagt. Binding Operational Directive 26-04 van CISA geeft Amerikaanse federale instanties tussen 3 dagen en de volgende systeemupgrade, afhankelijk van of de kwetsbaarheid in de KEV-catalogus staat, of het bedrijfsmiddel publiek is blootgesteld, of misbruik kan worden geautomatiseerd en hoeveel controle het een aanvaller geeft. De EU Cyber Resilience Act vraagt fabrikanten kwetsbaarheden onverwijld te verhelpen, en sinds 11 september 2026 geldt bij een actief misbruikte kwetsbaarheid in een product een meldtermijn van 24 uur.

Wat als er nog geen gerepareerde versie is?

Mitigeer en documenteer. Schakel de getroffen functie uit, blokkeer het aanvalspad of vervang de component als dat kan, en leg uw beoordeling vast, bijvoorbeeld als VEX-verklaring. Houd daarna de gerepareerde release in de gaten en herstel zodra die verschijnt.

Hoe repareer ik een CVE in een transitieve afhankelijkheid?

Probeer eerst de directe afhankelijkheid te upgraden die hem binnenhaalt, omdat een nieuwere release vaak de fix bevat. Bestaat die nog niet, dan kunt u bij de meeste pakketbeheerders de versie van een transitief pakket forceren: overrides in npm, resolutions in Yarn, pnpm.overrides in pnpm. Test het resultaat, want het parentpakket is niet tegen die versie gebouwd.