Artificial Intelligence verandert softwareontwikkeling fundamenteel. Waar development vroeger draaide om handmatig coderen, zien we nu een sterke opkomst van AI-gedreven ontwikkeling, van code completion tot volledig gegenereerde applicaties. Deze trend, ook wel “vibe coding” genoemd, maakt het mogelijk om sneller dan ooit software te bouwen.

Maar die snelheid heeft een keerzijde.

In dit blog nemen we je mee in de belangrijkste risico’s van AI in softwareontwikkeling én hoe je deze beheerst zonder innovatie te remmen.

Wat is “vibe coding” en waarom groeit het zo snel?

Vibe coding is een nieuwe manier van ontwikkelen waarbij je AI-tools gebruikt om code te genereren op basis van natuurlijke taal. Je beschrijft wat je wilt bouwen, en de AI doet de rest, vaak met minimale controle of review.

De voordelen zijn duidelijk:

• Snellere time-to-market
• Lagere drempel voor development (ook voor niet-developers)
• Meer ruimte voor experiment en innovatie

AI wordt inmiddels breed ingezet voor codegeneratie, testing, documentatie en zelfs volledige applicatieontwikkeling.

Maar precies daar ontstaat ook een nieuw risicodomein.

De verborgen security-risico’s van AI-gegenereerde code

Hoewel AI-code vaak functioneel correct lijkt, is deze lang niet altijd veilig. Onderzoek laat zien dat een significant deel van AI-gegenereerde code kwetsbaarheden bevat.

De belangrijkste risico’s:

1. Onveilige code “by default”

AI-modellen zijn getraind op grote hoeveelheden publieke code, inclusief kwetsbare patronen. Hierdoor kunnen ze onbedoeld:

• verouderde libraries gebruiken
• kwetsbare authenticatiemechanismen genereren
• fouten maken zoals injection vulnerabilities

2. Gebrek aan context en begrip

AI begrijpt geen risico’s zoals een ervaren developer dat doet. Het schrijft code die werkt, maar niet per se veilig is.

3. Shadow development & citizen developers

Niet alleen developers gebruiken AI. Ook business users bouwen steeds vaker applicaties zonder security-kennis of controles.

Dit vergroot de attack surface aanzienlijk.

4. Data leakage risico’s

Het invoeren van broncode of gevoelige data in AI-tools kan leiden tot datalekken, zeker bij publieke modellen.

5. Versnelling van kwetsbaarheden

AI versnelt development – maar daarmee ook de snelheid waarmee kwetsbaarheden ontstaan en in productie komen.

AI verandert niet alleen development – maar ook je aanvalsvlak

Door AI verschuift het traditionele securitymodel. Waar security vroeger vooral gericht was op handgeschreven code, moet je nu rekening houden met:

• AI-gegenereerde code zonder duidelijke herkomst
• Dynamische en snel veranderende applicaties
• Nieuwe supply chain risico’s
• Onbekende of “verborgen” assets

Kortom: je attack surface groeit sneller dan ooit.

Hoe manage je de risico’s van AI in je SDLC?

AI uitzetten is geen optie. De vraag is dus niet óf je AI gebruikt, maar hoe je het veilig doet.

Een effectieve aanpak bestaat uit drie pijlers:

1. Governance: stel duidelijke kaders

Begin met het definiëren van een AI Acceptable Use Policy (AUP) voor developers, DevOps en business users.

Denk aan:

• Wat mag wel/niet met AI gegenereerd worden
• Welke data ingevoerd mag worden
• Welke controles verplicht zijn

Dit voorkomt ongecontroleerd gebruik en “shadow AI”.

2. Awareness & training

Security blijft mensenwerk. Zorg dat teams begrijpen:

• welke risico’s AI introduceert
• hoe ze veilige prompts schrijven
• waarom AI-output altijd gevalideerd moet worden

AI maakt development toegankelijker – maar security-expertise blijft essentieel.

3. Technologie: van detectie naar exposure management

Traditionele securitytools schieten tekort in een AI-gedreven omgeving. Organisaties moeten verschuiven naar een exposure management aanpak:

• Continue zichtbaarheid op assets en kwetsbaarheden
• Prioritering op basis van risico
• Integratie van security in de hele SDLC
• Monitoring van zowel bekende als onbekende assets

Platforms zoals Tenable One helpen organisaties om deze end-to-end zichtbaarheid en controle te realiseren.

Van reactief naar proactief: de nieuwe standaard

De grootste fout die organisaties kunnen maken, is AI behandelen als “gewoon een nieuwe tool”.

AI verandert het speelveld fundamenteel. Security moet daarom:

• eerder in het proces plaatsvinden
• geïntegreerd zijn in development workflows
• gericht zijn op risico’s vóórdat ze misbruikt worden

Oftewel: van reactief patchen naar proactief beheersen.

Conclusie: snelheid én veiligheid – je moet beide beheersen

AI biedt ongekende kansen voor innovatie en efficiëntie. Maar zonder de juiste controles introduceert het ook nieuwe, vaak onzichtbare risico’s.

De organisaties die winnen in dit nieuwe tijdperk zijn niet degenen die AI het snelst adopteren, maar degenen die het veilig en gecontroleerd doen.

De sleutel?
Combineer de kracht van AI met sterke governance, goed getrainde teams en een volwassen exposure management strategie.

The post AI in softwareontwikkeling: innovatie versnellen zonder je security uit het oog te verliezen appeared first on Access42.

