Kwetsbaarheden prioriteren: bepalen wat u eerst repareert

Waarom ernst alleen niet werkt

De gebruikelijke aanpak is sorteren op CVSS en van kritiek naar beneden werken. Dat voelt objectief, en het faalt om drie redenen:

• CVSS meet ernst, geen risico. Het beschrijft hoe erg een kwetsbaarheid zou zijn als die wordt misbruikt. Het zegt niet of iemand haar misbruikt, of ze in uw product van belang is.
• Te veel van de lijst is urgent. Veel gepubliceerde CVE's scoren hoog of kritiek, dus een wachtrij die op CVSS is gesorteerd, zet honderden bevindingen bovenaan en biedt geen manier om daartussen te kiezen.
• De lijst is maar zo goed als de inventaris. Een scanner die een lockfile leest, rapporteert ontwikkelafhankelijkheden die nooit worden geleverd, en mist pakketten die de build buiten de pakketbeheerder om heeft gedownload. Beide vervormen de rangschikking nog voordat die begint.

Prioritering voegt de ontbrekende vragen toe: wordt ze misbruikt, hoe waarschijnlijk is dat, en wat gebeurt er met u als dat zo is.

De signalen

Signaal	Vraag die het beantwoordt	Bron
CVSS	Hoe ernstig is ze als ze wordt misbruikt? Score van 0 tot 10.	FIRST (de standaard); NVD en leveranciers publiceren scores
EPSS	Hoe waarschijnlijk is misbruik in de komende 30 dagen? Een kans van 0 tot 1.	FIRST, dagelijks bijgewerkt, gratis
CISA KEV	Wordt ze al in het wild misbruikt?	De Known Exploited Vulnerabilities-catalogus van CISA
SSVC	Wat moet u doen, gegeven misbruik, impact en uw missie: volgen, aandacht geven of handelen?	Beslisbomen van CERT/CC en CISA
Uw context	Wordt de kwetsbare versie geleverd? Is ze blootgesteld? Hoe belangrijk is het product? Is er een fix?	Uw inventaris, architectuur en asset-administratie

De openbare signalen beschrijven de kwetsbaarheid. Alleen uw context beschrijft uw risico, en dat is het deel dat de meeste teams uit de minst betrouwbare bron halen.

Een praktische prioriteringsmethode

De meeste programma's komen uit bij een variant van deze niveaus. Stem de termijnen af op wat uw beleid en klanten vragen.

1. Nu repareren: bekend misbruik, in software die u levert. Alles op de KEV-lijst, of met ander bewijs van misbruik, dat in een uitgebrachte build zit. Ter vergelijking: BOD 26-04 van CISA geeft Amerikaanse federale instanties voor een KEV-vermelding op een publiek toegankelijk systeem slechts 3 dagen.
2. Hierna repareren: waarschijnlijk misbruik en ernstig. Een hoge EPSS-score gecombineerd met een hoge of kritieke CVSS-score, in een geleverd en blootgesteld component. Kies een EPSS-drempel die een wachtrij oplevert die uw team echt kan wegwerken.
3. Routinematig repareren: al het andere dat wordt geleverd. Bundel het in reguliere upgrades van afhankelijkheden in plaats van elke bevinding als incident te behandelen.
4. Documenteren: niet getroffen. Het kwetsbare pakket is aanwezig, maar de kwetsbare code wordt niet gebruikt, of het component wordt niet geleverd. Leg de redenering vast als VEX-verklaring, zodat dezelfde bevinding niet terugkomt ter beoordeling en klanten die ernaar vragen, kunnen zien waarom.

Rangschik daarna doorlopend opnieuw. Een kwetsbaarheid op niveau drie kan van de ene op de andere dag naar niveau één gaan wanneer ze aan KEV wordt toegevoegd of haar EPSS-score omhoogschiet.

De kwetsbaarheden die u nooit kunt rangschikken

Elke prioriteringsmethode rangschikt de bevindingen die ze voor zich heeft. Een kwetsbaar pakket dat de scanner nooit heeft gezien, levert geen bevinding op, dus het krijgt nooit een CVSS-score, een EPSS-score of een KEV-match. Het wordt niet laag gerangschikt. Het wordt helemaal niet gerangschikt, en het wordt toch geleverd.

