Kennisbank / AI & vulnerability management

AI en enterprise security: meer kwetsbaarheden zichtbaar, maar ook beter verdedigbaar

Auteur: DEWOLF.IT

AI verandert vulnerability management aan twee kanten tegelijk. De technologie vergroot de capaciteit om fouten, kwetsbaarheden en verdachte patronen te vinden, waardoor securityteams meer findings te verwerken krijgen. Tegelijk wordt dezelfde technologie steeds waardevoller om die stroom te correleren, prioriteren en terug te brengen tot de kwetsbaarheden die in de eigen enterprise-omgeving werkelijk risico opleveren.

Scope. Dit artikel gaat niet over AI als autonome securitybeslisser. Het gaat over AI als extra analyse- en correlatielaag binnen bestaand vulnerability management, met enterprise Linux en RHEL als praktisch voorbeeld.

Probleem en achtergrond: AI vergroot de detectiecapaciteit

Software bevatte ook vóór generatieve AI kwetsbaarheden. Wat verandert, is de schaal en snelheid waarmee code en configuraties onderzocht kunnen worden. LLM-agents kunnen broncode lezen, hypothesen vormen, testcases genereren en resultaten uit tooling interpreteren. Daardoor worden defecten bereikbaar die met handmatige review of een specifieke fuzzingconfiguratie mogelijk langer onopgemerkt zouden blijven.

Google Project Zero en DeepMind publiceerden met Big Sleep een concreet voorbeeld: een AI-agent vond een exploiteerbare stack-buffer-underflow in SQLite voordat die code in een officiële release terechtkwam. De onderzoekers benadrukten daarbij zelf dat het om experimenteel werk ging en dat gespecialiseerde fuzzers voor bepaalde doelen nog minstens zo effectief kunnen zijn. Het relevante punt is dus niet dat AI klassieke securityresearch vervangt, maar dat er een nieuwe schaalbare onderzoeksmethode bijkomt.

Hetzelfde principe was zichtbaar in DARPA’s AI Cyber Challenge. De finalistensystemen analyseerden gezamenlijk tientallen miljoenen regels code en waren ontworpen om kwetsbaarheden automatisch te vinden én patches te produceren. Naarmate zulke technieken breder beschikbaar worden, is het logisch dat de hoeveelheid gevonden issues en securitysignalen verder groeit.

Meer findings zijn niet hetzelfde als meer risico

Een vulnerability scanner kan duizenden CVE’s tonen zonder te vertellen welke daarvan maandagmorgen als eerste moet worden opgelost. Een hoge CVSS-score is belangrijk, maar zegt op zichzelf niet of de kwetsbare component op een betrokken systeem aanwezig is, bereikbaar is voor een aanvaller, daadwerkelijk exploiteerbaar is binnen de gebruikte configuratie of al door een vendorpatch is afgedekt.

Voor prioritering zijn meerdere signalen nodig: affectedness van het product, bekende exploitatie, bereikbaarheid, privileges, assetkritiek, business impact, compensating controls en de beschikbaarheid van een fix of mitigatie. De CISA Known Exploited Vulnerabilities Catalog is daarom nuttig als harde indicator dat misbruik in het wild is vastgesteld. EPSS voegt daar een andere dimensie aan toe: een data-gedreven inschatting van de kans op exploitatie in de komende dertig dagen. Ook EPSS is nadrukkelijk geen volledige risicoscore; omgevingscontext blijft noodzakelijk.

RHEL laat zien waarom context belangrijker is dan alleen een CVE-lijst

Enterprise Linux maakt de beperkingen van generieke vulnerability scoring goed zichtbaar. Red Hat past securityfixes regelmatig via backports toe op stabiele pakketversies. Daardoor kan een pakket een oudere upstream-versie tonen terwijl de relevante beveiligingsfix al in het RHEL-pakket aanwezig is. Red Hat waarschuwt expliciet dat scanners die alleen naar upstream-versienummers kijken hierdoor false positives kunnen produceren.

Een bruikbare analyse moet daarom de scannerfinding verbinden met vendorinformatie. Red Hat publiceert hiervoor machine-readable security data, waaronder CSAF- en VEX-documenten. Daarin kan onder meer worden vastgelegd of een productvariant daadwerkelijk geraakt wordt en welke remediation bij een advisory hoort. Voor moderne workflows is juist die productcontext belangrijker dan een simpele vergelijking van versiestrings.

scanner finding
      |
      v
CVE -> package/NEVRA -> RHEL product context
      |
      +-> Red Hat advisory / CSAF / VEX
      +-> CISA KEV / exploit evidence
      +-> exposure / network path
      +-> asset criticality / business risk
      |
      v