Het centrale thema dit jaar is: Exposure First, met een sterke focus op Exposure Management én Human Risk. Cybersecurity draait vandaag de dag niet alleen om technologie. Het gaat om volledig inzicht in je aanvalsoppervlak én het begrijpen van de menselijke factor als cruciale schakel binnen je organisatie. Tijdens deze summitontdek je hoe je risico’s zichtbaar maakt, prioriteert en effectief aanpakt. Van kwetsbaarheden in systemen tot gedrag van gebruikers.

Met als keynote spreker: Lisa de Wilde

Met haar keynote: “Weerbaarheid begint pas echt wanneer de business begrijpt wat er op het spel staat.” laat zij zien waarom cybersecurity pas effectief wordt wanneer het niet alleen een IT-feestje is, maar een integraal onderdeel van de organisatie.

Dat geldt ook voor Exposure Management. Het in kaart brengen en prioriteren van risico’s raakt direct aan bedrijfsprocessen, continuïteit en strategische keuzes. Zonder betrokkenheid van management blijft het een technisch overzicht, terwijl de échte impact zit in businessrisico’s. Pas wanneer directie en management eigenaarschap nemen, ontstaat er draagvlak om de juiste prioriteiten te stellen en structureel weerbaarheid op te bouwen.

Wat kun je verwachten?

• Inspirerende keynote door Lisa de Wilde
• Inzichten in hoe je jouw attack surface continu in kaart brengt en beheerst
• Sessies over Human Risk en insider threats: van security awareness tot gedragsverandering
• Praktische handvatten om technologie en mens samen te brengen in je securitystrategie
• Netwerkmogelijkheden met vakgenoten en thought leaders

Of je nu verantwoordelijk bent voor IT, security, risk of compliance: deze dag helpt je om proactief controle te krijgen over je risico’s.

 Locatie: Prodentfabriek, Amersfoort
 Datum: 4 juni 2026

Wil jij weten waar jouw grootste risico’s écht liggen en hoe je ze vóór kunt zijn?

Schrijf je nu in!

We kijken ernaar uit je te verwelkomen!

Met vriendelijke groet,

Team Access42

We zien je graag op 4 juni!

P.S.: Heb je de Cybersecurity Summit nog niet eerder bezocht? Klik hier voor een impressie van ons event in 2025.

De Cybersecurity Summit 2026 wordt mede mogelijk gemaakt door:

The post Cybersecurity Summit 2026 – Exposure First appeared first on Access42.

Cloud security en de lessen van de EC-hack

Hoewel interne systemen van de Commissie gespaard bleven, wijst de diefstal van databases op het belang van een gelaagde defensieve strategie. Bij Access42 adviseren we organisaties om niet blind te varen op de standaardbeveiliging van cloudproviders. Het incident met de EC herinnert ons eraan dat configuratiefouten of gelekte inloggegevens de deur wagenwijd openzetten, ongeacht de reputatie van de provider. Door inzet van Managed Security Services kunnen organisaties afwijkend gedrag in hun cloudomgeving direct detecteren en indammen voordat honderden gigabytes aan data de organisatie verlaten.

Hoe voorkomt u grootschalige datadiefstal?

Vragen over hoe een aanvaller onopgemerkt 350GB kan wegsleisen zijn terecht. Het antwoord ligt vaak in een gebrek aan fijnmazige monitoring op data-exfiltratie. Een effectief Security Operations Center (SOC) signaleert dergelijke ongebruikelijke datastromen in real-time. Door gebruik te maken van technieken zoals Network Detection & Response (NDR) en Endpoint Detection & Response (EDR), wordt het voor kwaadwillenden vrijwel onmogelijk om grote hoeveelheden informatie te verplaatsen zonder dat er alarmbellen afgaan bij onze analisten.

De rol van proactieve testen en pentesting

Het is niet de vraag of u doelwit wordt, maar wanneer. De hacker in de EC-case deelde schermafbeeldingen van e-mailservers, wat duidt op diepgaande toegang. Met de penetratietesten van Access42 simuleren wij exact dit soort aanvallen om zwakke plekken in uw AWS- of Azure-omgeving te vinden voordat een echte aanvaller dat doet. Onze aanpak gaat verder dan een momentopname; met continuous pentesting houden we uw digitale weerbaarheid het hele jaar door op het hoogste niveau.

Compliance en de impact van de Cyberbeveiligingswet

Incidenten zoals deze hebben directe gevolgen voor de naleving van wetgeving zoals de NIS2 en de Nederlandse Cyberbeveiligingswet. Organisaties moeten kunnen aantonen dat zij passende maatregelen hebben genomen om incidenten te voorkomen en de impact te minimaliseren. Access42 helpt u niet alleen bij het technisch dichtzetten van de omgeving, maar ondersteunt ook bij de rapportage en compliance-eisen. Een robuust beveiligingsbeleid beschermt niet alleen uw data, maar voorkomt ook bestuurlijke aansprakelijkheid en reputatieschade na een eventuele inbreuk.

Directe actie bij security incidenten

Heeft uw organisatie te maken met een verdachte situatie of wilt u uw huidige cloudbeveiliging laten toetsen door experts? Wacht niet tot de data op straat ligt. Bij Access42 staan we klaar om uw omgeving door te lichten en te bewaken. Voor acute hulp kunt u direct een security incident melden bij ons team, zodat we direct kunnen starten met mitigatie en onderzoek om verdere schade te beperken.

The post Cyberaanval op Europese Commissie: De noodzaak van robuuste cloudbeveiliging appeared first on Access42.

Hoe het kon gebeuren

