De softwarebeveiliging bevindt zich in een oneerlijke race. Kunstmatige intelligentie maakt het mogelijk om kwetsbaarheden sneller op te sporen, tests te automatiseren en grote codebases te analyseren op schaal die voorheen onmogelijk leek. Het probleem is dat deze snelheid ook de aanvallers bevoordeelt. Tussen het identificeren, valideren, communiceren, patchen, testen en uitrollen van een kwetsbaarheid kan een organisatie dagen, weken of zelfs maanden blootgesteld blijven.
IBM, Red Hat en Palo Alto Networks willen dat interval verkorten door de uitbreiding van Project Lightwell, een initiatief van IBM en Red Hat dat de beveiliging van open source software versterkt. De samenwerking voegt de mogelijkheid van virtual patching toe van Palo Alto Networks, zodat een bedrijf exploits in het netwerk kan blokkeren terwijl het de juiste softwarepatch test en implementeert.
Het concept wordt samengevat in een “beschermen en corrigeren”-model. Palo Alto Networks biedt bescherming op het netwerklaag om directe blootstelling te verminderen. IBM en Red Hat, via Project Lightwell, werken aan het remediëren van software, met name open source componenten die bedrijven kunnen testen en toepassen in hun omgevingen. Het is geen vervanging voor een echte patch, maar een manier om tijd te winnen wanneer de klok tegenzit.
Wanneer de patch te laat komt
Het beheer van kwetsbaarheden kent altijd een tijdsprobleem. Het ontdekken van een probleem is niet genoeg. Men moet bepalen of het relevant is voor de systemen, risico’s inschatten, prioriteiten stellen, patch testen, teams coördineren, onderbrekingen voorkomen en het patchproces zonder stilstand uitrollen. Bij grote organisaties verloopt dit proces zelden immediaat.
AI verscherpt de spanning omdat het zowel het defensieve ontdekkingproces als de offensieve zoekactie naar kwetsbaarheden kan versnellen. Palo Alto Networks vat het treffend samen: de window tussen ontdekken en uitbuiting is verkort van weken naar minuten. Hoewel dit een commerciële uitspraak bevat, weerspiegelt het wel een reële zorg: als aanvallers geautomatiseerd op zoek gaan naar kwetsbaarheden, kunnen organisaties niet meer reageren met langdurige, handmatige processen.
| Traditionele fase | Veelvoorkomend probleem |
|---|---|
| Ontdekking van de kwetsbaarheid | Toename in gedetecteerde defecten |
| Validatie | Niet alle meldingen hebben hetzelfde risico |
| Prioritering | Gebrek aan bedrijfscontext en echte blootstelling |
| Ontwikkeling van de patch | Afhankelijk van de leverancier of open source project |
| Testen | Productie mag niet worden gestoord door urgente correcties |
| Implementatie | Onderhoudsvensters, afhankelijkheden en gedistribueerde teams |
| Temporal protection | Veel bedrijven beschikken niet over een effectieve tussenlaag terwijl de patch wacht |
Hier komt virtual patching in beeld. Het wijzigt de kwetsbare software niet. Het biedt bescherming op netwerkniveau, doorgaans door regels, handtekeningen, inspectie of controles die bekende exploitpatronen blokkeren. De waarde ligt in het verminderen van blootstelling tot de definitieve correctie klaar is.
Wat voegt Palo Alto Networks toe aan Lightwell
Project Lightwell is ontstaan met een duidelijke focus: de toeleveringsketen van open source software die bedrijven gebruiken te versterken. IBM en Red Hat presenteerden het als een toezegging van 5 miljard dollar, ondersteund door kunstmatige intelligentie en meer dan 20.000 ingenieurs, om kwetsbaarheden in open source componenten te identificeren, valideren en corrigeren, van ontwikkeling tot productie.
De toevoeging van Palo Alto Networks verandert de operationele reikwijdte. Het gaat niet alleen meer om code verbeteren en gevalideerde patches leveren. Het doel is ook om netwerkverkeer te beschermen en exploits te blokkeren voordat het organisatie’s interne updateproces is voltooid.
| Bedrijf | Rol in de samenwerking |
| IBM | Project Lightwell, advies, prioritering en implementatiediensten |
| Red Hat | Expertise in bedrijfs-open source, validatie en remediering van software |
| Palo Alto Networks | Virtual patching en netwerkbescherming tegen exploits |
| Klanten | Testen, uitrollen en valideren van patches in hun omgevingen |
| Deelnemende leveranciers | Veilig informeren over kwetsbaarheden |
De samenwerking streeft er ook naar om een bredere scope te dekken: open source software, commerciële applicaties, OT-omgevingen, verbonden apparaten en medische technologieën. Deze bredere aanpak is relevant omdat veel organisaties geen duidelijke scheidslijn meer hebben tussen IT, cloud, OT, medische apparaten en moderne software.
In bijvoorbeeld een industriële setting, ziekenhuis of kritieke infrastructuur is patchen niet altijd zo eenvoudig als een pakket bijwerken. Sommige systemen vereisen certificering, uitgebreide tests, specifieke tijdvensters of coördinatie met leveranciers. In zulke gevallen kan tijdelijke netwerkbescherming helpen het risico te beperken zonder essentiële processen stil te leggen.
De belofte van “shield-and-fix”
Het “shield-and-fix”-model is zinvol als het wordt gezien als een opeenvolging, niet als een excuus. Eerst wordt snel bescherming geboden om bekende exploits te blokkeren. Daarna wordt de kwetsbare software gecorrigeerd. Het eerste biedt tijd, het tweede lost de oorzaak op.
Dit onderscheid is belangrijk omdat virtual patching een vals gevoel van veiligheid kan geven als het als een permanente vervanging van de echte patch wordt gebruikt. Het blokkeren van een aanvalsvector betekent niet dat de kwetsbaarheid verdwenen is. Het dekt niet altijd varianten, interne exploits, payloadaanpassingen, bypasses of situaties waarin het netwerkverkeer niet langs de inspectie gaat.
| Voordeel van virtual patching | Limiet |
| Kan dezelfde dag worden ingezet | Maakt de software niet echt kwetsbaar |
| Reduceert blootstelling tijdens testen | Afhankelijk van netwerkzichtbaarheid en dekking |
| Geschikt voor OT, gezondheidszorg of moeilijk te updaten systemen | Maakt niet altijd alle vectoren af |
| Wint tijd voor beveiligingsteams | Mag geen permanente oplossing worden |
| Behoudt bedrijfscontinuïteit | Vereist opvolging en validatie |
De aanpak van IBM, Red Hat en Palo Alto Networks probeert precies dat gat te dichten. De initiële bescherming wordt niet geïsoleerd, maar gekoppeld aan inzichten in kwetsbaarheden, software remediering en consultancy om te prioriteren welke defecten echt belangrijk zijn voor het specifieke bedrijf.
Open source, AI en supply chain risico’s
Project Lightwell vertrekt vanuit een bekende realiteit: open source software vormt de basis van bijna alles. Besturingssystemen, containers, Kubernetes, frameworks, databases, libraries, AI-tools en cloudplatformen vertrouwen op open source componenten die worden onderhouden door gemeenschappen, bedrijven en teams met verschillende achtergronden. Die diversiteit is krachtig, maar brengt ook beveiligingsuitdagingen met zich mee.
Een kwetsbaarheid in een populaire library kan zich snel verspreiden over duizenden producten. Een probleem in een component dat door AI-tools of zakelijke applicaties wordt gebruikt, kan lang onopgemerkt blijven in onvolledige inventarissen. Bovendien, aangezien AI patroonherkenning versnelt, wordt de druk op onderhoudsteams en security teams groter, omdat ze grote aantallen kwetsbaarheden moeten monitoren en aanpakken.
IBM en Red Hat willen Project Lightwell positioneren als een soort bedrijfscompensatiemechanisme voor open source software: detecteren, valideren, corrigeren en met meer vertrouwen patches aanbieden. Door ook netwerkbescherming te integreren, ontstaat een vollediger responsivecyclus — van detectie tot tijdelijke mitigatie en uiteindelijke remediering.
De rol van IBM Consulting
De samenwerking omvat ook IBM Security Services. In de praktijk betekent dit dat het niet alleen draait om het krijgen van alerts en patches, maar vooral om te weten welke kwetsbaarheden het meeste risico vormen voor het bedrijf, waar de systemen staan, welke blootstelling er is, welke controles er actief zijn en welke stappen relatief veilig en effectief zijn voor herstel.
Veel bedrijven slagen er niet in stukjes informatie te vermijden of te prioriteren; ze ontvangen vaak té veel informatie zonder voldoende context. Prioritering wordt cruciaal in grote organisaties met duizenden assets, talrijke leveranciers, verouderde systemen en verspreide teams.
| Bedrijfsbehoefte | Waar de samenwerking op gericht is |
| Weten welke kwetsbaarheden belangrijk zijn | Risico- en blootstellingsgebaseerde prioriteiten |
| Beschermen vóór patchen | Virtual patching op netwerkniveau |
| Correctie van open source software | Remediatie via Project Lightwell |
| Voorkomen van onderbrekingen | Geleidelijke tests en gecontroleerde uitrol |
| Samenwerking met leveranciers | Veilige uitwisseling van informatie |
| Meten van daadwerkelijke exploitatie | Geanonimiseerde telemetry over aanvalspogingen |
De telemetriecomponent is eveneens belangrijk. Bedrijven stellen voor om anoniem informatie te delen over werkelijke aanvalspogingen. Goed beheerd kan dat helpen om echte bedreigingen te scheiden van theoretische kwetsbaarheden. Slecht beheer kan echter zorgen baren over privacy, afhankelijkheid van leveranciers en controle over securitygegevens.
Een noodzakelijke samenwerking, maar met open vragen
De uitbreiding van Project Lightwell komt op een logisch moment. Het aantal kwetsbaarheden groeit, open source software is nog belangrijker geworden, en AI versnelt de snelheid van de dreiging. Het integreren van tijdelijke bescherming en gevalideerde correcties kan organisaties ondersteunen die nu vastzitten tussen urgente meldingen en langzaam patchproces.
Toch is het belangrijk om dit initiatief niet als een magische oplossing te beschouwen. Beveiliging vereist meer dan een samenwerking tussen drie grote partijen. Het begint met een daadwerkelijke inventarisatie van assets, een bruikbare Software Bill of Materials (SBOM), afhankelijkheidsbeheer, segmentatie, observability, testprocedures, changemanagement, een patchcultuur en de mogelijkheid om verouderde software te verwijderen. Zonder die fundamenten kan zelfs goede netwerkbescherming slechts een laag blijven binnen een chaotische architectuur.
Daarnaast blijft de vraag hoe de samenwerking concreet vorm krijgt: welke producten worden geïntegreerd, welke klanten toegang krijgen, welke processen geautomatiseerd worden, hoe de dekking buiten Red Hat wordt gerealiseerd, op welke wijze kwetsbaarheden worden gedeeld met derden, wat de echte responstijden zijn en hoe virtual patching de uitrol van definitieve patches niet vertraagt.
De richtingen zijn duidelijk: cybersecurity kan kwetsbaarheden niet langer beschouwen als een lijst tickets die gesloten worden zodra er tijd voor is. AI versnelt zowel de ontdekking als de exploitatie. Defence moet de kloof verkleinen tussen weten dat een fout bestaat en beschermd zijn tegen die fout.
IBM, Red Hat en Palo Alto Networks beloven niet de kloof volledig te dichten. Ze proberen haar wel te verkleinen. Tegen 2026 kan dat een van de belangrijkste security-oorlogen in het bedrijfswezen worden.
Veelgestelde vragen
Wat is Project Lightwell?
Een initiatief van IBM en Red Hat dat de beveiliging van zakelijke open source software versterkt met behulp van kunstmatige intelligentie, validatie, engineering en kwetsbaarheidsremediatie.
Wat draagt Palo Alto Networks bij aan Lightwell?
Voegt virtual patching toe om exploits in het netwerk te blokkeren terwijl het patchproces wordt voorbereid, getest en uitgerold.
Wat is een virtual patch?
Een tijdelijke beveiligingsmaatregel op netwerk- of beveiligingslaag die misbruik van een kwetsbaarheid blokkeert zonder de software zelf aan te passen.
Vervangt virtual patching de echte patch?
Nee. Het vermindert wel snel de blootstelling, maar de kwetsbaarheid blijft bestaan totdat de software echt wordt gepatcht.
via: newsroom.ibm