“Je wist het, en je had kunnen handelen. Waarom heb je dat niet gedaan?”
Dit is de vraag die u niet wilt stellen. En het is steeds vaker de vraag die leiders na een incident moeten beantwoorden.
Jarenlang hebben veel executive teams en raden van bestuur een grote achterstand op het gebied van kwetsbaarheden behandeld als een ongemakkelijk maar aanvaardbaar gegeven: “we hebben het risico geaccepteerd.” Als je ooit een rapport hebt gezien met duizenden (of tienduizenden) openstaande Highs en Critical CVE’s, heb je waarschijnlijk ook de gebruikelijke rationalisaties gehoord van mensen die liever de andere kant op kijken: wij hebben andere prioriteiten, het zal jaren van technische tijd vergen om dit op te lossen, Hoe weet je dat deze echt cruciaal zijn? We stellen nog steeds prioriteiten, we komen er wel aan.
In de oude wereld was dat verhaal, hoewel niet goed, vaak te overleven. De exploitatie verliep langzamer, meer handmatig en vereiste meer vaardigheid van de operator. Zelfs de meest geavanceerde aanvallers hadden beperkingen. Organisaties baseerden zich op deze beperkingen als een onuitgesproken onderdeel van het risicomodel: “Als het echt zo erg was als je zegt, zouden we nu gecompromitteerd zijn.”
Die wereld is verdwenen.
AI heeft de exploitatiekosten doen dalen
We zien nu hoe bedreigingsactoren agentische AI-systemen gebruiken om de hele offensieve workflow te versnellen: verkenning, ontdekking van kwetsbaarheden, ontwikkeling van exploits en operationeel tempo. Anthropic gaf publiekelijk gedetailleerde informatie over het verstoren van een cyberspionagecampagne waarin aanvallers Claude gebruikten op manieren die hun snelheid en schaal aanzienlijk vergrootten, en ze waarschuwden expliciet dat dit soort mogelijkheden minder ervaren groepen in staat kan stellen werk te doen waarvoor voorheen veel meer vaardigheden en personeel nodig waren.
Als leiders op het gebied van beveiliging weten we dat AI aanvallers in staat stelt sneller te handelen. Maar nu verandert automatisering een achterstand in een wapen. In het oude model zou het hebben van 13.000 Highs in productie kunnen worden gerationaliseerd als een triageprobleem. In het nieuwe model kunnen aanvallers in aanzienlijk minder tijd overstappen van ketendetectie naar validatie en exploitatie. ‘We werken aan de achterstand’ klinkt niet langer als een strategie, maar begint als een excuus te klinken.
De gevaarlijkste zin in de bestuurskamer
“Maak je geen zorgen, de CISO regelt het.”
Ik heb de realiteit achter die zin geleefd. CISO’s kunnen programma’s bouwen, prioriteiten stellen, meetgegevens rapporteren en crossfunctioneel herstel aansturen, maar in veel ondernemingen is het kwetsbaarheidsprobleem structureel groter dan de verantwoordelijkheid van welke leidinggevende dan ook. Het is een systeemprobleem: verouderde afhankelijkheden, beperkingen op de releasesnelheid, kwetsbare productieomgevingen en beperkte technische middelen. Besturen kunnen het bestuur niet delegeren.
De Caremark-reeks van Delaware wordt vaak aangehaald in discussies over het toezicht van directeuren: besturen moeten over rapportagesystemen beschikken die zijn ontworpen om gevolgrisico’s aan het licht te brengen en moeten zich daadwerkelijk bezighouden met wat die systemen rapporteren. Het gaat er niet om bestuurders bang te maken met juridische theorieën. Het gaat erom het praktische bestuurspunt duidelijk te maken: als er in uw berichtgeving staat dat er ‘duizenden ernstige kwetsbaarheden openstaan’, is het de taak van het bestuur om toezicht uit te oefenen.
Wat besturen zouden moeten eisen (en hoe CISO’s zouden moeten antwoorden)
Als u bestuurslid bent, moet u op zoek gaan naar operationele waarheid. Concentreer u op de veerkracht van de technologie van uw bedrijf, niet alleen op naleving. En als u een leider op het gebied van beveiliging bent, zou u de besturingssystemen moeten creëren die daarvoor zorgen. Dit zijn de vragen die teams kunnen gebruiken om performatieve cyberbeveiliging te doorbreken:
- Hoe ziet ons programma voor kwetsbaarheidsbeheer er end-to-end uit?
- Hoeveel kwetsbaarheden (vooral kritieke en hoge punten) bestaan er momenteel in onze producten?
- Hoe lang heeft het afgelopen kwartaal geduurd om de nieuwe kritieke en hoogste punten volledig te herstellen? Het afgelopen jaar?
- Als er vandaag een nieuwe 0-dag zou worden ontdekt in ons bestverkopende product, hoe lang zou het dan duren voordat we klanten konden vertellen dat het veilig was?
- Wat zijn de kosten in dollars van onze huidige achterstand op het gebied van kwetsbaarheden? (Vermenigvuldig de manuren die moeten worden opgelost met de volledige engineeringkosten, en je krijgt een getal dat het bestuur kan bepalen.)
Zo maak je de achterstand tastbaar genoeg, zodat het leiderschap zich niet langer verschuilt achter abstracties.
“Sneller patchen” is geen volledig antwoord
Veel organisaties reageren op de druk van het bestuur door te beloven sneller te patchen. Dat helpt, totdat de productie kapot gaat.
Als noodpatches op betrouwbare wijze impact op de klant veroorzaken (en in sommige omgevingen is dat ook het geval), wordt u tot een vreselijke afweging gedwongen: blootstelling accepteren of downtime accepteren. De moderne onderneming heeft behoefte aan een model dat de frequentie en de straal van noodsaneringen reduceert, en niet een model dat alleen maar hetzelfde fragiele proces versnelt.
De realiteit van de toeleveringsketen: verplichtingen verschuiven
We zien de aansprakelijkheden verschuiven nu toezichthouders en rechtbanken zich richten op de hygiëne van de softwaretoeleveringsketen en operationele veerkracht.
In de EU is nu de Cyber Resilience Act (CRA) van kracht, waarvan de belangrijkste verplichtingen in december 2027 van kracht worden. Veel organisaties zullen te maken krijgen met sterkere verwachtingen ten aanzien van de omgang met kwetsbaarheden, ‘secure-by-design’-praktijken en verantwoordelijkheid gedurende de gehele levenscyclus van software.
Op het gebied van de financiële dienstverlening is de DORA (Digital Operational Resilience Act) in werking getreden, waardoor geharmoniseerd ICT-risicobeheer en operationele veerkrachtvereisten in de hele EU tot stand komen.
We zien deze dynamiek ook in de VS, waar nalatigheidsclaims worden ingediend in class action-rechtszaken tegen bedrijven, waarbij eisers een gebrek aan zorgvuldigheid aanvoeren dat tot datalekken heeft geleid.
Je kunt de achterstand door ontwerp terugdringen
In het tijdperk van door AI versnelde uitbuiting betekent ‘beheerd risico’ te vaak dat wordt aangenomen dat aanvallers zich in het tempo van gisteren zullen blijven bewegen.
Besturen moeten ophouden deze veronderstelling te aanvaarden. CISO’s moeten ophouden met te doen alsof ‘sneller patchen’ of het accepteren van risico’s voldoende is. En organisaties moeten investeren in het verminderen van de blootstelling aan kwetsbaarheden bij de bron, zodat het volgende auditrapport geen spreadsheet is van geaccepteerde risico’s, maar een bewijs van een steeds kleiner wordend aanvalsoppervlak.
Schaamteloze plug, dit is waar de aanpak van Chainguard is ontworpen om de wiskunde te veranderen: begin met standaard beveiligde softwarecomponenten die kwetsbaarheden vanaf het begin minimaliseren en de toename van kwetsbaarheden in de loop van de tijd verminderen. Dat betekent dat er minder kritieke bevindingen in uw omgeving terechtkomen, minder cycli van noodpatches en minder operationele verstoringen wanneer de volgende spraakmakende CVE zich voordoet.
Door de achterstand op het gebied van kwetsbaarheden en het herstelwerk structureel te verminderen, kunnen teams de engineeringtijd ombuigen van brandbestrijding zonder ROI naar innovatie met een hoge ROI die daadwerkelijk concurrentievoordeel en omzet oplevert.
Want als het vingerwijzen begint na de inbreuk, en iemand vraagt waarom het bedrijf ervoor heeft gekozen om met 13.000 Highs in productie te leven, is het enige verdedigbare antwoord: dat hebben we niet gedaan. Wij hebben het systeem veranderd.
Voor meer interessante inzichten en praktisch advies van – en voor – leiders op het gebied van engineering en beveiliging, kunt u zich abonneren op Unchained of contact opnemen voor meer informatie over Chainguard.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen doorQuincy Castro, CISO, kettingkast.