Je zou verwachten dat een groot telecombedrijf zijn systemen hermetisch heeft afgesloten. Maar de aanval was geen geavanceerde technische operatie. De hackers maakten gebruik van phishing en social engineering om toegang te krijgen tot een Salesforce-omgeving waarin klantgegevens waren opgeslagen. Ze manipuleerden medewerkers om inloggegevens af te geven, waarna ze toegang kregen tot het volledige klantcontactsysteem. Geen firewall ter wereld beschermt je tegen een medewerker die goedwillig zijn wachtwoord doorgeeft.

Wat er precies is gelekt

De dataset is zorgwekkend breed. Het gaat om namen, adressen, e-mailadressen, telefoonnummers, geboortedata, bankrekeningnummers en nummers van identiteitsbewijzen. Maar wat de situatie extra ernstig maakt, zijn de interne klantnotities die ook zijn buitgemaakt. Notities bedoeld voor intern gebruik zijn nu in handen van criminelen. Odido had dit aanvankelijk niet aan klanten laten weten en leek zelf ook verrast dat deze informatie onderdeel uitmaakte van de gestolen data.

Losgeld betalen of niet

ShinyHunters eiste een bedrag van meer dan een miljoen euro en gaf Odido een deadline tot 26 februari. Odido weigerde te betalen, op advies van cybersecurityexperts en overheidsinstanties, omdat onderhandelen met criminelen criminaliteit stimuleert. Op zich een principieel en verdedigbaar standpunt. Maar de gevolgen zijn concreet en pijnlijk: volgens Security.nl begonnen de hackers daarna data te publiceren op het dark web, waarbij op 26 februari de gegevens van zo’n 430.000 personen en 290.000 bedrijven openbaar verschenen.

Of Odido de juiste keuze heeft gemaakt valt te betwisten. De reputatieschade, juridische risico’s en maatschappelijke impact zijn aanzienlijk. Tegelijkertijd is het ook zo dat betalen geen garantie geeft dat criminelen de data verwijderen of niet opnieuw toeslaan.

Wat dit betekent voor getroffen klanten

De directe risico’s zijn serieus. Met een combinatie van naam, adres, geboortedatum, bankrekeningnummer en paspoortnummer kunnen criminelen zeer geloofwaardige phishingaanvallen uitvoeren, identiteitsfraude plegen of nep-incasso’s versturen. Het Centraal Meldpunt Identiteitsfraude zag het aantal meldingen in korte tijd meer dan verdubbelen.

Als compensatie biedt Odido twee jaar gratis toegang tot F-Secure beveiligingssoftware aan. Dat is beter dan niets, maar het lost het kernprobleem niet op: je geboortedatum en paspoortnummer kun je niet zomaar wijzigen.

De les die niemand wil trekken

De Odido-hack is geen incident. Het is een symptoom. Bedrijven met enorme hoeveelheden klantdata investeren structureel te weinig in twee dingen: het beperken van toegangsrechten en het trainen van medewerkers op social engineering. In dit geval hadden klantenservicemedewerkers toegang tot een systeem met data van miljoenen mensen, en was het mogelijk om via phishing die toegang te onderscheppen.

De technische beveiliging was waarschijnlijk prima in orde. Maar menselijke handelingen vallen buiten het bereik van techniek, tenzij je systemen zodanig ontwerpt dat één gecompromitteerd account niet direct toegang geeft tot de volledige klantendatabase. Dat principe, least privilege access, is al jaren bekend en wordt nog altijd stelselmatig genegeerd in de praktijk. Met exposure management breng je structureel in kaart waar je organisatie kwetsbaar is, voordat een aanvaller dat doet.

Wat je nu het beste kunt doen als bedrijf

Als klant van Odido of Ben: ga uit van het worst case scenario, controleer je accounts en wees extra alert op verdachte berichten die persoonlijke informatie bevatten. Zet tweefactorauthenticatie aan op al je belangrijke accounts.

Als organisatie is dit het moment om je eigen beveiliging kritisch te bekijken. Wie heeft toegang tot welke systemen? Zijn die rechten nog proportioneel? Weet je hoe je medewerkers reageren als iemand belt die zegt van de IT-afdeling te zijn? Een penetratietest geeft je een eerlijk beeld van waar je organisatie kwetsbaar is, inclusief de menselijke kant. En voor organisaties die continu inzicht willen in wat er op hun netwerk gebeurt, biedt een Security Operations Center de monitoring en detectie die je nodig hebt om snel in te grijpen als er iets misgaat.

De hack bij Odido laat zien dat geen enkel bedrijf immuun is. De kwetsbaarheid zit zelden in de techniek. Het zit hem in mensen, processen en de aanname dat het met ons wel los zal lopen. Die aanname klopt niet.

The post De Odido-hack: wat er misging en wat het zegt over cybersecurity in Nederland appeared first on Access42.

In deze blog wil ik niet alleen mijn ervaring delen, maar ook uitleggen waarom Exposure Management zo cruciaal is voor organisaties vandaag de dag, en hoe Tenable dit concept concreet invult om cyberweerbaarheid te verhogen.

Van kwetsbaarheidsbeheer naar Exposure Management

Traditioneel denken organisaties vaak in termen van kwetsbaarheidsbeheer: CVE’s patchen, periodieke scans uitvoeren, firewalls configureren. Hoewel dit nog steeds belangrijk is, is het tegenwoordig onvoldoende. Het digitale landschap is enorm complex geworden: cloudomgevingen, mobiele apparaten, IoT, third-party services, AI-systemen, ze creëren voortdurend nieuwe paden waarlangs aanvallers binnen kunnen dringen.

Tenable introduceert daarom een bredere visie: Exposure Management. Dit gaat verder dan het simpelweg patchen van systemen. Het richt zich op zicht, grip en actie op het volledige digitale aanvalsoppervlak, inclusief identiteiten en toegangspaden naar kritische assets.

