Een kritieke kwetsbaarheid in PHP, tijdelijk onbereikbare overheidswebsites en organisaties die halsoverkop moeten uitzoeken welke systemen geraakt worden. Het recente PHP-incident maakt duidelijk waarom een actuele Software Bill of Materials (SBOM), dagelijkse kwetsbaarhedenmonitoring en goed leveranciersmanagement steeds belangrijker worden.
Op 21 oktober 2026 werden twee kritieke kwetsbaarheden in PHP bekendgemaakt: CVE-2026-109618 en CVE-2026-109619. Misbruik kon onder bepaalde omstandigheden leiden tot het uitvoeren van ongeautoriseerde code op servers.
De impact was direct zichtbaar. Verschillende overheidswebsites, waaronder DigiD.nl en MijnOverheid.nl, werden tijdelijk offline gehaald. De achterliggende DigiD-dienst bleef beschikbaar.
Ook bij Sigbar hield het incident ons bezig. Voor websites die wij beheren, moesten we snel vaststellen welke PHP-versies werden gebruikt, welke systemen mogelijk kwetsbaar waren en welke maatregelen nodig waren. De betrokken websites zijn gepatcht en aanvullend gecontroleerd op malware.
Juist op zulke momenten merk je hoe belangrijk een actueel overzicht is.
Want als er morgen een nieuwe kritieke kwetsbaarheid wordt ontdekt, wil je niet eerst moeten uitzoeken welke applicaties, frameworks en leveranciers mogelijk geraakt worden.
Je wilt direct weten: wat hebben we draaien, waar zit het risico en wie moet in actie komen?
Een PHP-versie is nog maar het begin
Veel organisaties weten welke applicaties of websites ze gebruiken. Maar weten ze ook uit welke software die applicaties bestaan?
Een website kan bijvoorbeeld draaien op PHP, met daarbovenop een CMS, tientallen libraries, plug-ins, frameworks en koppelingen met externe diensten. Die softwareonderdelen hebben allemaal hun eigen versies, afhankelijkheden en mogelijke kwetsbaarheden.
Het recente PHP-incident laat zien waarom dat belangrijk is. Een kwetsbaarheid in een veelgebruikte programmeertaal kan gevolgen hebben voor een groot aantal verschillende producten en diensten.
Dat probleem beperkt zich niet tot PHP.
Denk aan Log4j, OpenSSL, Java-libraries, JavaScript-packages, container images of componenten die via leveranciers in applicaties terechtkomen.
Wie alleen een lijst met applicatienamen bijhoudt, mist daarmee een belangrijk deel van het risicobeeld.
Wat is een Software Bill of Materials?
Een Software Bill of Materials, kortweg SBOM, is een gestructureerd overzicht van de softwarecomponenten waaruit een applicatie of softwareproduct bestaat.
Je kunt het vergelijken met de ingrediëntenlijst op een verpakking. Bij een applicatie wil je niet alleen weten dat er een CMS of webframework wordt gebruikt. Je wilt ook weten welke libraries, packages en andere afhankelijkheden onderdeel zijn van het product.
Een SBOM kan inzicht geven in:
- de gebruikte softwarecomponenten en versies;
- directe en indirecte afhankelijkheden;
- open-sourcelibraries en frameworks;
- de herkomst en leveranciers van componenten;
- componenten waarvoor bekende kwetsbaarheden bestaan.
- Veelgebruikte SBOM-formaten zijn CycloneDX en SPDX.
Een SBOM helpt om bij een nieuw beveiligingsadvies snel te bepalen welke software mogelijk geraakt wordt.
Maar een SBOM is geen garantie dat een applicatie veilig is. Het overzicht moet volledig en actueel zijn, en de softwarecomponenten moeten vervolgens worden gekoppeld aan actuele kwetsbaarhedeninformatie.
Iedere kritieke applicatie verdient dagelijkse CVE-monitoring
Een SBOM is een momentopname. Zodra een leverancier een update uitvoert, een nieuwe library wordt toegevoegd of een bestaande component wordt vervangen, verandert de samenstelling van de software.
En ondertussen worden voortdurend nieuwe kwetsbaarheden ontdekt. Daarom vinden we bij Cilde dat organisaties voor hun kritieke digitale voorzieningen minimaal dagelijks moeten controleren of nieuwe relevante kwetsbaarheden zijn gepubliceerd.
Dat betekent niet dat iedere applicatie dagelijks een volledige penetratietest nodig heeft.
Het gaat om een combinatie van actuele software-informatie, geautomatiseerde kwetsbaarhedencontroles en monitoring van nieuwe CVE's.
Een CVE (Common Vulnerabilities and Exposures) is een unieke identificatie voor een publiek bekende kwetsbaarheid.
Door softwarecomponenten en versies te koppelen aan kwetsbaarhedendatabases, leveranciersadviezen en betrouwbare securitybronnen, kan een organisatie sneller zien welke systemen aandacht nodig hebben.
De volgende stap is minstens zo belangrijk: beoordelen of een kwetsbaarheid daadwerkelijk relevant en exploiteerbaar is.
Daarvoor spelen de gebruikte configuratie, bereikbaarheid vanaf internet, beschikbare beveiligingsmaatregelen en mogelijke bedrijfsimpact een rol.
Het doel is niet om dagelijks een langere lijst kwetsbaarheden te produceren. Het doel is om sneller te weten waar actie nodig is.
De Cyberbeveiligingswet en BIO2 maken aantoonbaarheid belangrijker
Sinds 15 augustus 2026 is de Cyberbeveiligingswet (Cbw) van kracht. Daarmee zijn de Europese NIS2-verplichtingen in Nederland uitgewerkt.
Voor organisaties die onder de Cbw vallen, brengt de wet onder meer verplichtingen mee rondom risicobeheersing, incidenten en beveiliging van netwerk- en informatiesystemen.
Voor essentiële entiteiten in de sector overheid is de zorgplicht nader uitgewerkt in de Cyberbeveiligingsregeling sector overheid.
Daarbij spelen ISO 27001, ISO 27002 en BIO2 een belangrijke rol.
De BIO2 vraagt onder andere aandacht voor het identificeren en beheersen van technische kwetsbaarheden. Voor internet-facing informatiesystemen wordt waar mogelijk continue controle op zwakheden en kwetsbaarheden voorgeschreven.
Het gaat dus niet alleen om het hebben van een kwetsbaarhedenbeleid.
- Een organisatie moet ook kunnen aantonen:
- Welke systemen zijn binnen scope?
- Welke kwetsbaarheden zijn vastgesteld?
- Wanneer zijn deze ontdekt?
- Wie heeft de risico's beoordeeld?
- Welke maatregelen zijn genomen?
- Wanneer is een patch uitgevoerd?
- Is de maatregel daadwerkelijk in productie doorgevoerd?
- En hoe is gecontroleerd of het probleem is opgelost?
Een actuele SBOM en structurele CVE-monitoring helpen om deze vragen sneller en beter te beantwoorden.
De Cbw schrijft niet voor iedere organisatie expliciet een SBOM of dagelijkse CVE-scan voor. Wel sluiten deze maatregelen goed aan op de risicogestuurde zorgplicht en de behoefte aan aantoonbare beheersing.
DigiD 2026: dagelijks scannen en sneller opvolgen
Ook de vernieuwde NOREA-handreiking voor DigiD-assessments 2026 onderstreept het belang van structureel kwetsbaarhedenbeheer.
De nieuwe handreiking heeft meer aandacht voor de volledige gebruikersreis, cloudbeheer, softwareafhankelijkheden, CI/CD-processen en kwetsbaarheden.
Waar de handreiking 2025 minimaal jaarlijkse kwetsbaarhedenassessments beschreef, introduceert de versie 2026 dagelijkse kwetsbaarheidsscans en aanvullende controles bij relevante wijzigingen in de ontwikkel- en uitrolstraat.
Daarnaast zijn concrete termijnen opgenomen voor het behandelen van kwetsbaarheden:
- 5 werkdagen voor kritieke kwetsbaarheden op internet-facing componenten;
- 10 werkdagen voor kritieke kwetsbaarheden op niet-internet-facing componenten en hoge kwetsbaarheden;
- 1 maand voor kwetsbaarheden met een medium of lage classificatie.
Binnen deze termijnen moeten kwetsbaarheden worden beoordeeld en, waar van toepassing, verholpen, gemitigeerd of aantoonbaar geaccepteerd.
Daarbij is het belangrijk dat een geaccepteerd risico niet automatisch betekent dat ook aan alle afzonderlijke patchmanagementeisen wordt voldaan.
De handreiking benadrukt bovendien dat patchmanagement verder gaat dan het bijwerken van broncode of een container image. Organisaties moeten ook kunnen aantonen dat de aangepaste software daadwerkelijk in productie is gebracht.
Voor DigiD-aansluithouders maakt dit de verbinding tussen software-inzicht, ontwikkelproces, beheer en auditbewijs steeds belangrijker.
Maak een actuele SBOM onderdeel van leveranciersmanagement
Veel publieke en semipublieke organisaties ontwikkelen hun software niet volledig zelf.
Applicaties worden ingekocht, gehost of beheerd door externe partijen. Soms wordt gebruikgemaakt van SaaS-diensten waarvan de technische samenstelling nauwelijks zichtbaar is.
Maar uitbesteden betekent niet dat je geen inzicht meer nodig hebt in de risico's.
Daarom vinden we dat een actuele SBOM, waar passend bij de aard en het risico van de software, een standaardonderdeel moet worden van leveranciersmanagement.
Maak afspraken over:
- het opleveren van een SBOM in een gestandaardiseerd formaat;
- het actualiseren daarvan bij releases en relevante wijzigingen;
- het actief monitoren van bekende kwetsbaarheden;
- het melden van kritieke kwetsbaarheden die de dienstverlening raken;
- het beschikbaar stellen van relevante versies en afhankelijkheden;
- hersteltermijnen en verantwoordelijkheden;
- het aantonen dat patches daadwerkelijk zijn uitgevoerd.
Niet iedere leverancier hoeft daarbij per definitie alle technische details van zijn volledige platform prijs te geven. Zeker bij SaaS kan een passende combinatie van SBOM-informatie, beveiligingsrapportages, kwetsbaarhedenmeldingen en contractuele garanties nodig zijn.
De kern is dat een organisatie voldoende inzicht krijgt om haar eigen risico's te beoordelen en maatregelen te kunnen verantwoorden.
Dit sluit aan op de aandacht voor beveiliging van de toeleveringsketen binnen NIS2 en BIO2.
Een SBOM en een externe technologiescan zijn niet hetzelfde
Er is een belangrijk onderscheid tussen een SBOM en het extern detecteren van gebruikte software.
Met een technologiescan kun je bijvoorbeeld onderzoeken of een website gebruikmaakt van PHP, een bepaald CMS, JavaScript-framework of andere herkenbare technologie.
Soms is ook de gebruikte versie vast te stellen.
Dat levert waardevolle informatie op, zeker wanneer organisaties zelf geen actueel overzicht hebben van hun websites en digitale voorzieningen.
Maar een externe scan ziet niet alles.
Veel softwarecomponenten draaien achter de schermen en zijn niet vanaf internet herkenbaar. Denk aan serverlibraries, interne packages, containers en afhankelijkheden die geen zichtbare technische kenmerken prijsgeven.
Een volledige SBOM moet daarom bij voorkeur worden gegenereerd vanuit het ontwikkel-, build- of softwareleveringsproces.
Een externe technologiescan geeft zicht op wat van buitenaf herkenbaar is. Een SBOM laat zien waar de software van binnenuit uit bestaat.
Juist de combinatie maakt kwetsbaarhedenbeheer sterker.
Verberg je softwareversies niet voor jezelf, maar wel voor aanvallers
Een andere belangrijke basismaatregel is het beperken van onnodige informatie over gebruikte softwareversies.
Webservers, frameworks en programmeertalen geven soms via HTTP-headers, foutmeldingen of technische endpoints prijs welke software wordt gebruikt.
Bij PHP kan bijvoorbeeld via de configuratie-instelling expose_php een X-Powered-By-header worden toegevoegd.
Wanneer deze informatie zichtbaar is, kan dat kwaadwillenden helpen om gerichter naar bekende kwetsbaarheden te zoeken.
Daarom is het verstandig om:
- expose_php uit te schakelen;
- onnodige software- en versieheaders te verwijderen;
- debugpagina's en technische foutmeldingen af te schermen;
- directorylisting en ongebruikte diagnostische endpoints uit te schakelen;
- periodiek te controleren welke technische informatie extern zichtbaar is.
Maar let op: een kwetsbare applicatie wordt niet veilig doordat je de versie verbergt. Versie-informatie kan soms ook via andere kenmerken worden achterhaald.Het beperken van onnodige informatie is daarom een aanvullende hardeningmaatregel. Actueel patchmanagement en kwetsbaarhedenbeheer blijven noodzakelijk.
Intern wil je juist precies weten welke versies je gebruikt.
Hoe KEA helpt om in control te komen
Bij Cilde zien we dat het probleem vaak niet alleen technisch is.
Organisaties hebben verschillende applicatieregisters, leveranciersoverzichten, scanners, rapportages en auditdossiers.
Maar de samenhang ontbreekt.
Een scanner meldt een kwetsbaarheid, terwijl onduidelijk is wie eigenaar is. Een leverancier heeft een patch beschikbaar, maar niemand weet welke applicaties afhankelijk zijn van het betreffende product. De CISO wil een overzicht van de risico's, terwijl de auditor bewijs vraagt van daadwerkelijke opvolging.
Precies daar kan KEA helpen.
Met het centrale register brengt KEA digitale voorzieningen, eigenaren, leveranciers, normenkaders en risico's samen.
Daarnaast kan KEA nu al technologieën detecteren en, waar technisch mogelijk, gebruikte versies controleren. De Worker module voert aanvullende automatische controles uit, bijvoorbeeld op certificaten, uptime, scripts en Internet.nl-resultaten.
Deze signalen worden gekoppeld aan de geregistreerde digitale voorzieningen.
Daardoor zie je niet alleen dat er technisch iets afwijkt, maar ook bij welk systeem, welke eigenaar en welke leverancier het signaal hoort.
De volgende stap: SBOM en CVE-monitoring verbinden
Een logische uitbreiding van deze werkwijze is het koppelen van SBOM-informatie en actuele CVE-signalen aan het centrale register. Daarmee willen we organisaties helpen om:
Softwarecomponenten te registreren
Welke applicaties gebruiken welke libraries, frameworks en softwareversies?
Kwetsbaarheden te monitoren
Welke nieuwe CVE's zijn relevant voor de software die binnen de organisatie wordt gebruikt?
Risico's te prioriteren
Welke systemen zijn vanaf internet bereikbaar, bedrijfskritisch of onderdeel van bijvoorbeeld een DigiD-aansluiting?
Eigenaren en leveranciers te betrekken
Wie is verantwoordelijk voor beoordeling, patching en eventuele risicoacceptatie?
Opvolging aantoonbaar te maken
Welke kwetsbaarheden zijn opgelost, welke maatregelen zijn getroffen en welk bewijs is beschikbaar?
Bewijs te hergebruiken
Welke informatie kan worden gebruikt voor BIO2, Cbw, ITGC, DigiD en interne audits?
Het koppelen van volledige SBOM's aan automatische CVE-monitoring is een ontwikkelrichting voor KEA. We maken daarin bewust onderscheid tussen wat het platform vandaag al ondersteunt en de aanvullende mogelijkheden die we willen realiseren.
Minder incidenten én minder auditwerk
Een goed ingericht software- en kwetsbaarhedenbeheerproces levert twee belangrijke voordelen op.
Het eerste is betere digitale weerbaarheid.
Wanneer een nieuwe kritieke kwetsbaarheid wordt ontdekt, kan de organisatie sneller bepalen welke systemen geraakt worden. Daardoor kunnen eigenaren en leveranciers gerichter handelen en wordt de tijd tussen ontdekking en herstel verkort.
Het tweede voordeel is minder administratieve en auditlast.
Want dezelfde informatie is vaak relevant voor meerdere normenkaders.
Een vulnerabilityscan, patchrapportage, leveranciersverklaring of risicoacceptatie kan bewijs leveren voor ITGC, BIO2, Cbw en DigiD.
Door deze informatie centraal vast te leggen en te koppelen aan de juiste systemen en controls, hoeven medewerkers niet voor iedere audit opnieuw op zoek.
Dat past bij het principe van Cilde:
Explain once, comply to many.
Een keer goed vastleggen, meerdere keren gebruiken.
Begin bij inzicht en eigenaarschap
Je kunt de beste scanners en monitoringtools aanschaffen, maar zonder overzicht en eigenaarschap blijft kwetsbaarhedenbeheer lastig.
Daarom begint het met een aantal praktische stappen:
- Inventariseer welke kritieke websites, applicaties en digitale voorzieningen in gebruik zijn.
- Leg vast wie eigenaar is en welke leveranciers verantwoordelijk zijn.
- Zorg voor actuele software- en versie-informatie, bij voorkeur met een SBOM.
- Richt voor kritieke systemen minimaal dagelijkse monitoring van nieuwe kwetsbaarheden in.
- Beoordeel kwetsbaarheden op risico, blootstelling en mogelijke bedrijfsimpact.
- Zorg voor heldere afspraken over patching, mitigatie, risicoacceptatie en herstel.
- Controleer periodiek of basismaatregelen en hardening nog goed zijn ingericht.
- Leg de opvolging vast, zodat deze ook voor auditors en management aantoonbaar is.
Zo verandert kwetsbaarhedenbeheer van reageren op incidenten naar een beheersbaar en herhaalbaar proces.
Conclusie: de volgende kwetsbaarheid komt er ook
Vandaag gaat het over PHP. Morgen kan het een kwetsbaarheid zijn in Java, OpenSSL, een veelgebruikte opensourcelibrary, een container image of een SaaS-product van een belangrijke leverancier.
De vraag is daarom niet óf er nieuwe kwetsbaarheden worden ontdekt.
De vraag is hoe snel jouw organisatie weet of zij geraakt wordt.
Met de nieuwe Cyberbeveiligingswet, BIO2 en aangescherpte DigiD-handreiking neemt het belang van aantoonbaar kwetsbaarhedenbeheer verder toe.
Een actuele SBOM, dagelijkse CVE-monitoring voor kritieke systemen, duidelijke leveranciersafspraken en structurele opvolging vormen daarvoor een sterke basis.
Bij Cilde werken we met KEA aan het verbinden van dit soort informatie. Zodat organisaties niet alleen weten welke software ze gebruiken, maar ook welke risico's daarbij horen en wat er moet gebeuren.
Want een kwetsbaarheid vinden is één ding. Weten wie hem moet oplossen en kunnen aantonen dat het is gebeurd, is pas echt in control zijn.