prioriteit -> remediation -> verificatie

Dit is precies het soort keten waarin AI waarde kan toevoegen: niet door één bron tot waarheid te verheffen, maar door gegevens uit meerdere betrouwbare bronnen bij elkaar te brengen en afwijkingen zichtbaar te maken.

Waar AI defensief waarde toevoegt

De sterkste rol van AI binnen vulnerability management is voorlopig niet het autonoom nemen van beslissingen, maar het reduceren van analysewerk. In een grote omgeving kan een AI-laag bijvoorbeeld:

gelijksoortige findings clusteren en duplicaten herkennen;
security advisories, VEX-data en scanneroutput samenvatten tot één dossier;
een CVE koppelen aan getroffen assets, services en business-eigenaren;
bekende exploitatie, exposure en assetkritiek combineren tot een voorgestelde prioriteit;
verschillen tussen een generieke scannerfinding en de vendorstatus signaleren;
remediationvoorstellen en teststappen voorbereiden voor review;
grote hoeveelheden log-, configuratie- en changerecords doorzoeken op relevante context.

De Red Hat vulnerability service laat hetzelfde onderliggende principe zien zonder dat daar per se generatieve AI voor nodig is: resultaten kunnen worden gefilterd op onder meer severity, bekende exploits, business risk en daadwerkelijk blootgestelde systemen. Vanuit die context kan remediation vervolgens worden voorbereid. AI kan zo’n proces verder versnellen door de niet-gestructureerde informatie rond een finding te interpreteren en samen te vatten.

Een gecontroleerde enterprise-workflow

Een volwassen implementatie houdt deterministische securitydata en AI-analyse bewust uit elkaar. Een praktisch proces kan uit zes stappen bestaan.

Verzamel. Scannerdata, package inventory, Red Hat advisories, CSAF/VEX, KEV, assetinformatie en netwerkcontext.
Normaliseer. Koppel CVE, package, systeem, service en eigenaar met stabiele identifiers.
Verrijk. Voeg known-exploit-status, exploitkans, exposure, business risk en lifecycle-informatie toe.
Laat AI correleren. Laat een model samenvatten, groeperen en inconsistenties aanwijzen, maar laat het bronmateriaal zichtbaar.
Laat beleid beslissen. Prioriteit en change-urgentie volgen uit vastgelegde securityregels en menselijke beoordeling, niet uit een losse modelscore.
Remedieer en verifieer. Patch via de normale content- en changeflow, bijvoorbeeld met Satellite en Ansible, en controleer daarna opnieuw of de finding werkelijk is verdwenen.

Die scheiding is essentieel. Een taalmodel kan uitstekend helpen om informatie te ontsluiten, maar een onderbouwde vendorstatus, package-inventory of netwerkregel moet niet worden vervangen door een waarschijnlijk klinkend antwoord.

Wat AI niet zelfstandig moet beslissen

De verleiding is groot om van automatische analyse meteen automatische remediation te maken. In bedrijfskritische omgevingen is dat een gevaarlijke sprong. Een patch kan een exploit sluiten en tegelijk een applicatie, kernelmodule of afhankelijkheid breken. Een configuratiewijziging kan een attack surface verkleinen en tegelijkertijd de beschikbaarheid aantasten.

AI-output hoort daarom dezelfde controles te doorlopen als ander technisch advies: broncontrole, reproduceerbaarheid, impactanalyse, change approval, rollback en verificatie. Hoe groter de autonomie van de tooling, hoe belangrijker het wordt dat beslisregels, gebruikte bronnen en uitzonderingen auditbaar blijven.

De paradox: meer vinden maakt betere filtering noodzakelijk

AI zal vulnerability management waarschijnlijk niet eenvoudiger maken doordat er minder informatie komt. Het tegenovergestelde ligt meer voor de hand: betere detectie levert meer bevindingen, meer verbanden en meer mogelijke acties op. De schaarse factor verschuift daarmee van vinden naar begrijpen en prioriteren.

Juist daarom wordt AI ook aan de verdedigende kant interessant. Niet als vervanger van security engineering, maar als schaalvergroter die mensen helpt om uit duizenden signalen de tientallen beslissingen te halen die er werkelijk toe doen. In een enterprise-omgeving is de vraag uiteindelijk niet hoeveel CVE’s een scanner kan produceren, maar hoe snel het team kan aantonen welke daarvan de eigen dienstverlening werkelijk bedreigen en welke gecontroleerde maatregel nodig is.

Bronnen en verdere lezing

Gerelateerde kennis

Voor de operationele kant van vulnerability management: Red Hat Satellite: gecontroleerd patchen met content views, Ansible voor RHEL: idempotent beheer en RHEL lifecycle en migratie.