“Wie alleen CVE’s fixet, blijft reactief. Wie zijn blootstelling continu beheert, kan proactief risico’s reduceren en zijn aanvalsoppervlak verkleinen.” – Tenable Guardian Summit 2026

Exposure Management is een continu proces dat organisaties helpt om prioriteiten te stellen, risico’s te reduceren en sneller te reageren op nieuwe bedreigingen.

De kernstappen van Exposure Management

Exposure Management bestaat uit vijf belangrijke fasen, elk met een concreet doel en praktische toepassing:

1. Scoping

De eerste stap is bepalen wat er binnen scope valt. Dit gaat verder dan alleen servers en werkstations. Kritische assets, cloud-omgevingen, applicaties, databronnen en vooral identiteiten moeten in kaart worden gebracht.

Voorbeeld: een financiële dienstverlener kan tientallen applicaties hebben, waarvan slechts een paar directe toegang geven tot klantgegevens. Door deze applicaties expliciet in scope te nemen, wordt het duidelijk waar mitigatie prioriteit moet krijgen.

2. Discovery

Discovery richt zich op het in kaart brengen van alle assets en het externe aanvalsoppervlak. Dit omvat het detecteren van kwetsbaarheden, misconfiguraties en andere risico’s die een aanvaller kan exploiteren.

Praktijkvoorbeeld: een organisatie had honderden cloud-services, waarvan sommige verkeerd geconfigureerd waren. Discovery bracht dit aan het licht, waardoor preventieve maatregelen konden worden genomen voordat een echte aanval plaatsvond.

3. Prioritization

Niet elk risico is gelijk. Prioritization zorgt dat de organisatie zich richt op de risico’s die de grootste impact hebben en het meest waarschijnlijk zijn.

Bijvoorbeeld: een CVE op een intern systeem dat niet toegankelijk is van buitenaf kan laag op de prioriteitenlijst staan. Een misconfiguratie die toegang tot een kritische database geeft, staat bovenaan. Door prioriteiten helder te stellen, wordt tijd en budget efficiënt besteed.

4. Validation

Validation gaat over het verifiëren van geprioriteerde risico’s. Zijn de exposures echt, en vormen ze daadwerkelijk een risico zoals ingeschat?

Voorbeelden van validatie:

• Koppelen van kwetsbaarheden aan firewall rules om te controleren of het risico effectief wordt gemitigeerd.

• (Continuous) pentesten om te zien of kwetsbaarheden daadwerkelijk kunnen worden misbruikt.

Deze stap voorkomt dat tijd wordt verspild aan risico’s die theoretisch bestaan, maar in de praktijk niet exploiteerbaar zijn.

5. Action / Mobilization

De laatste stap is mobilization: zorgen dat risico’s worden opgelost. Dit kan worden gedaan door direct tickets aan te maken in workflowtools zoals Jira of ServiceNow, en door te monitoren dat mitigaties effectief zijn uitgevoerd.

Tenable maakt het mogelijk om alle risico’s op één plek te beheren, inclusief data van derden en pentestbevindingen. Zo ontstaat een geïntegreerd overzicht van exposures en hun status, van detectie tot mitigatie.

Waarom Exposure Management nu essentieel is

De noodzaak van Exposure Management wordt steeds duidelijker door de veranderende dreigingsomgeving:

1. Exponentieel groeiende attack surfaces – Cloud, mobiele apparaten, IoT en AI-systemen creëren continu nieuwe kwetsbaarheden.

2. Complexe en snel veranderende bedreigingen – Aanvallers richten zich op de zwakste punten en zoeken routes naar kritische assets.

3. Identiteiten als nieuwe kwetsbaarheden – Toegangspaden naar belangrijke systemen zijn vaak de grootste risico’s.

Volgens Gartner hebben organisaties die hun beveiligingsinvesteringen baseren op een continu Exposure Management-programma drie keer minder kans om slachtoffer te worden van een datalek.

Het is dus duidelijk: traditionele kwetsbaarheidsbeheerprogramma’s volstaan niet meer. Een dynamische, continue aanpak is nodig om cyberweerbaarheid te versterken.

AI en het Open Platform van Tenable

Tenable loopt voorop in het gebruik van AI en open data-integratie. Het Open Platform maakt het (nu en op termijn) mogelijk om data uit verschillende bronnen te combineren, bijvoorbeeld:

• CrowdStrike en Microsoft voor real-time detectie en endpointinformatie.

• Pentestbevindingen om ook niet-technische kwetsbaarheden inzichtelijk te maken.

• Workflowtools zoals Jira en ServiceNow voor directe mitigatie en opvolging.

AI helpt om patronen te herkennen, risico’s automatisch te prioriteren en trends te voorspellen. Zo wordt Exposure Management niet alleen efficiënter, maar ook proactiever.

Identiteiten zijn de nieuwe kwetsbaarheden

Een van de meest belangrijke inzichten van de summit: identiteiten vormen tegenwoordig de kern van risico’s. Organisaties fixen vaak CVE’s waar niemand bij kan, terwijl de echte risico’s lopen via toegangspaden tot kritische systemen.

Praktijkvoorbeeld: een organisatie had alle systemen gepatcht, maar een enkele account met hoge rechten werd misbruikt door een aanvaller. Dit leidde bijna tot een ernstige datalek. Exposure Management focust op het beveiligen van de echte paden naar de kroonjuwelen, oftewel identity-first security.

Exposure Management in de praktijk bij Access42

Bij Access42 passen we deze principes actief toe in onze CyberTIM SOC en managed diensten:

• Continu zicht op kwetsbaarheden in klantomgevingen, inclusief cloud-assets en identiteiten.

• Proactieve prioritering en mitigatie via integratie van diverse datastromen.

• Validation door combinatie van automatisering, threat intelligence en pentestdata.

• Directe mobilisatie via workflowtools zodat actie geen vertraging oploopt.

Deze aanpak maakt dat onze klanten niet alleen reactief beveiligd zijn, maar weerbaar tegen de dynamische dreigingen van vandaag en morgen.

Conclusie

De Tenable Guardian Summit heeft nogmaals bevestigd dat cybersecurity niet statisch is. Traditioneel kwetsbaarheidsbeheer volstaat niet meer. Wat nodig is, is continu, proactief en geïntegreerd Exposure Management.

Voor ons bij Access42 betekent dit dat we blijven investeren in kennis, tooling en processen, zodat onze klanten optimaal beschermd zijn. Het gaat niet langer alleen om het fixen van CVE’s, maar om het inzichtelijk maken en mitigeren van echte risico’s. Van assets tot identiteiten.

Exposure Management is daarmee niet alleen een tool of proces, maar een strategische visie voor moderne cybersecurity: zicht, grip en actie op alles wat ertoe doet.

–Ronald Kingma

The post Vanuit de Tenable Guardian Summit: Waarom Exposure Management de kern is van moderne cybersecurity appeared first on Access42.

De conclusie is onvermijdelijk: het klassieke SOC-model is niet langer toereikend.

In 2026 draait cybersecurity niet meer om het managen van alerts, maar om het beheersen van exposure. Exposure management vormt daarbij de verbindende schakel tussen preventie, detectie, validatie en respons.

AI versnelt dreigingen en legt de zwakte van traditionele SOC’s bloot

AI verandert cyberaanvallen niet fundamenteel, maar maakt bestaande technieken:

• sneller
• schaalbaarder
• consistenter

Phishing, credential abuse, misbruik van kwetsbaarheden en laterale beweging gebeuren in 2026 op AI-tempo. Voor SOC’s betekent dit dat time-to-detect alleen niet meer voldoende is. Als een aanval binnen minuten van initiële toegang naar impact gaat, is reactieve detectie per definitie te laat.

Veel SOC’s in Nederland zijn nog traditioneel ingericht rondom:

• SIEM-alerts
• handmatige triage
• ticketgedreven workflows
• lineaire escalatie

Dat model kraakt onder de druk van AI-gedreven aanvallen

Van detectie naar exposure management: een noodzakelijke verschuiving

De centrale vraag in cybersecurity verschuift:

Van:

“Zien we het incident?”

Naar:

“Hadden we dit risico überhaupt moeten laten bestaan?”

Exposure management richt zich niet op losse kwetsbaarheden of alerts, maar op het totale aanvalsoppervlak:

• kwetsbaarheden
• cloud-misconfiguraties
• identity exposure
• aanvalspaden richting kroonjuwelen

Voor SOC’s betekent dit een fundamenteel andere manier van werken:

• minder focus op volume
• meer focus op exploiteerbaar risico
• prioritering op basis van context en impact

In een wereld waarin AI aanvallen versnelt, is preventief inzicht in exposure de enige manier om structureel voor te blijven.

Cloud en identity: waar exposure zich opstapelt

Nederlandse organisaties zijn volwassen in cloudadoptie, maar cloudbeveiliging is vaak versnipperd. Cloud security, IAM en SOC opereren regelmatig als losse disciplines. Juist daar ontstaat exposure.

Met name machine-identiteiten vormen in 2026 een structureel risico:

• service accounts
• API-keys
• tokens
• CI/CD-identiteiten

Deze identiteiten:

• zijn talrijker dan menselijke accounts
• hebben vaak te brede rechten
• worden nauwelijks gemonitord

Voor aanvallers zijn ze ideaal: stil, persistent en moeilijk te detecteren.

Exposure management verbindt cloud en identity en maakt zichtbaar:

• welke identiteiten toegang hebben tot welke assets
• welke misconfiguraties leiden tot privilege escalation
• welke aanvalspaden daadwerkelijk realistisch zijn

Voor het SOC betekent dit: context vóórdat er een alert is.

Automated remediation: onmisbaar, maar alleen met exposure-context

Automatische respons was lang spannend. De angst voor verstoringen overheerste. In 2026 is automatisering geen luxe meer, maar een voorwaarde om bij te blijven.

Belangrijk daarbij is:
automatisering zonder context is gevaarlijk.

Exposure management levert die context:

• wat is het risico?
• wat is de impact?
• hoe urgent is ingrijpen?

Hierdoor kan automated remediation gericht worden ingezet, bijvoorbeeld:

• automatisch intrekken van misbruikte tokens
• isoleren van endpoints
• verlagen van (cloud-)privileges
• corrigeren van kritieke misconfiguraties

Het SOC verschuift van uitvoerder naar regisseur van geautomatiseerde verdediging.

Van inzicht naar bewijs: de rol van pentesten en BAS

Exposure management laat zien waar risico’s zitten. Maar inzicht alleen is niet genoeg. In 2026 moeten organisaties aantonen dat risico’s:

1. daadwerkelijk misbruikt kunnen worden

2. worden gedetecteerd en gestopt

Hier komen penetratietesten en Breach & Attack Simulation (BAS) in beeld.

Penetratietesten: bewijzen wat écht exploiteerbaar is

Pentesten verschuiven van jaarlijkse checklist naar:

• risicogedreven inzet
• focus op kroonjuwelen, cloud en identity
• verdieping op specifieke exposure