Dit gebeurt vaker dan u misschien denkt, omdat de meeste scanners uit bestanden afleiden wat er in uw software zit: de lockfile, de manifests of de uitvoer van de build. Alles wat de build ophaalt en niet in een lockfile staat, is een verborgen afhankelijkheid, en op bestanden gebaseerde tools missen die:

• Install-hooks. Code die wordt gedownload door de npm-scripts preinstall en postinstall, de route die de Shai-Hulud-worm gebruikte.
• Buildscripts. Bijvoorbeeld Rust-buildscripts die tijdens de build code downloaden.
• Base images. De base image van een containerbuild en de lagen van het besturingssysteem daarin.
• Caches. Pakketten die uit een CI-cache worden teruggezet in plaats van vanuit de lockfile te worden geïnstalleerd.

De uitvoer achteraf scannen dicht dat gat niet. Bij een afgeronde binary, zeker bij gecompileerde code zoals Rust, moet de scanner raden wat erin is gegaan. En omdat builds standaard niet reproduceerbaar zijn, is het later opnieuw bouwen van dezelfde commit geen garantie voor dezelfde afhankelijkheden.

Een SBOM uit de build begint aan de andere kant. CRACI draait uw GitHub Actions-jobs en ziet het verkeer dat elke build binnenkomt, dus het legt elk pakket vast dat de job daadwerkelijk heeft binnengehaald, verborgen afhankelijkheden inbegrepen. Elke SBOM heeft een volledigheidsstatus die aangeeft wanneer iets niet kon worden gezien. In de praktijk heeft CRACI kwetsbare pakketten gevonden die Snyk en Aikido niet rapporteerden, omdat de componenten in hun scans ontbraken. Dat zijn precies de bevindingen die een prioriteringsmethode nooit de kans krijgt te rangschikken.

Context: het deel dat scanners niet voor u kunnen scoren

Wordt de kwetsbare versie echt geleverd?

Dit is de vraag die de meeste ruis wegneemt. Een testframework in een lockfile, een pakket dat is vastgepind in een branch die nooit wordt uitgebracht, een containerfase die wordt weggegooid: geen daarvan bereikt klanten. Een SBOM die tijdens de build is vastgelegd, beantwoordt de vraag op basis van wat de releasebuild daadwerkelijk heeft gebruikt, en niet op basis van wat de repository declareert.

Welke releases bevatten de kwetsbaarheid, en sinds wanneer?

Een bevinding in een product dat u aan klanten levert, waarbij elke release sinds afgelopen voorjaar is getroffen, gaat boven dezelfde bevinding in een interne tool. De blootstellingsperiode kennen vertelt u ook wat u moet melden.

Is de kwetsbare code bereikbaar?

Reachability-analyse traceert of uw code de kwetsbare functie in een afhankelijkheid kan aanroepen. Verschillende SCA-tools bieden dit, en het duwt onbereikbare bevindingen effectief lager op de lijst. Behandel het als één invoer: het ziet alleen codepaden die de analyse kan volgen, en een bereikbare functie is niet hetzelfde als een misbruikbare.

Is ze blootgesteld, en is er een fix?

Een dienst die aan internet hangt, gaat boven een batchjob op een privénetwerk. Een kwetsbaarheid met een gepatchte versie is goedkoper te dichten dan een die een mitigatie nodig heeft. Beide veranderen de volgorde, niet of ze wordt afgehandeld.

Risicogebaseerd kwetsbaarheidsbeheer

Risicogebaseerd kwetsbaarheidsbeheer is de naam op programmaniveau voor hetzelfde idee: rangschik op bewijs van misbruik, waarschijnlijkheid, ernst en bedrijfscontext, meet hoe snel de riskantste bevindingen worden gesloten, en accepteer dat bevindingen met een laag risico open kunnen blijven. De meetwaarden veranderen mee. Volg in plaats van het totale aantal open kwetsbaarheden hoeveel bekend misbruikte kwetsbaarheden in geleverde software openstaan, en hoe lang ze openblijven.

Tools voor het prioriteren van kwetsbaarheden

Drie soorten tools doen vandaag het meeste rangschikwerk:

