Er verschijnen elke dag tientallen nieuwe CVE’s, maar de vraag die ertoe doet is kort: staat dit lek op onze systemen en zouden we het zien als iemand het misbruikt? Deze gids laat in vier stappen zien hoe je van een CVE in het nieuws naar een antwoord in je eigen data komt.
Wat speelt er nu?
Op 29 oktober 2026 zette het Amerikaanse CISA een lek in GitLab (CVE-2026-97229, CVSS 10) op de lijst van actief uitgebuite kwetsbaarheden, de Known Exploited Vulnerabilities (KEV). Aanvallers probeerden het onder meer bij Alpine Linux. In dezelfde ronde kwam CVE-2026-76418 in Cisco ASA en FTD op de lijst en op 3 november volgde WordPress Core CVE-2026-119977 (The Hacker News).
Dat komt bovenop een recordjaar: in 2025 verschenen 48.185 CVE’s (Jerry Gamblin via The Stack). Niemand leest die allemaal en dat hoeft ook niet.
Stap 1: scheid uitgebuit van gepubliceerd
De meeste CVE’s worden nooit misbruikt. De KEV-lijst bevat de lekken die wel actief worden uitgebuit en EPSS geeft voor de rest een kans dat ze in de komende 30 dagen worden misbruikt. Samen maken ze van tienduizenden CVE’s een korte lijst waar je deze week iets mee kunt.
LogPulse haalt KEV elke zes uur op, NVD elke twee uur en EPSS dagelijks. De prioriteit van een CVE is dus al bekend voordat je hem opent.
Stap 2: kijk of het lek bij jou draait
Een CVE is alleen relevant als de kwetsbare versie ergens bij jou draait. Dat antwoord staat in je kwetsbaarheidsscans, niet in het advies van de leverancier. Stuur de uitvoer van Trivy, Grype, Snyk of Clair naar LogPulse met sourcetype security_vulnerability, dan worden de bevindingen elke zes uur naast de CVE-kennisbank gelegd. Een GitLab-image met de kwetsbare versie verschijnt dan als blootgesteld, met de KEV- en EPSS-context erbij.
Zonder scans geen antwoord
Stuur je geen scans, dan kan LogPulse niet zeggen of een lek op je systemen staat. Firmware van edge-apparaten zoals firewalls zit meestal ook niet in container- of pakketscans. Volg daarvoor de adviezen van de leverancier zelf.
Stap 3: zorg dat er iets meekijkt
Patchen is de oplossing en LogPulse vervangt dat niet. Maar een patch kost dagen en een aanvaller uren, dus de volgende vraag is of een detectie een poging zou zien. Elke regel uit de hub noemt de logbronnen die hij nodig heeft. Kan een regel niet afgaan omdat bijvoorbeeld je GitLab- of firewalllogs niet binnenkomen, dan zegt de Security-pagina welke bron ontbreekt en hoe je hem koppelt.
Nieuwe regels uit de hub gaan pas live nadat een mens ze heeft beoordeeld en de regel zijn test in het Detection Lab heeft gehaald. Geen AI zet zelf een regel aan.
Stap 4: kijk ook terug
Als een CVE op de KEV-lijst komt, wordt hij meestal al een tijd misbruikt. Daarom draait LogPulse een retro-hunt zodra er nieuwe indicatoren of regels binnenkomen: bekende aanvals-IP’s worden 30 dagen terug in je logs gezocht, nieuwe regels 7 dagen terug. Stond de poging al in je data, dan weet je het nu.
Checklist voor de volgende CVE in het nieuws
- Staat de CVE op de KEV-lijst, of heeft hij een hoge EPSS-score?
- Laat je laatste scan de kwetsbare versie zien en op welke systemen?
- Komen de logs binnen die een detectie voor dit lek nodig heeft?
- Is er in de afgelopen 30 dagen verkeer van bekende aanvals-IP’s geweest?
- Wie patcht en wanneer? Leg het vast; onder de Cyberbeveiligingswet hoort dit bij je zorgplicht.
Bekijk hoe de hele keten werkt op de pagina Threat intelligence. Het gratis plan bevat securitymonitoring en vraagt geen creditcard.