Pentesten leveren:

• bewijs van exploitability
• inzicht in chaining van zwakheden
• menselijke creativiteit die tools missen

Voor het SOC zijn pentests geen eindrapport, maar input voor verbetering.

Breach & Attack Simulation: werkt het SOC ook echt?

BAS richt zich niet op of iets kan worden misbruikt, maar op:

“Zien en stoppen we dit ook?”

In een SOC dat steeds verder automatiseert, is continue validatie cruciaal:

• testen van MITRE ATT&CK-technieken
• valideren van SIEM-, EDR- en cloud-detecties
• meten van time-to-detect en time-to-respond
• testen van automated remediation zonder echte schade

BAS maakt SOC-effectiviteit meetbaar en herhaalbaar.

De gesloten cyclus van het SOC van 2026

Samen vormen exposure management, pentesten en BAS een continue verbetercyclus:

1. Exposure management identificeert structurele risico’s
2. Penetratietesten valideren exploitability
3. BAS test detectie en respons
4. SOC optimaliseert detecties en playbooks
5. Exposure management meet of risico’s daadwerkelijk zijn afgenomen

Dit is geen losse tooling, maar een volwassen operationeel model.

De Nederlandse realiteit: NIS2 en schaarste dwingen tot volwassenheid

Voor Nederlandse organisaties is deze ontwikkeling extra relevant:

• NIS2 vraagt om aantoonbare werking van detectie en respons
• Audits accepteren geen “we hadden het niet gezien”
• Securitytalent is schaars
• Handmatig werken schaalt niet

Exposure-gedreven SOC’s maken:

• risicogebaseerde keuzes
• automatisering verantwoord inzetbaar
• security aantoonbaar effectief

Conclusie: het SOC van 2026 managed geen alerts, maar exposure

Cybersecurity in 2026 draait niet om harder werken, maar om slimmer organiseren. AI versnelt aanvallen, cloud vergroot complexiteit en identiteit vervangt de perimeter. In die realiteit is een reactief SOC niet langer voldoende.

Het SOC van de toekomst:

• stuurt op exposure
• valideert continu
• automatiseert met context
• en maakt cyberweerbaarheid aantoonbaar

Exposure management is geen extra discipline. Het is het fundament onder het moderne SOC.

The post Cybersecurity in 2026: waarom exposure management het fundament wordt van het SOC in Nederland appeared first on Access42.

Eén ingang.

Eén kwetsbaarheid.

Eén aanval is genoeg.

Met Pentesting, Exposure Management, 24/7 monitoring, snelle detectie en effectieve incident response helpt Access42 organisaties ransomware voor te blijven.

Santa’s watching. So are we.

 

Veilige feestdagen gewenst.

 

The post Veilige feestdagen gewenst. appeared first on Access42.

Op 3 december 2025 heeft het team van React een ernstige kwetsbaarheid bekendgemaakt: CVE-2025-55182. Deze bug, React2Shell, treft de “React Server Components” (RSC) en maakt het mogelijk om zonder authenticatie remote code uit te voeren op een server.

Wat houdt de kwetsbaarheid in?

• De fout zit in onveilige deserialisatie van data binnen de RSC-protocol (“Flight”).

• Een aanvaller kan via een speciaal gemaakte HTTP-request (payload) willekeurige server-side JavaScript-code uitvoeren — ook als er geen expliciete “Server Function”-endpoints gebruikt worden.

• Dit geldt niet alleen voor React zelf, maar ook voor frameworks die React gebruiken — bijvoorbeeld Next.js. Voor Next.js is de bijbehorende identifier CVE-2025-66478. Welke versies zijn kwetsbaar?

De kwetsbaarheid treft de volgende React-RSC-pakketten in deze versies: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack versies 19.0, 19.1.0, 19.1.1 en 19.2.0.

Daarnaast zijn ook bepaalde versies van Next.js (met App Router) kwetsbaar.

Hoe ernstig is het?

Zeer ernstig — de kwetsbaarheid is ingeschaald op CVSS score 10.0: maximale ernst.
Dat is mede zorgwekkend omdat populaire webapps vaak (gedeeltelijk) draaien op React / Next.js — dus veel omgevingen kunnen kwetsbaar zijn.

Is het al misbruikt?

Volgens de laatste melding (3 december 2025) zijn er nog geen bevestigde gevallen van in-the-wild exploitatie van CVE-2025-55182. Het team dat de kwetsbaarheid ontdekte houdt de situatie nauwlettend in de gaten.

Er circuleren wel onbevestigde meldingen van pogingen tot misbruik.

Wat kun je doen om je applicatie te beschermen?

• Update direct naar de gepatchte versies: voor React-RSC: react-server-dom-webpack / parcel / turbopack naar 19.0.1, 19.1.2 of 19.2.1. Voor Next.js: bijvoorbeeld 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 of 16.0.7 (afhankelijk van je versie).

• Controleer of je applicatie überhaupt React Server Components gebruikt — ook als je geen expliciete Server Function-endpoints hebt, want het kan toch kwetsbaar zijn.

• Overweeg extra veiligheidsmaatregelen (web-application firewall, strengere input-validatie of deserialisatie) tot je hebt geüpdatet — sommige partijen (zoals Fastly) bieden bijvoorbeeld virtual patches of detectieregels aan.

Waarom React2Shell een big deal is

• De kwetsbaarheid is “low-complexity”: een aanvaller heeft alleen een kwaadaardige HTTP-request nodig — geen login, geen extra fouten, niets. Dit maakt het extra gevaarlijk.