• Platforms voor kwetsbaarheidsbeheer van infrastructuur zoals Tenable, Qualys en Rapid7 scoren hosts, endpoints en cloudassets met eigen risicobeoordelingen, gebaseerd op informatie over misbruik.
• SCA- en applicatiebeveiligingstools zoals Snyk, Endor Labs en Semgrep rangschikken bevindingen in afhankelijkheden, verschillende ervan met reachability-analyse.
• Open-sourcetools zoals Grype, dat EPSS- en KEV-gegevens bij zijn bevindingen rapporteert, en Dependency-Track, dat SBOM's doorlopend analyseert.

Tools voor kwetsbaarheidsbeheer vergeleken behandelt ze een voor een.

Hoe CRACI prioritering ondersteunt

CRACI begint waar de rangschikking het vaakst misgaat: de inventaris. Het draait uw GitHub Actions-jobs en legt de pakketten vast die elke job daadwerkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit caches zijn teruggezet en verborgen afhankelijkheden die in geen enkele lockfile staan.

• Bevindingen voor wat is geleverd. Gemonitorde SBOM's worden doorlopend opnieuw beoordeeld, en organisatieweergaven bundelen bevindingen over builds en repositories heen. Elk pakket toont zijn advisories met ernst en de pakketten die het binnenhalen.
• Blootstellingsperiode. De buildgeschiedenis toont welke eerdere builds een kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet welke releases zijn getroffen en hoe lang.
• Triage en toewijzing. Securityteams triëren bevindingen en sturen elke bevinding naar het team dat verantwoordelijk is voor de fix. CRACI ondersteunt VEX om vast te leggen dat een kwetsbaarheid uw product niet raakt.
• Controlepunten. Policy gates kunnen een build blokkeren op bevindingen, ook een build die een specifieke CVE bevat.

CRACI biedt geen reachability-analyse. Is dat het signaal dat u het hardst nodig hebt, kies dan een van de SCA-tools die het wel bieden. Zie het volgen van kwetsbaarheden voor de volledige functionaliteit.

Kwetsbaarheden prioriteren: veelgestelde vragen

Wat is het prioriteren van kwetsbaarheden?

Het prioriteren van kwetsbaarheden is bepalen welke bekende kwetsbaarheden u eerst repareert, welke kunnen wachten en welke u helemaal niet raken. Het rangschikt bevindingen op hoe waarschijnlijk misbruik is en hoeveel schade dat in uw omgeving zou aanrichten, niet alleen op ernst.

Hoe prioriteert u kwetsbaarheden?

Begin met een nauwkeurige inventaris, zodat u kwetsbaarheden rangschikt in software die echt wordt geleverd. Geef voorrang aan alles wat op de Known Exploited Vulnerabilities-lijst van CISA staat en rangschik de rest op waarschijnlijkheid van misbruik (EPSS) en ernst (CVSS), aangepast aan uw context: blootstelling, het belang van het product en of er een fix bestaat. Leg de kwetsbaarheden die u niet raken vast als VEX-verklaringen.

Is CVSS genoeg om kwetsbaarheden te prioriteren?

Nee. CVSS meet hoe ernstig een kwetsbaarheid is, niet hoe waarschijnlijk misbruik is of hoeveel ze voor u uitmaakt. Alleen rangschikken op CVSS markeert een groot deel van de backlog als hoog of kritiek, en de meeste van die kwetsbaarheden worden nooit misbruikt.

Wat is risicogebaseerd kwetsbaarheidsbeheer?

Risicogebaseerd kwetsbaarheidsbeheer rangschikt en repareert kwetsbaarheden op het risico dat ze voor uw organisatie vormen, door bewijs van misbruik, waarschijnlijkheid, ernst en bedrijfscontext te combineren, in plaats van ze af te werken op CVSS-score of leeftijd.

Wat is het verschil tussen EPSS en KEV?

EPSS is een voorspelling: de geschatte kans dat een CVE in de komende 30 dagen wordt misbruikt. KEV is een register: de CISA-catalogus van kwetsbaarheden met bewijs van misbruik in het wild. Een KEV-vermelding is een feit; een EPSS-score is een waarschijnlijkheid. Gebruik eerst KEV en daarna EPSS om al het andere te rangschikken.

Vervangt reachability-analyse prioritering?

Nee, het is nog een invoer. Reachability controleert of uw code de kwetsbare functie in een afhankelijkheid kan aanroepen. Het verwijdert bevindingen die niet kunnen worden geactiveerd, maar het zegt niets over hoe waarschijnlijk misbruik is, en het dekt alleen code die de analyse kan volgen.