• Omdat veel projecten gebruikmaken van React / Next.js (of frameworks daarop), is de potentiële impact dus breed — veel servers draaien mogelijk kwetsbare applicaties.

• Zelfs apps die “zomaar” een standaard setup hebben, kunnen kwetsbaar zijn — je hoeft niets speciaals geconfigureerd te hebben.

React2Shell Veiligheids-checklist

Is mijn React / Next.js app kwetsbaar?

Gebruik je React Server Components?

Controleer in je project of je RSC gebruikt:

• Staat er ergens in je project .server.js of .server.jsx?

• Gebruik je use server in je code?

• Gebruik je het App Router-model van Next.js (map /app)?

• Gebruik je het Flight-protocol (bij Next.js automatisch bij App Router)?

Zo ja → mogelijk kwetsbaar.

Welke versies van React Server DOM packages gebruik je?

Controleer in package.json of je één van deze pakketten hebt:

• react-server-dom-webpack

• react-server-dom-parcel

• react-server-dom-turbopack

Zijn deze versies 19.0, 19.1.0, 19.1.1 of 19.2.0?
Dan ben je kwetsbaar.

Veilige versies:

• 19.0.1

• 19.1.2

• 19.2.1

Gebruik je Next.js?

Controleer of je Next.js gebruikt in combinatie met de App Router (/app-folder).

Kwetsbare versies liggen in vrijwel alle branches van Next 15 en 16.

Veilige versies (patches):

• 15.0.5

• 15.1.9

• 15.2.6

• 15.3.6

• 15.4.8

• 15.5.7

• 16.0.7

Upgraden is verplicht om niet kwetsbaar te blijven.

Draait je app een omgeving waarin RSC publiek toegankelijk is?

Voorbeelden:

• Next.js App Router zonder extra API-gateway of WAF

• React Server Components endpoint via /react of interne Flight-routes

• Server staat publiek op internet (IP of domain)

Als de server request-payloads accepteert, ben je kwetsbaar.

Gebruik je custom middleware of proxies?

Sommige proxies (zoals Nginx, Vercel of Node middlewares) loggen of muteren request-bodies.

Controleer of:

• Je middleware request-streams doorgeeft

• Je body-parsing zonder limieten toestaat

• Je requests doorlaat naar RSC zonder controles

Zo ja → risico op exploitatie is hoger.

Heb je al logs gecheckt op mogelijke exploitpogingen?

Let op:

• Onbekende POST-requests naar RSC-endpoints

• Requests met ongebruikelijke headers zoals rsc-action

• Probing of fuzzing-patronen (lange strings, veel JSON, onbekende methodes)

Als je dit ziet → patchen én monitoren.

Heb je al gepatcht, maar nog geen build/test gedaan?

Na patching:

• Voer een volledige rebuild uit

• Herstart servers

• Test zowel server actions als RSC rendering

• Controleer CI/CD-lockfiles (package-lock.json, yarn.lock)

Veel teams patchen wél, maar vergeten dat hun lockfile nog de oude versies pinned heeft.
Dan blijft je app kwetsbaar.

Heb je een tijdelijke beveiligingsmaatregel?

Tot je update, kun je:

• WAF-regels gebruiken (bijv. Fastly, Cloudflare)

• Traffic limiter op payload size

• Alleen bekende origins toelaten

• Verdachte headers blokkeren

Dit vervangt geen patch, maar beperkt risico’s.

Conclusie

Je app is waarschijnlijk kwetsbaar als:

• Je React Server Components gebruikt

• Je React RSC-packages in de 19.0–19.2 range hebt

• Je Next.js App Router gebruikt

• Je nog niet naar de nieuwste patchlevels hebt geüpdatet

The post React2Shell: Kritieke kwetsbaarheid in React Server Components appeared first on Access42.

Tim Senders onderzoekt hoe hackers slimme apparaten kunnen misbruiken

Webserie  onderdeel van overheidscampagne ‘Doe je Updates’

DEN HAAG, 13 oktober 2025 – In de nieuwe online serie ‘Hoe slim is jouw huis’ onderzoekt programmamaker Tim Senders samen met ethisch hacker Dylan hoe kwetsbaar slimme apparaten in huis kunnen zijn voor cybercriminelen. De afleveringen maken op toegankelijke en visuele wijze duidelijk waarom het belangrijk is om deze apparaten regelmatig te updaten.

Tim Senders is een veelzijdige presentator en programmamaker, bekend van o.a. Streetlab, Willem Wever en Factcheckers (KRO-NCRV). In laatstgenoemd programma onderzocht hij al eerder of babyfoons makkelijk te hacken zijn — een onderwerp dat in deze serie opnieuw terugkomt.

Webserie Doe je Updates

De webserie is onderdeel van de overheidscampagne Doe je Updates en bestaat uit korte video’s waarin Tim met een ethisch hacker op bezoek gaat bij bewoners in verschillende Nederlandse huishoudens. Samen kijken ze naar apparaten zoals een slimme babyfoon, smart tv of slim slot, en laten ze zien hoe eenvoudig sommige daarvan te hacken zijn – mits ze niet goed zijn beveiligd.

De opnames zijn gemaakt in samenwerking met een student (Bas), een moeder (Charlotte) en een echte liefhebber van slimme apparaten (Ruben), die vooraf toestemming gaven om hun huis en apparaten beschikbaar te stellen. De hacks zijn bedoeld om te laten zien welke risico’s slimme apparaten met zich mee kunnen brengen – en hoe je die met eenvoudige updates kunt verkleinen.

Minister Karremans beet vorige week het spits af

Demissionair minister Karremans van Economische Zaken liep vorige week zelf een zogeheten hackstage bij cybersecuritybedrijf Access42, waarbij hij uitleg kreeg over de risico’s van slecht beveiligde routers en slimme apparaten. Deze stage vormde de aftrap van de bredere campagne. Een korte videoweergave hiervan is HIER te vinden.

Volgens het recent verschenen onderzoek Alert Online 2025 gebruikt inmiddels 89% van de Nederlanders ten minste één slim apparaat in huis. Toch wordt een aanzienlijk deel van die apparaten niet altijd van updates voorzien. Hierdoor zijn naar schatting meer dan 2,5 miljoen apparaten in Nederland op enig moment niet up-to-date – en dus kwetsbaar voor misbruik.

De serie Laat je niet hacken is vanaf maandag onder andere online te zien op doejeupdates.nl.

The post ‘Doe je Updates’ appeared first on Access42.

DORA wil dat organisaties niet alleen weten of ze kwetsbaar zijn, maar ook hoe goed ze zich staande houden wanneer het écht gebeurt.

TLPT – TL;DR

Een TLPT is een gesimuleerde aanval die:

• gebaseerd is op actuele dreigingen;

• zich richt op kritieke functies;

• en niet aangekondigd is bij de organisatie (black box).

Het doel is niet alleen om kwetsbaarheden te vinden, maar om de detectie- en responsprocessen van de organisatie te toetsen.

Wat is TLPT precies?

Een TLPT is een gesimuleerde aanval op de organisatie, gebaseerd op actuele dreigingen en gericht op kritieke functies. In tegenstelling tot standaard pentests is een TLPT vaak een black box-test, waarbij de organisatie niet weet wanneer of hoe de aanval plaatsvindt.

Het doel is niet alleen om kwetsbaarheden te ontdekken, maar ook om de detectie- en responscapaciteit van de organisatie te meten. Hoe snel wordt een aanval gesignaleerd? Hoe effectief is de reactie? En hoe goed herstellen systemen en processen?

De drie hoofdrollen binnen TLPT

Om de resultaten realistisch en objectief te houden, schrijft DORA een duidelijke rolverdeling voor:

1. Threat Intelligence Provider (OSINT / CTI-partij)
   Deze partij verzamelt en analyseert informatie over relevante dreigingen en actoren. Het resultaat is een Targeted Threat Intelligence (TTI) Report dat dient als basis voor de Red Team-test. Hierbij wordt gebruikgemaakt van advisories, nieuws, MITRE ATT&CK-technieken en sector-specifieke dreigingsinformatie.

2. Red Team (Testuitvoerder)
   Het Red Team ontwikkelt aanvalsscenario’s op basis van het TTI-rapport en simuleert deze aanvallen op de organisatie. Dit gebeurt zonder voorkennis bij de defenders, zodat de test realistisch is en objectieve inzichten oplevert.

3. Blue Team / Defender (Organisatie zelf)
   De interne verdedigers reageren in real-time op de aanval. Ze worden pas na afloop betrokken bij de evaluatie, waarin lessons learned en verbeterpunten worden gedeeld.

Belangrijk: de TTI-provider en het Red Team moeten onafhankelijk van elkaar opereren. Zo blijft de test realistisch en wordt belangenverstrengeling voorkomen. Binnen Access42 waarborgen we die onafhankelijkheid door een externe partij de OSINT/CTI uit te laten voeren. We werken vanuit Access42 vaak samen met Centrum voor Cybersecurity Veiligheid en Technologie (CCVT). De CTI informatie die aangeleverd wordt stelt ons vanuit Access42 in staat om relevante aanvalsvectoren en scenario’s uit te werken.

OSINT/CTI van CCVT

Een TLPT is zo realistisch als de informatie waarop hij is gebaseerd. Zonder actuele threat intelligence wordt een TLPT al snel een theoretische oefening.

Het CCVT levert OSINT/CTI en verrijkt TLPT op drie manieren:

1. Realisme:
   Scenario’s zijn gebaseerd op actuele dreigingen, malwarecampagnes en sectorspecifieke actoren.

2. Relevantie:
   Door filtering op sector, technologie en geografie worden alleen de meest waarschijnlijke aanvalspaden getest.

3. Continuïteit:
   TLPT is een momentopname, maar CTI levert een continue stroom van informatie die ook na de test gebruikt kan worden voor monitoring, detectie en awareness.

Kortom: zonder CTI is TLPT slechts een pentest met een ander label.

Hoe een CTI-platform TLPT ondersteunt

Een goed CTI-platform levert meer dan ruwe data; het biedt context, prioritering en integratie:

• Data-acquisitie: automatische verzameling van advisories, nieuws, incidentmeldingen en OSINT.

• Verrijking: koppeling aan MITRE ATT&CK, CVE’s, malwarefamilies, threat actors, sectorspecifieke tags en risk scores.

• Toepassing: selectie van relevante aanvalsvectoren voor TLPT en scenario-ontwerp.

Zo ontstaat een brug tussen strategische dreigingsinformatie en tactische testuitvoering.

Conclusie – van verplichting naar kans

DORA verplicht TLPT, maar organisaties die het goed aanpakken halen er veel meer uit dan een vinkje op de checklist. Een threat-led test, gevoed door actuele CTI, geeft een realistisch beeld van de digitale veerkracht van de organisatie en laat zien waar de echte gaten vallen.

TLPT is geen compliance-tool, maar een stresstest voor je cyberweerbaarheid.
Met de juiste CTI aan de basis wordt die stresstest een bron van inzicht, niet van verrassing.

The post DORA, OSINT, CTI, TLPT…. wat moeten we doen? appeared first on Access42.