Bijgewerkt op 43 min leestijd

Kwetsbaarheden: zo beschermt u uw applicaties

Sébastien Nobour

Oprichter van DEVEDANOS

Praktijken

PHP is een programmeertaal. Volgens W3Techs, een dienst die bijhoudt welke technologieën websites gebruiken, wordt PHP in oktober 2026 gebruikt door 69,3 % van de websites waarvan de taal aan de serverkant bekend is. Op 21 oktober 2026 bracht het PHP-team met spoed nieuwe versies van de taal uit. Die dichten twee kritieke kwetsbaarheden, die hun ontdekkers PHP2Shell hebben gedoopt. Met een paar verzoeken, zonder account of wachtwoord, kan een aanvaller de server waarop een website staat zijn eigen code laten uitvoeren.

Gebruikt uw website of applicatie PHP, stel dan deze eenvoudige vraag aan uw hostingprovider of uw leverancier: welke PHP-versie gebruiken we, en wanneer stappen we over op een gepatchte versie? Ons artikel over de PHP-kwetsbaarheid van oktober 2026 legt uit wie risico loopt en wat u moet doen, in volgorde.

Dezelfde dag brachten ook GitLab en Node.js patches uit voor ernstige kwetsbaarheden. GitLab, een platform dat de code van software host en het testen en deployen ervan automatiseert, dichtte een kwetsbaarheid (CVE-2026-110264) met een score van 10 op 10, waarmee zonder account en onder bepaalde voorwaarden code kon worden uitgevoerd op de installaties die bedrijven zelf hosten. Alle versies vanaf 7.0 waren getroffen. GitLab.com, de versie die GitLab zelf host, was al gepatcht.

Node.js, de software die JavaScript op servers uitvoert, bracht versies uit die vier kwetsbaarheden met een hoge ernst dichten. Met een daarvan, in het decoderen van gegevens die in het Brotli-formaat zijn gecomprimeerd, kan op afstand code worden uitgevoerd. Deze versies werken ook de lijst van vertrouwde certificaten bij, nadat een tussenliggende certificeringsinstantie van eMudhra was gecompromitteerd.

Host uw bedrijf GitLab zelf, of gebruiken zijn applicaties Node.js, dan geldt voor die software dezelfde vraag: welke versie gebruiken we, en wanneer stappen we over op een gepatchte versie?

Media bundelden deze patches en andere incidenten van die week onder de naam “Black October”, die opdook in de nacht van 21 op 22 oktober. SecurityToday, een Duitse nieuwssite over IT-beveiliging, ziet er vooral een piek in openbaarmakingen in: veel van de aanvallen die in die dagen aan het licht kwamen, waren weken of maanden eerder begonnen.

Wat volgt, geldt voor elke applicatie, in welke taal ze ook is geschreven. Dit zijn niet de eerste kwetsbaarheden van deze omvang, en niets wijst erop dat het de laatste zullen zijn. Op drie dingen kunt u zich vooraf voorbereiden: waar een kwetsbaarheid toegang toe geeft, hoe lang het duurt voordat u het merkt, en hoe lang het duurt om het lek te dichten.

De technische details staan in de passages met de titel “Voor uw technische team”.

Aanvallen beginnen steeds eerder, soms nog voordat de kwetsbaarheid openbaar is

Mandiant, het dreigingsanalyseteam van Google Cloud, meet elk jaar de tijd tussen de publicatie van een kwetsbaarheid en het eerste waargenomen misbruik. Gemiddeld was dat 63 dagen in 2018 en 2019, 44 dagen tussen 2020 en begin 2021, 32 dagen in 2021 en 2022, en in 2023 nog maar 5 dagen (Mandiant). In zijn rapport M-Trends 2026 schat Mandiant dat het eerste misbruik gemiddeld zeven dagen vóór de publicatie van de kwetsbaarheid plaatsvindt. Misbruik gebeurt vaak “zelfs voordat er een patch is gepubliceerd” (M-Trends 2026).

VulnCheck, een bedrijf dat kwetsbaarheden in de gaten houdt, keek alleen naar kwetsbaarheden waarvan misbruik is aangetoond. In de eerste helft van 2026 werd 23,43 % daarvan misbruikt op de dag van publicatie, of eerder. Contentmanagementsystemen, zoals WordPress en zijn plugins (zo heten uitbreidingen bij WordPress), vormen de meest getroffen categorie: een derde van die kwetsbaarheden (VulnCheck). En volgens het jaarlijkse rapport van Verizon over datalekken, editie 2026, begint 31 % van de datalekken met een kwetsbaarheid in software, vaker dan met gestolen wachtwoorden (Verizon DBIR 2026).

Inspelen op AI: patches installeren zodra ze verschijnen, en de code nalezen die AI schrijft

De beveiligingsautoriteiten zijn het over één punt eens: AI verkort de tijd die overblijft voor wie patches installeert. In mei kondigde het National Cyber Security Centre (NCSC) van het Verenigd Koninkrijk een golf van updates aan, voor kwetsbaarheden van elke ernst, omdat AI het in bekwame handen mogelijk maakt de zwakke plekken die zich in software hebben opgestapeld “op grote schaal en in een hoog tempo” te misbruiken. In juni veranderde de CISA, het Amerikaanse agentschap voor cyberbeveiliging, de termijnen die het de Amerikaanse federale overheidsdiensten oplegt om patches te installeren: die hangen voortaan af van het risico (blootstelling aan internet, aangetoond misbruik, impact). De kortste termijn is drie dagen. Het agentschap rechtvaardigt deze wijziging met het gebruik van AI door aanvallers, dat de tijd waarover verdedigers beschikken “nog verder zou kunnen verkorten”. Wij leiden er een regel uit af: een kritieke patch wordt geïnstalleerd op de dag dat hij wordt gepubliceerd, wat mogelijk is met een manier van opleveren waarbij elke wijziging al door de pipeline gaat.

AI wordt ook gebruikt om code te schrijven, en verscheidene van deze autoriteiten raden aan die code te controleren. In maart 2026 waarschuwde de directeur van het Britse NCSC dat onveilige software, geproduceerd “zonder dat een mens ze naleest”, kwetsbaarheden zou kunnen verspreiden. Het BSI, de Duitse federale dienst voor cyberbeveiliging, wijst in een rapport over programmeerassistenten op het risico dat ontwikkelaars, vooral beginnende, te afhankelijk worden van deze tools en de code die ze genereren zonder controle accepteren. Het beveelt aan dat gegenereerde code in de regel door de ontwikkelaars wordt gecontroleerd, met een kritische blik op de fouten van de tool en op de beveiligingsrisico’s. Voor AI-agents geldt het principe van zo min mogelijk rechten net zo goed als voor het PHP-proces (details verderop).

Concreet raden wij een team dat met AI ontwikkelt aan om elke regel die de tool schrijft na te lezen en door de tests van de pipeline te laten gaan, net als de rest van de code; om na te gaan of een component die AI voorstelt bestaat, en wie hem publiceert, voordat hij wordt toegevoegd; en om een agent alleen de rechten te geven die zijn taak nodig heeft. Voor een applicatie die met AI is gemaakt, beschrijft ons artikel “Een app maken met AI: kan dat?” wat de tool zelf kan.

Ga ervan uit dat er al een kwetsbaarheid is

Een mkb-bedrijf of een startup hoeft geen beveiligingsonderzoekers in dienst te hebben. Een kwetsbaarheid als PHP2Shell vinden is werk voor specialisten, en hun onderzoek vond plaats vóór de publicatie: tussen de eerste melding en de patch zaten acht tot tien weken, volgens de tijdlijnen van Wiz, een bedrijf voor cloudbeveiliging, en van Calif, het beveiligingsonderzoeksbedrijf waarvan de onderzoekers de eerste kwetsbaarheden aan het PHP-team meldden (Wiz, Calif). Voor de rest biedt het Nederlandse NCSC in zijn basisprincipes houvast voor organisaties. Wie de expertise mist, schakelt volgens ons een specialist in voor een beoordeling en wijst binnen het bedrijf een aanspreekpunt voor beveiliging aan.

Dave Farley is de bedenker van de deployment-pipeline, vaak CI/CD-pipeline genoemd. Bij Continuous Delivery staat de software op elk moment klaar om naar productie te gaan, in kleine wijzigingen die automatisch worden gecontroleerd. De deployment-pipeline is de geautomatiseerde keten die elke wijziging in de code oppakt, test, vastlegt en klaarzet om naar productie te gaan. Dave Farley schreef samen met Jez Humble het boek “Continuous Delivery” (Continue oplevering), en is de auteur van “Modern Software Engineering” (Moderne software-engineering). In “Continuous Delivery Pipelines” (Pipelines voor Continuous Delivery) schrijft hij dat beveiliging het advies van specialisten kan vragen, maar dat ze “de verantwoordelijkheid is van iedereen in het team”. Specialisten adviseren; ze horen geen “poortwachters” te zijn die elke stap naar productie goedkeuren.

Wat het team dat de applicatie ontwikkelt en onderhoudt kan doen, komt neer op vier doelen, en voor geen ervan hoeft het kwetsbaarheden te zoeken:

  1. Beperken waar een kwetsbaarheid toegang toe geeft, zodat een aanvaller die via PHP binnenkomt niet alle deuren erachter open aantreft.
  2. Direct gewaarschuwd worden als er iets misgaat, om de toegang af te sluiten en te achterhalen waar de aanval vandaan komt.
  3. De patch nog op de dag van publicatie installeren, zonder iets kapot te maken. Zolang er geen patch is, de beschermende maatregelen toepassen die de maker van de software en de autoriteiten aanbevelen, zoals het PHP-team en het Nederlandse NCSC dat voor PHP2Shell aanraadden (The PHP Group, NCSC).
  4. Weten wat u moet doen op de dag dat het gebeurt, met een plan dat vooraf op papier staat.

De secties “Beperken waar een kwetsbaarheid toegang toe geeft” en “Direct gewaarschuwd worden” behandelen de eerste twee doelen. De secties over dependencies, over updates en over de manier van opleveren behandelen het derde, en de sectie “Website gehackt of kwetsbaarheid ontdekt” het vierde. De deployment-pipeline controleert ook elke wijziging in de code, om de kwetsbaarheden op te sporen die ze zou introduceren (beveiligingstests in de pipeline).

Volgens M-Trends 2026 is de mediane tijd tussen het binnendringen van een aanvaller in een systeem en de ontdekking ervan 14 dagen (M-Trends 2026). In die tijd is de aanvaller actief: de eerste twee doelen beperken wat hij kan bereiken en hoe lang hij onopgemerkt blijft.

Beperken waar een kwetsbaarheid toegang toe geeft

Een digitale dienst is meer dan een website. Een typische webapplicatie bestaat uit meerdere onderdelen: een toegangspunt dat de verzoeken van internet ontvangt en doorstuurt, de server die de code uitvoert, een database, back-ups, en de accounts van de mensen die het geheel beheren. Elk van die onderdelen kan zo worden ingericht dat een kwetsbaarheid in het ene geen toegang geeft tot alle andere. Dat heet gelaagde beveiliging, in het vak ook defense in depth genoemd.

Elk programma zo min mogelijk rechten geven. Het PHP-proces hoeft geen beheerder van de machine te zijn, en hoeft de code van de website niet te kunnen wijzigen. Het account waarmee het verbinding maakt met de database hoeft volgens de beveiligingsgids van WordPress alleen gegevens te kunnen lezen en schrijven; de rechten om te verwijderen, de structuur te wijzigen of rechten toe te kennen kunnen worden ingetrokken, met in het achterhoofd dat sommige WordPress-updates die structuur moeten wijzigen. Jez Humble en Dave Farley zeggen het in “Continuous Delivery”: de standaardinstellingen van besturingssystemen en databases zijn niet geschikt voor een applicatie in productie; er zijn firewalls nodig, overbodige diensten moeten uit, en databasegebruikers moeten precies de rechten krijgen die ze nodig hebben.

Ervoor zorgen dat de code niet vanuit de website kan worden gewijzigd. Kan het PHP-proces niet schrijven in de mappen met code, dan kan een aanvaller die het overneemt daar niet zo makkelijk een webshell neerzetten, een klein bestand waarmee hij later via zijn browser de server weer kan aansturen. Op een WordPress-site hoeft alleen de map met geüploade inhoud schrijfbaar te blijven, en kunt u de code-editor in het beheerpaneel uitschakelen.

Netwerk segmenteren. De database hoeft niet vanaf internet bereikbaar te zijn: alleen de applicatieserver moet er verbinding mee kunnen maken.

Vooraf filteren, met kennis van de grenzen van het filter. Een webapplicatiefirewall, of WAF, onderzoekt de verzoeken voordat ze de server bereiken en blokkeert de verzoeken die op een bekende aanval lijken. De beveiligingsgids van WordPress raadt aan er een te installeren. Zo’n firewall heeft zijn grenzen: Cloudflare vraagt zelf om de patch te installeren, ook met zijn regels tegen PHP2Shell. Een webapplicatiefirewall levert tijd op; hij vervangt de patch niet.

Beveiligingsheaders meesturen, en ze op de live site controleren. Met elke pagina kan de server de browser vertellen wat hij ermee mag doen: alleen versleutelde verbindingen gebruiken, weigeren dat een andere site de pagina in een frame toont, scripts alleen laden vanaf de voorziene adressen. OWASP, de toonaangevende stichting voor de beveiliging van webapplicaties, beveelt deze headers aan, en noemt Mozilla Observatory om ze op de productiesite te controleren. De strengste ervan, de Content Security Policy (CSP), beperkt de scripts die een pagina mag uitvoeren: code die in een betaalpagina is gesmokkeld om kaartnummers te kopiëren, kan dan minder makkelijk worden uitgevoerd. OWASP noemt haar “een effectieve tweede beschermingslaag”, waarop u niet uitsluitend mag vertrouwen. Op een bestaande site voert u haar stapsgewijs in, eerst in observatiemodus, waarin de browser meldt wat ze zou blokkeren zonder iets te blokkeren.

Geheimen uit de code halen. Wachtwoorden en toegangssleutels voor andere diensten (betalingen, e-mailverzending, opslag) horen niet in de codebestanden te staan. MITRE ATT&CK raadt een regel aan die het opslaan van wachtwoorden in bestanden verbiedt. Staan ze in de omgevingsvariabelen van de server of in een kluis voor geheimen, dan kan PHP ze nog steeds lezen terwijl het wordt uitgevoerd: dat beschermt ze niet tegen een overname van het PHP-proces. Wat u er naar ons idee mee wint, is dat ze niet meer in de geschiedenis van de code of in de back-ups ervan staan, en dat u ze kunt wijzigen zonder de code aan te passen. Dat telt op de dag dat ze allemaal vervangen moeten worden.

Kiezen waar geheimen worden bewaard. De geheimen van de pipeline en de productie horen in de beschermde variabelen van het continuous-integrationplatform, of in een secrets manager: GitLab vraagt tokens en wachtwoorden in de projectinstellingen op te slaan, nooit in het bestand dat de pipeline beschrijft. Op de computer van een ontwikkelaar raden wij aan geen enkel geheim onversleuteld in een bestand te bewaren: de wachtwoord- of secrets manager geeft het aan het programma op het moment dat dat wordt uitgevoerd; is er geen manager, dan raden Jez Humble en Dave Farley aan het versleuteld te bewaren. OWASP raadt aan productiegeheimen gescheiden te houden van ontwikkelgeheimen, en elk alleen de minimaal nodige rechten te geven: een ontwikkelaar werkt met inloggegevens voor de ontwikkelomgeving, die geen toegang geven tot de productie. Een token dat niet meer wordt gebruikt, trekt u in bij de dienst die het heeft uitgegeven, in plaats van het geldig te laten in een vergeten bestand.

De accounts van mensen beschermen. Een aanvaller heeft niet altijd een kwetsbaarheid nodig: een hergebruikt wachtwoord is genoeg. Concreet raden wij een wachtwoordmanager aan, zodat iedereen per dienst een ander wachtwoord heeft, en tweestapsverificatie op de accounts die toegang geven tot de productie, de hosting en de code.

Handmatige wijzigingen in productie verbieden. In “Continuous Delivery Pipelines” stelt Dave Farley een doel: “alle menselijke schrijftoegang tot productiesystemen verwijderen”. Elke wijziging gaat via de deployment-pipeline. In “Continuous Delivery” voegen de twee auteurs eraan toe dat de productie afgesloten moet zijn voor buitenstaanders en voor mensen binnen het bedrijf, beheerteams inbegrepen. Zonder dat weet niemand meer wie wat heeft gedaan, en wanneer, als er iets misgaat.

Back-ups offline bewaren, en testen. Een back-up die bereikbaar is vanaf de gecompromitteerde server, kan samen met de rest worden versleuteld of gewist. Het NCSC adviseert de 3-2-1-regel: drie versies van uw gegevens, op twee verschillende media, met één kopie op een andere locatie. Een back-up die nooit is teruggezet, heeft nog niet bewezen dat hij werkt.

Voor uw technische team: gelaagde beveiliging

  • Toegangspunt: een reverse proxy, vaak gecombineerd met een load balancer die de verzoeken over meerdere servers verdeelt, ontvangt de verzoeken van internet en stuurt ze door naar de applicatieserver. Daar kan ook een blokkade plaatsvinden, nog vóór PHP.
  • Gebruiker van het PHP-proces: met PHP-FPM wordt elke pool van processen uitgevoerd onder de gebruiker die is ingesteld met de verplichte directive user (php.net). Instellingen die met php_admin_value en php_admin_flag zijn vastgelegd, kunnen niet met ini_set() worden gewijzigd. Stel PHP-FPM niet open op een adres dat van buitenaf bereikbaar is.
  • PHP harden, en de grenzen daarvan: de OWASP-cheatsheet over de configuratie van PHP raadt onder meer aan: expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…), sessiecookies met secure, httponly en use_strict_mode. Maar de documentatie van PHP waarschuwt zelf dat disable_functions “kan worden omzeild” en dat open_basedir slechts “een extra vangnet is, verre van volledig”, dat de toegang tot Unix-sockets niet beperkt. Deze instellingen maken het vervolg van een aanval lastiger; ze voorkomen het niet, en PHP2Shell slaat toe voordat de applicatie wordt uitgevoerd.
  • Afgesloten productie: elke wijziging aan de infrastructuur, van een firewallregel tot een nieuwe versie, doorloopt hetzelfde proces: getest op een omgeving die op productie lijkt, vastgelegd en gecontroleerd (“Continuous Delivery”). Met immutable infrastructuur “wordt elke handmatige wijziging bij de volgende deployment overschreven” (“Continuous Delivery Pipelines”).
  • Back-ups: de back-up, het herstel en de archivering van gegevens testen als onderdeel van de continuïteitstests (“Continuous Delivery”); offline kopieën en een jaarlijkse hersteloefening.
  • Beveiligingsheaders (OWASP): Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, frame-ancestors in de CSP (of X-Frame-Options), Referrer-Policy, Permissions-Policy. De CSP begint als Content-Security-Policy-Report-Only, zolang de legitieme scripts in kaart worden gebracht.

Direct gewaarschuwd worden als er iets misgaat

Is de verdediging eenmaal op orde, dan moet u ook weten wanneer iemand erdoorheen komt. Het doel is drieledig: weten dat er iets abnormaals gebeurt, de toegang afsluiten, en dan achterhalen waar de aanval vandaan komt. In “Continuous Delivery” vragen Jez Humble en Dave Farley dat beheerteams “onmiddellijk op de hoogte worden gebracht” van een incident, en dat ze de tools hebben om de oorzaak te vinden. Ze wijzen ook op een veelgemaakte fout: fouten negeren in plaats van ze te loggen, waardoor ze niet te ontdekken zijn.

Een monitoringoplossing bewaakt specifieke signalen, en haar logs worden ergens anders bewaard dan op de bewaakte server. Beheerteams volgen de staat van de servers continu op dashboards, zoals Grafana of Kibana, die metingen en logs bundelen en een melding geven wanneer een drempel wordt overschreden. Dit zijn de signalen die deze meldingen moeten bewaken.

De webserver start een programma. Een webserver levert pagina’s; hij heeft geen enkele reden om een opdrachtinterpreter of een downloadtool te starten. Doet hij dat wel, dan wordt er vaak een webshell gebruikt (MITRE ATT&CK).

De server maakt verbinding met onbekende adressen. Cryptomining-software, een tool om een server op afstand over te nemen of een datalek: ze hebben allemaal uitgaande verbindingen nodig. Wij raden aan uitgaande verbindingen van de server standaard te blokkeren, behalve naar de diensten die de applicatie nodig heeft: dat beperkt ook het gebruik van zulke tools.

Een codebestand verandert. In productie verandert de code alleen bij een deployment. Een nieuw .php-bestand in de mappen van de website, buiten een deployment om, is een teken van inbraak. WordPress raadt aan de integriteit van bestanden te bewaken, en wijst erop dat een aanval “altijd sporen achterlaat, in de logs of in de bestanden”.

Er verschijnt een nieuw beheerdersaccount. Wij raden aan de inventaris van accounts met verhoogde rechten actueel te houden. Een beheerdersaccount dat buiten elke procedure om is aangemaakt, is een signaal om op te volgen.

Het aantal fouten loopt op. Wij raden aan de fouten van webdiensten te loggen (fouten 403, 404 en 500) en onverwachte stops.

Logs buiten de server bewaren. Een aanvaller die de server in handen heeft, kan zijn sporen wissen in de logs die daar staan. Wij raden daarom aan de logs centraal op een ander systeem te bewaren.

Voor uw technische team: monitoring

  • Signalen die specifiek zijn voor PHP2Shell: volgens Patchstack (dat de kwetsbaarheden in het WordPress-ecosysteem volgt) en Wiz uploadverzoeken gevolgd door geheugenfouten of herhaalde 500-fouten, abnormaal lange of misvormde sessiecookies, en onverklaarde herstarts van PHP-processen.

Enkele opensourcetools, als voorbeeld:

  • Wazuh: de module voor de bewaking van bestandsintegriteit geeft een melding wanneer een gebruiker of proces een bewaakt bestand aanmaakt, wijzigt of verwijdert (documentatie van Wazuh). OSSEC is de tool die de beveiligingsgids van WordPress voor hetzelfde doel noemt.
  • Falco: een tool voor beveiliging tijdens de uitvoering, een project met de status “graduated” bij de Cloud Native Computing Foundation; de standaardregels dekken het starten van een opdrachtinterpreter, onverwachte netwerkverbindingen en wijzigingen onder /etc (documentatie van Falco).
  • CrowdSec: opensource-tool voor het opsporen en blokkeren van inbraken, die kwaadaardige adressen deelt met al zijn gebruikers.
  • ModSecurity: opensource-webapplicatiefirewall.
  • Productiesignalen om continu te volgen: geheugen, schijf, processor, foutlogs (“Continuous Delivery Pipelines”).

Dependencies: versies zelf kiezen, elke dag controleren

Een applicatie is niet volledig geschreven door de mensen die haar ontwikkelen. Ze steunt op componenten die door anderen zijn gepubliceerd, de dependencies, die door tools worden geïnstalleerd en bijgewerkt: Composer voor PHP, npm of pnpm voor JavaScript. En ze wordt uitgevoerd in een omgeving, PHP zelf, die wordt geleverd door het systeem van de server, door de hostingprovider of door de image waarmee ze wordt gedeployd.

In “Continuous Delivery” zijn Jez Humble en Dave Farley stellig: een project moet altijd “de exacte versie van de externe bibliotheken” vermelden die het gebruikt. Zonder dat, schrijven ze, kan wat in productie staat niet identiek opnieuw worden gebouwd. Naar ons idee weet u dan ook niet of u blootstaat aan een kwetsbaarheid.

Minder geïnstalleerde componenten betekent minder mogelijke kwetsbaarheden: OWASP vraagt overbodige dependencies te verwijderen. En een component die door zijn auteur is verlaten, krijgt geen patches meer: die vervangt u.

De exacte versie vastleggen, en vergrendelen

Accepteert een project “elke versie vanaf deze”, dan komt een nieuw gepubliceerde versie bij de volgende update de applicatie binnen, zonder dat iemand ervoor heeft gekozen. Op dit moment is dat de standaardinstelling van npm (npm), en Composer raadt het aan voor bibliotheken die bedoeld zijn om door andere projecten te worden hergebruikt (Composer). De details van de notatie staan verderop, in het kader “Voor uw technische team: dependencies”.

Niet elke nieuwe versie vraagt dezelfde aanpak. De patch voor een ernstige kwetsbaarheid installeert u zodra hij is gepubliceerd: wachten betekent de deur openlaten. Andere nieuwe versies kunnen een paar dagen wachten, omdat kwaadaardige code juist in een pas gepubliceerde versie binnensluipt. In 2018 nam een aanvaller het onderhoud van het pakket event-stream over en voegde er code aan toe die het gemunt had op de bitcoinwallets van de applicatie Copay (npm). In september 2025 werd het account van de maintainer van chalk, debug en een twintigtal andere JavaScript-pakketten gehackt via een valse e-mail om het wachtwoord opnieuw in te stellen; volgens StepSecurity, een bedrijf voor IT-beveiliging, werden die pakketten toen miljarden keren per week gedownload (StepSecurity). Een paar dagen later had de worm Shai-Hulud, die zich zelfstandig van pakket naar pakket verspreidde, er meer dan 500 gecompromitteerd; de CISA raadde toen aan dependencies vast te zetten op veilige versies, gepubliceerd vóór 16 september 2025 (CISA).

Daaruit volgen zes praktijken.

De exacte versie vastleggen in het bestand dat de dependencies declareert. De applicatie krijgt dan een nieuwe versie wanneer iemand daartoe besluit, niet wanneer die wordt gepubliceerd. Met een lockfile die samen met de code wordt vastgelegd (volgende praktijk), speelt een versiebereik alleen bij een update een rol. Het is dus op zichzelf geen kwetsbaarheid: de exacte versie is een teamafspraak, die van elke update een bewuste keuze maakt. Voor een PHP-applicatie volstaat composer.lock om precies na te bouwen wat in productie staat; exacte versies in composer.json blijven optioneel. Op dit moment weigert de pipeline van onze eigen site elke dependency die zonder exacte versie is gedeclareerd.

De lockfile bij de code bewaren. Dat bestand legt de exacte versie vast van elk geïnstalleerd component, ook van de componenten waarvan uw componenten afhankelijk zijn, en de documentatie van Composer vraagt het samen met de code van het project vast te leggen (Composer).

Installeren vanuit dat bestand, en alleen updaten na een besluit. De pipeline installeert precies de versies uit de lockfile. Over een update wordt per component besloten, en hij wordt getest.

Wachten voordat u een pas gepubliceerde versie overneemt. De pakketbeheerder pnpm biedt die wachttijd aan, sinds versie 11 standaard ingesteld, op dit moment, op één dag, “om het risico te verkleinen dat gecompromitteerde of defecte pakketten worden geïnstalleerd”. Volgens de documentatie worden kwaadaardige versies meestal binnen een uur ontdekt en verwijderd (pnpm). De patch voor een ernstige kwetsbaarheid volgt die wachttijd niet: die installeert u zodra hij is gepubliceerd, nadat u hebt gecontroleerd dat hij echt is aangekondigd door de maker van de software of door het Nederlandse NCSC.

Installatiescripts blokkeren, behalve de scripts die u hebt toegestaan. Een JavaScript-pakket kan elk willekeurig commando uitvoeren op het moment dat het wordt geïnstalleerd, en OWASP raadt aan die scripts uit te schakelen. Op dit moment blokkeert pnpm ze standaard, behalve voor de pakketten die het team één voor één heeft toegestaan (pnpm). Composer, voor PHP, voert alleen de scripts van het project zelf uit, en laadt geen enkele plugin die niet op zijn lijst allow-plugins staat (Composer): het volstaat die instelling niet te versoepelen.

Ook de versie van de taal vastleggen, en controleren dat elke omgeving die gebruikt. De runtime, PHP of Node.js, behandelt u als een dependency. Jez Humble en Dave Farley vragen te testen op omgevingen die zoveel mogelijk op de productie lijken, met dezelfde geïnstalleerde software. Wij raden dus aan dat het project de taalversie van de productie vastlegt, en dat de pipeline faalt als een omgeving een andere versie gebruikt. Ook die versie moet actueel blijven: het NIST, het Amerikaanse instituut voor normen en technologie, vraagt in zijn Secure Software Development Framework (SSDF) actuele versies van compilers, interpreters en buildtools te gebruiken.

Het omgekeerde risico bestaat ook: versies vastzetten en ze nooit meer bijwerken. Volgens onze berekeningen op basis van de cijfers van W3Techs gebruikte in oktober 2026 bijna de helft van de PHP-websites een versie die het PHP-team niet meer patcht. Een vastgezette versie beschermt alleen als u blijft bijwerken: vaak, één update tegelijk, en getest. Jez Humble en Dave Farley maken er een algemeen principe van: “als het pijn doet, doe het dan vaker, en haal de pijn naar voren”. Een update die elke week wordt gedaan, verandert weinig tegelijk; een update die twee jaar wordt uitgesteld, wordt een klus op zich.

Elke dag controleren, niet alleen als de code verandert

Er worden elke dag nieuwe kwetsbaarheden gepubliceerd in code die zelf niet is veranderd. Een controle die alleen bij een wijziging wordt gestart, mist de kwetsbaarheden die in de tussentijd zijn gepubliceerd. Composer, de tool die de componenten van een PHP-applicatie beheert, kan de geïnstalleerde componenten vergelijken met de beveiligingsadviezen op Packagist, de belangrijkste repository van PHP-componenten, en meldt ook verlaten componenten (Composer). Start een geplande taak van de pipeline die controle elke dag, dan signaleert ze een kwetsbaarheid zodra het beveiligingsadvies is gepubliceerd. In “Continuous Delivery Pipelines” vraagt Dave Farley om beveiliging in de pipeline te testen, vanaf de eerste stap, en niet als losse controle te behandelen.

Eén keer per week somt een andere controle de componenten op waarvoor een nieuwe versie bestaat. Die herinnering voorkomt de achterstand van twee jaar.

Een geplande controle kan ook stilletjes niet meer worden uitgevoerd, en haar stilte lijkt dan goed nieuws. Wij raden daarom aan elke geplande controle een heartbeat te geven, een levenssignaal: er gaat een melding uit wanneer de verwachte controle niet heeft plaatsgevonden. Geen enkele beveiligingsreferentie schrijft dit voor; het steunt op de melding waar Jez Humble en Dave Farley in “Continuous Delivery” om vragen, de melding dat “een vereiste gebeurtenis niet heeft plaatsgevonden”.

Meldingen prioriteren: ernst en misbruik

Niet elke melding vraagt dezelfde reactie. Twee gegevens bepalen de urgentie. Eerst het misbruik: een kwetsbaarheid die al wordt misbruikt, gaat vóór een ernstigere die dat nog niet wordt. De CISA houdt de lijst van misbruikte kwetsbaarheden bij: het legt Amerikaanse federale overheidsinstanties termijnen op om ze te patchen, en raadt elke organisatie aan ze “onmiddellijk” aan te pakken. FIRST, de internationale organisatie die de CVSS-schaal voor de ernst publiceert, brengt ook elke dag de EPSS uit, een schatting van de kans dat een kwetsbaarheid binnen dertig dagen wordt misbruikt. Voor PHP2Shell publiceerde het Nederlandse NCSC een alert.

Dan de ernst: de meeste beveiligingsadviezen geven een CVSS-score, van 0 tot 10, die FIRST in vijf niveaus indeelt: geen (0), laag (0,1 tot 3,9), gemiddeld (4 tot 6,9), hoog (7 tot 8,9) en kritiek (9 tot 10) (CVSS 4.0). De PHP2Shell-kwetsbaarheden scoren 9,2: kritiek. Die score vergelijkt de ernst van een kwetsbaarheid met die van andere; hij meet niet het risico voor uw bedrijf.

In de praktijk raden wij aan elke kwetsbaarheid die al wordt misbruikt of kritiek is, te patchen op de dag dat de patch wordt gepubliceerd: zo breiden wij de aanbeveling van de CISA uit, die over misbruikte kwetsbaarheden gaat. De andere volgen het normale ritme van de updates, één tegelijk.

Sommige meldingen worden niet meteen afgehandeld: het getroffen deel van de component wordt nooit door de applicatie aangeroepen, of er bestaat nog geen patch. Het NIST vraagt de reden van elke zulke uitzondering vast te leggen, en alle toegestane uitzonderingen regelmatig opnieuw te beoordelen. Wij geven elke uitzondering een vervaldatum, waarop de pipeline faalt en opnieuw over de uitzondering wordt beslist: geen enkele referentie schrijft die datum voor, het is onze manier om de herbeoordeling af te dwingen die het NIST vraagt.

Deze tools hebben een beperking, en PHP2Shell laat die zien. Ze onderzoeken de bibliotheken die de applicatie declareert, niet de taal die haar uitvoert. Een componentencontrole zonder meldingen zegt niets over PHP2Shell. De PHP-versie bewaakt u apart: het PHP-team publiceert de lijst van ondersteunde versies en een nieuwsfeed van zijn releases. Wij raden ook aan te anticiperen op het einde van het onderhoud van software: PHP 8.2 krijgt na 31 december 2026 geen onderhoud meer.

Voor uw technische team: dependencies

Een composer.json met exacte versies (namen van componenten als voorbeeld):

{
  "require": {
    "vendor/component-a": "2.3.1",
    "vendor/component-b": "5.0.4"
  }
}

In plaats van "^2.3.1", dat elke versie vanaf 2.3.1 tot 3.0.0 (niet inbegrepen) zou accepteren (Composer). Op dit moment schrijft npm standaard ^: ^1.2.3 accepteert elke versie vanaf 1.2.3 en vóór 2.0.0 (node-semver). Bij npm zorgt save-exact=true in .npmrc ervoor dat standaard de exacte versie wordt vastgelegd (npm).

Een voorbeeld van een GitLab-pipeline, ter illustratie en aan te passen: een controle bij elke push, een dagelijkse taak en een wekelijkse taak, elk gestart door een eigen GitLab-planning (planningen, regels).

# Voorbeeld ter illustratie, aan te passen aan uw project
stages: [commit, audit]

.php:
  # Image van uw project met PHP en Composer, vastgezet op zijn digest
  image: registry.example/php-composer@sha256:<digest>

commit:
  extends: .php
  stage: commit
  script:
    # Controleert of composer.json en composer.lock met elkaar overeenkomen
    - composer validate --strict
    # Faalt als een component, voor productie of voor ontwikkeling, een beveiligingsadvies heeft
    - composer audit --locked
    # Installeert precies de versies uit de lockfile
    - composer install --no-interaction --prefer-dist
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

daily-audit:
  extends: .php
  stage: audit
  script:
    # Dezelfde controle elke dag, zonder codewijziging; faalt ook bij verlaten componenten
    - composer audit --locked --abandoned=fail
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"

weekly-reminder:
  extends: .php
  stage: audit
  script:
    # Somt de beschikbare nieuwe versies op, zonder de pipeline te laten falen: dit is de herinnering
    - composer outdated --direct
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
  • De lockfile (composer.lock, of package-lock.json bij npm) wordt samen met de code vastgelegd. De pipeline start composer install, dat precies de versies uit dat bestand installeert; composer update berekent de versies opnieuw en herschrijft het bestand: dat dient alleen voor een update waartoe is besloten, bijvoorbeeld composer update vendor/component-a (Composer).
  • Wachttijd vóór overname: minimumReleaseAge bij pnpm, min-release-age bij npm (namen van de instellingen in oktober 2026). Bij Composer raden wij aan die wachttijd te bewaken met een teamafspraak, of met de tool die de updates voorstelt.
  • composer audit geeft een exitcode die niet nul is wanneer een component onder een advies valt: de taak wordt rood, en dat is de melding. --locked leest de lockfile, ook zonder vendor-map (Composer): daarom voert het voorbeeld de controle uit vóór composer install, en stopt de taak voordat een component met een advies wordt geïnstalleerd. Het voorbeeld controleert ook de ontwikkelcomponenten: die worden uitgevoerd in de pipeline, die toegang heeft tot de code en tot de geheimen voor de deployment.
  • Op dit moment zit Composer niet in de officiële Docker-image php, vandaar de projectimage in het voorbeeld.
  • Docker-images vastgezet op hun digest (@sha256:…), de hash die een image identificeert: volgens de documentatie van Docker krijgt u dan altijd dezelfde image, met de waarschuwing dat de image geen updates meer ontvangt, “die beveiligingspatches kunnen bevatten” (Docker). Vastzetten heeft dus alleen zin als de digest regelmatig wordt bijgewerkt, getest door de pipeline.
  • Hashes overal waar ze bestaan, niet alleen voor Docker-images. De lockfiles van npm en pnpm leggen de hash van elk pakket vast (veld integrity), en de installatie faalt als het gedownloade pakket niet overeenkomt. Bij een script of een stylesheet die van een ander domein wordt geladen, laat het attribuut integrity (Subresource Integrity) de browser een gewijzigd bestand weigeren (MDN). OWASP vraagt de controle van hashes en handtekeningen van gedownloade pakketten in te schakelen. Renovate of Dependabot kunnen deze updates voorstellen als merge requests; ze deployen zelf niets (Renovate, Dependabot).
  • PHP zelf bewaken: de Atom-feed van php.net (https://www.php.net/feed.atom). OSV-Scanner, van Google, leest op dit moment composer.lock en, in een containerimage, de pakketten van Alpine en van Debian of Ubuntu: zo kan het een PHP opsporen dat via het systeem van de image is geïnstalleerd.
  • Installatiescripts: voor pnpm somt allowBuilds de pakketten op die bij de installatie een script mogen uitvoeren (pnpm); voor npm ignore-scripts=true in .npmrc (OWASP). Voor Composer noemt allow-plugins alleen de nodige plugins, nooit true voor allemaal (Composer).
  • Taalversie: voor PHP require.php in composer.json, en composer check-platform-reqs, dat faalt wanneer de PHP-versie of een extensie van de omgeving niet overeenkomt; met config.platform kiest Composer de dependencies voor de PHP-versie van de productie (Composer). Voor Node.js laat het veld engines van package.json, met engine-strict=true, de installatie op een andere versie mislukken.
  • Uitzonderingen: audit.ignore, in composer.json, legt voor elk genegeerd advies de reden vast (Composer).

Updates: automatisch, of na een bewuste beslissing

Voor software die u installeert en ongewijzigd gebruikt (Windows, macOS, een telefoon, een browser, kantoorsoftware), raden wij aan de automatische updates in te schakelen, zoals het Britse NCSC vraagt. Voor een WordPress-site raden wij de automatische updates af die WordPress zelf toepast.

Een applicatie die u ontwikkelt, of samenstelt uit componenten, wordt bijgewerkt na een bewuste beslissing. Het Cyber Essentials-kader van het Britse NCSC sluit de op maat ontwikkelde onderdelen van webapplicaties uit van zijn reikwijdte, en beveelt daarvoor “zorgvuldige ontwikkeling en grondige tests” aan. OWASP vraagt in zijn ranglijst 2025 van de meest kritieke risico’s voor webapplicaties om “bewust de versie van elke dependency te kiezen, en alleen te updaten wanneer dat nodig is”, en om “te vermijden dat updates op alle systemen tegelijk worden uitgerold”. Zijn ranglijst van de risico’s die specifiek zijn voor CI/CD-pipelines vraagt tools niet zo in te stellen dat ze altijd de nieuwste versie van een pakket ophalen. Wij raden aan elke update, van de taal of van een component, door de deployment-pipeline en zijn geautomatiseerde tests te laten gaan.

Deze aanpak veronderstelt iemand die het onderhoud verzorgt. Wat wordt geautomatiseerd, zijn de meldingen: een melding wanneer een kwetsbaarheid de geïnstalleerde versies treft, een melding wanneer er iets abnormaals op de server gebeurt, die waarschuwt zodra het gebeurt. Het is aan een mens om te beslissen wanneer er wordt bijgewerkt, en om de patch voor een kritieke of al misbruikte kwetsbaarheid zonder te wachten te installeren.

Voor een WordPress-site of een PHP-applicatie hangt het van de hosting af of de hostingprovider PHP bijwerkt of u zelf. In WordPress werkt u plugins en thema’s één voor één bij.

Beveiliging testen in de deployment-pipeline

Elke wijziging in de code kan ook een kwetsbaarheid introduceren: de pipeline controleert dus de code die het team schrijft, zoals hij de dependencies controleert. Dave Farley, hierboven geciteerd, vraagt ook gangbare penetratietests te automatiseren. Het NIST beveelt een statische analyse aan die de code automatisch controleert, en dynamische kwetsbaarheidstests die in de geautomatiseerde tests zijn opgenomen.

Statische analyse leest de code zonder haar uit te voeren, en spoort codepatronen op waarvan bekend is dat ze kwetsbaarheden veroorzaken. Semgrep, een van de open-sourcetools, heeft regels voor PHP en voor JavaScript. Deze tools melden ook gevallen die geen probleem zijn: iemand moet elke melding bekijken, en het NIST vraagt de gevonden problemen vast te leggen en te prioriteren.

Dynamische tests sturen verzoeken naar de applicatie terwijl ze wordt uitgevoerd, zoals een bezoeker dat zou doen. De baseline-scan van ZAP, een open-sourcetool voor het testen van de beveiliging van webapplicaties, voert geen echte aanval uit: hij observeert de antwoorden van de site, en meldt bijvoorbeeld een ontbrekende beveiligingsheader. Volgens de documentatie is hij geschikt voor een pipeline, en zelfs voor een productiesite. Een actieve scan, die echte aanvallen verstuurt, voert u alleen uit op een testomgeving, nooit op de productie.

Fuzzing stuurt het programma onverwachte of willekeurige gegevens, om te zien of het die verkeerd verwerkt. Het NIST noemt het als een van zijn voorbeelden. Volgens ons is het niet nodig voor een gewone webapplicatie; het is zinvol voor code die gegevens van buitenaf leest en interpreteert, zoals een bestandsformaat.

Controleren dat er geen geheim in de code terechtkomt. Wij raden een tool voor het opsporen van geheimen aan, zoals gitleaks, die elke wijziging onderzoekt voordat ze wordt vastgelegd en gepusht; de pipeline doorzoekt daarna de hele geschiedenis van de code, voor het geval die eerste controle werd omzeild. OWASP raadt aan geheimen op te sporen nog voordat een wijziging wordt vastgelegd, en daar meer dan één tool voor te gebruiken. Een geheim dat per vergissing is vastgelegd, trekt u in en vervangt u: OWASP vraagt een blootgestelde sleutel onmiddellijk in te trekken.

Waarom de manier van opleveren bepaalt hoe lang het duurt voordat een patch in productie staat

Alles hiervoor steunt op één vermogen: een patch nog dezelfde dag in productie zetten, zonder iets kapot te maken. Dat vermogen wordt niet op de dag van de waarschuwing geïmproviseerd. Het hangt af van de manier waarop de software dagelijks wordt opgeleverd.

In onze ervaring komt een kritieke kwetsbaarheid als een onverwachte gebeurtenis in een organisatie waar elke release een zeldzame operatie is (één avond per kwartaal, handmatige tests, meerdere mensen die moeten worden ingezet). Er moet buiten de planning om een spoedcorrectie worden opgezet, de mensen die kunnen deployen moeten bij elkaar komen, de tests moeten opnieuw met de hand, er moet een onderhoudsvenster worden gereserveerd, en soms is de goedkeuring van een comité nodig. De patch wordt een project, en ondertussen blijft de applicatie blootgesteld. Bij zo’n ritme ligt het voor de hand om rechtstreeks op de server te sleutelen, met de hand. In “Continuous Delivery” wijzen Jez Humble en Dave Farley die kortere weg onomwonden af: bij een kritiek defect “omzeil onder geen beding uw proces”. Ze wijzen er ook op dat het soms beter is terug te gaan naar de vorige versie dan een correctie te deployen. Een correctie die met de hand in productie wordt gedaan, is niet getest, kan het probleem verergeren, en wordt vaak nergens vastgelegd.

Het probleem is niet beperkt tot één bepaald raamwerk. Het geldt voor alle voorspellende aanpakken, het V-model net zo goed als de raamwerken die als agile worden gepresenteerd, zodra een functionaliteit wordt toegezegd met een vaste scope, een vast budget en een vaste termijn tegelijk, en vervolgens in een planning wordt opgenomen die op schattingen is gebouwd. SAFe (Scaled Agile Framework) bijvoorbeeld plant het werk in periodes van acht tot twaalf weken, elk met eigen doelen en opleverdatums. Deze organisaties houden rekening met spoedcorrecties, die voorrang krijgen op de rest. Toch blijft elke spoedcorrectie een uitzondering op de planning: ze volgt een minder ingesleten weg dan de geplande releases, en schuift op wat was toegezegd. In “Accelerate” wijzen Nicole Forsgren, Jez Humble en Gene Kim erop dat korte doorlooptijden ook tellen “wanneer er een defect of storing is en er snel, met veel vertrouwen, een oplossing moet worden opgeleverd”.

En juist het ongeplande werk neemt steeds meer ruimte in: meer gepubliceerde kwetsbaarheden, dus meer patches die niet kunnen wachten. AI veroorzaakt de zwakke plekken van deze organisaties niet, maar buit ze sneller uit. Volgens Amazon “gaat een termijn van 7 of 30 dagen uit van een adempauze die er niet meer is”, en het Britse NCSC vraagt organisaties ervoor te zorgen dat hun “processen en risicobereidheid frequente updates op grote schaal mogelijk maken”.

Naar ons idee brengt deze voorspellende manier van werken in de eerste plaats de organisaties in gevaar die eraan vasthouden: elke dringende patch zet een planning op zijn kop die er geen ruimte voor had gemaakt, en ondertussen blijft het systeem blootgesteld. In een adaptieve aanpak verandert de scope mee met de prioriteiten, en met Continuous Delivery gaat de patch voor op de rest en volgt hij dezelfde weg als alle andere wijzigingen, nog dezelfde dag. In hun onderzoek stellen de auteurs van “Accelerate” vast dat de organisaties die het best presteren in softwarelevering twee keer zoveel kans hebben als de andere om te melden dat ze hun doelen voor winstgevendheid en marktaandeel hebben overtroffen.

Om een patch te installeren hoeft u het systeem overigens niet aan cybersecurityspecialisten toe te vertrouwen. Het is het dagelijkse werk van het team dat de applicatie ontwikkelt: het werkt de betrokken component bij, de deployment-pipeline controleert de wijziging met de geautomatiseerde tests en zet haar daarna in productie. DORA vraagt beveiliging te integreren “in het dagelijkse werk” van de hele opleveringsketen, omdat “beveiliging de verantwoordelijkheid van iedereen is”.

Bij Continuous Delivery, toegepast binnen een adaptieve aanpak, dat wil zeggen door de software continu bij te sturen op basis van het gebruik ervan, is dezelfde patch een wijziging als alle andere. Jez Humble definieert Continuous Delivery als “het vermogen om wijzigingen van alle soorten, waaronder nieuwe functionaliteiten, configuratiewijzigingen, bugfixes en experimenten, veilig, snel en duurzaam in productie of in handen van gebruikers te brengen” (continuousdelivery.com). Dave Farley zegt erbij dat de deployment-pipeline “de ENIGE weg naar productie” is: elke wijziging gaat erdoorheen, de update van PHP net zo goed als de nieuwe functionaliteit. Ze ondergaat dezelfde geautomatiseerde tests en gaat daarna naar productie. Omdat elke wijziging die weg volgt, is de procedure al ingeslepen op de dag dat er een patch komt.

Deze discipline verandert ook de manier waarop het project wordt gestuurd. Een kritieke kwetsbaarheid wordt niet ingepland voor het eind van de week: ze gaat nog dezelfde dag voor al het andere. Een team dat de discipline van Continuous Delivery volgt, kan in de loop van de dag zijn prioriteiten aanpassen aan wat er gebeurt, omdat niets van wat in uitvoering is de release van de patch blokkeert.

Om ervoor te zorgen dat niets wat nog in uitvoering is de patch tegenhoudt, bevelen Jez Humble en Dave Farley aan dat iedereen zijn wijzigingen op de hoofdbranch vastlegt, en dat u “nieuwe functionaliteit verbergt tot die af is”: dat is trunk-based development, waarbij iedereen zijn werk in één enkele branch integreert, meerdere keren per dag. Een dringende patch volgt dan hetzelfde pad als al het andere, zonder te wachten tot een functionaliteit af is. Om een onvoltooide functionaliteit te verbergen, volstaat een configuratie-instelling; dezelfde auteurs vragen die instellingen te verwijderen zodra ze hun doel hebben gediend. Het is een praktijk van Continuous Delivery, waar beveiligingskaders zich niet over uitspreken.

Wij raden aan de pipeline de applicatie maar één keer te laten bouwen, en daarna hetzelfde archief naar elke omgeving te deployen. “Elke keer dat u de code compileert, loopt u het risico een verschil te introduceren”, schrijven Jez Humble en Dave Farley. De regel geldt ook voor PHP, dat niet wordt gecompileerd. Het archief bevat de code, de componenten die Composer heeft geïnstalleerd en de statische bestanden; het archief gaat naar productie, en er wordt niets rechtstreeks op de server geïnstalleerd. Na elke deployment controleert een smoke test, een korte test, of de applicatie reageert. Terugdraaien komt dan neer op het opnieuw deployen van het vorige archief, wat dezelfde auteurs vaak de eenvoudigste manier noemen. De gegevens beperken dat: een database die de nieuwe versie heeft gewijzigd, keert niet vanzelf terug naar haar vorige toestand.

DORA (DevOps Research and Assessment), het onderzoeksprogramma van Google Cloud naar hoe software wordt ontwikkeld en in productie gaat, meet wat deze praktijk verandert. DORA meet niet rechtstreeks hoe lang het duurt voordat een patch is geïnstalleerd. De indicator die er het dichtst bij komt, is de doorlooptijd van een wijziging, vanaf het moment dat ze in de code wordt vastgelegd tot het moment dat ze in productie staat. In “Modern Software Engineering” stelt Dave Farley een verwante vraag: hoe lang duurt het voordat een wijziging van één regel van idee werkende software wordt? Naar ons idee is dat ook de tijd die het installeren van de volgende beveiligingspatch zal kosten. Het onderzoek van DORA laat steeds weer zien dat “snelheid en stabiliteit geen compromissen zijn” (DORA). Volgens een samenvatting van het rapport van 2024, gepubliceerd door Octopus Deploy, een maker van deploymenttools, zetten de best presterende teams een wijziging in minder dan een dag in productie, en herstellen ze in minder dan een uur van een mislukte release (Octopus Deploy, DORA-rapport 2024).

Goedkeuringscomités voor wijzigingen maken een trage oplevering niet goed. In “Modern Software Engineering” citeert Dave Farley het onderzoek uit het boek Accelerate: “goedkeuring door een externe instantie, zoals een manager of een comité voor de goedkeuring van wijzigingen, verhoogt de stabiliteit van productiesystemen eenvoudigweg niet […] Het is zelfs slechter dan helemaal geen goedkeuringsproces voor wijzigingen.”

Ook voor beveiliging geldt een termijn. OWASP waarschuwt in zijn ranglijst 2025 van de tien meest kritieke risico’s voor webapplicaties voor een maandelijks of driemaandelijks patchritme: de blootstelling “ontstaat vaak in omgevingen waar patchen een maandelijkse of driemaandelijkse taak is onder change control, waardoor organisaties dagen of maanden blootstaan aan kwetsbaarheden die al zijn gedicht”. De tijd tot misbruik is teruggelopen tot enkele dagen. Nu aanvallen soms beginnen voordat de patch is gepubliceerd, volstaat een maandelijks ritme niet meer als doel. Het controleren van patches dwingt niet tot een maand wachten: geautomatiseerde tests in de pipeline voeren die controle bij elke wijziging uit.

AI-agents: wat Continuous Delivery afdekt, en wat onder toegangsrechten valt

Jamie Dimon, bestuursvoorzitter en CEO van JPMorgan Chase, wees in oktober 2026 op twee risico’s: AI-agents die handelingen verrichten op de bankrekeningen van hun gebruikers, en AI-tools die honderden ernstige kwetsbaarheden blootleggen in opensourcecode, waardoor sectoren “volledig onbeschermd” achterblijven. Op dit moment geeft zijn bank externe AI-agents alleen leestoegang tot de rekeningen van haar particuliere klanten.

Voor de kwetsbaarheden die AI eerder blootlegt, verkort Continuous Delivery de tijd die het kost om de patch te installeren. Al in 2010 vroegen Jez Humble en Dave Farley in “Continuous Delivery” om snel een nieuwe versie te kunnen uitbrengen “voor het geval er kritieke defecten of beveiligingslekken worden ontdekt”. Ze vroegen ook dat de productie “volledig afgesloten” is, zodat alleen de deployment-pipeline er wijzigingen in kan aanbrengen. Met die praktijken en de praktijken die in de sectie over de manier van opleveren staan beschreven, gaat de patch voor een kwetsbaarheid die door AI is gevonden naar productie zoals elke andere wijziging. Naar ons idee verkort Continuous Delivery de tijd waarin een kwetsbaarheid waarvoor al een patch bestaat bij u misbruikt kan worden; kwetsbaarheden vinden en aanvallen stoppen hoort bij de andere praktijken die in dit artikel worden beschreven.

Het andere risico dat Jamie Dimon beschrijft, gaat over toegangsrechten: weten of een agent echt handelt voor de persoon die hem toestemming heeft gegeven, bij een bank net als bij elke applicatie. OWASP rekent “buitensporige autonomie” tot de risico’s van AI-applicaties, en het Britse NCSC vraagt op agents het principe van zo min mogelijk rechten toe te passen. Laat uw applicatie AI-agents handelen voor uw gebruikers, dan raden wij, net als OWASP, aan ze alleen de minimaal nodige rechten te geven, ze te laten handelen in de context van de betrokken gebruiker, en acties met grote impact door een mens te laten goedkeuren.

Website gehackt of kwetsbaarheid ontdekt: wat te doen, in deze volgorde

Op de dag dat een kwetsbaarheid uw software treft, bestaat de aanpak uit acht stappen. Ze steunt op onze eigen praktijk en op de stappen bij een cyberincident van het NCSC. Lees deze stappen liever vóór die dag, en spreek af wie wat doet.

De eerste drie stappen hangen af van de kwetsbaarheid. Voor PHP2Shell betekent dat: nagaan of u kwetsbaar bent, bijwerken of isoleren, en daarna zoeken naar sporen van inbraak. De volgende vijf gelden voor elke kwetsbaarheid.

4. Bewijs veiligstellen vóór het opschonen. Wij raden aan de logs van de firewall, de reverse proxy en de getroffen servers veilig te stellen, en een volledige kopie te maken van de aangevallen machine en haar geheugen. Het NCSC adviseert bovendien een logboek bij te houden van het verloop van het incident: dat helpt bij het vinden van een oorzaak en bij aangifte of een verzekerings- of aansprakelijkheidsclaim. Deployt u een schone versie opnieuw vóór die kopie, dan wist u precies de sporen uit die nodig zijn om te begrijpen wat er is gebeurd.

5. Alle secrets vervangen die de server bevatte. Wij raden aan de wachtwoorden van de database te wijzigen, net als de sleutels van de applicatie (sleutels en salts van WordPress, APP_KEY van Laravel, versleutelingssleutel van Magento), de toegangssleutels voor diensten van derden (betalingen, e-mailverzending, opslag), de accounts voor het versturen van berichten, de deploymenttokens op de server, de privésleutels van de certificaten en de beheerdersaccounts, en de openstaande sessies te beëindigen. De nieuwe secrets worden gegenereerd vanuit een schone omgeving en alleen gedeployd op de server die in de volgende stap opnieuw wordt opgebouwd, nooit op de server die nog gecompromitteerd is. CosmicSting liet het zien: een sleutel die vóór de patch is gestolen, blijft daarna geldig, en Sansec raadt aan de versleutelingssleutel te vervangen en de oude ongeldig te maken. Het wijzigen van de applicatiesleutel logt alle gebruikers uit; dat is de bedoeling. Let wel op gegevens die met de oude sleutel zijn versleuteld: die worden onleesbaar, tenzij de oude sleutel beschikbaar blijft om ze te ontsleutelen of ze opnieuw worden versleuteld met de nieuwe. Laravel laat u oude sleutels bewaren om te ontsleutelen (APP_PREVIOUS_KEYS), en Adobe biedt voor Magento een procedure om de sleutel te wijzigen en een opdracht die de gegevens opnieuw versleutelt.

6. Is de server gecompromitteerd, bouw dan opnieuw op vanuit een schone bron. Wij raden af de oude serverimage of de oude code terug te zetten, want die kunnen de webshell bevatten. Met een pipeline bouwt u de server en de applicatie opnieuw op vanuit de coderepository, in een schone versie, met de patch. De gegevens zet u naar ons idee terug vanuit een back-up van vóór de vroegst mogelijke datum van inbraak. Daar maken offline en geteste back-ups het verschil. Wij raden aan de systemen daarna geleidelijk weer in gebruik te nemen, nadat is vastgesteld dat de kwetsbaarheid is gedicht.

7. Melden. Kunnen persoonsgegevens zijn ingezien, gewijzigd of vernietigd, dan moet het incident binnen 72 uur worden gemeld bij de Autoriteit Persoonsgegevens, de Nederlandse toezichthouder op persoonsgegevens (in België de Gegevensbeschermingsautoriteit). Die termijn van 72 uur legt de AVG op. Meld de schade ook bij uw verzekeraar. Voor begeleiding raden wij aan een gekwalificeerde dienstverlener voor de afhandeling van beveiligingsincidenten in te schakelen. Bel in een noodgeval 112.

8. Lessen trekken. Stel de vraag: wat hebben we geleerd? Hoe lang duurde het om de patch te installeren, en waarom? DORA meet de indicator die het dichtst bij die tijd komt, hierboven beschreven: hoe korter die in het dagelijks werk is, hoe eerder de volgende patch na publicatie wordt geïnstalleerd. Wat maakte het mogelijk, of had het mogelijk gemaakt, de aanval op te merken?

Hoe wij werken

Een beveiligingspatch is een wijziging als alle andere: hij gaat door dezelfde pipeline als de rest. Wij zoeken geen kwetsbaarheden; dat onderzoek is aan de onderzoekers. Wij zorgen ervoor dat de volgende kwetsbaarheid zo min mogelijk toegang geeft, dat we direct worden gewaarschuwd zodra ze wordt misbruikt, en dat de patch live gaat zodra hij is gepubliceerd.

Bij DEVEDANOS ontwikkelt, test, deployt en onderhoudt hetzelfde team uw software continu, in dezelfde pipeline. Elke productie-deployment gaat door een deployment-pipeline: beveiliging en toegankelijkheid worden automatisch geverifieerd voordat een wijziging productie bereikt, en de performance wordt in productie gemonitord. We zetten één wijziging tegelijk in productie, nadat de pipeline haar heeft gecontroleerd. Bij een incident gaan we terug naar de vorige versie.

Voor de applicaties die wij ontwikkelen, zetten we het volgende op met een deployment-pipeline. Elke dependency staat op haar exacte versie. Een nieuw gepubliceerde versie nemen we pas na drie dagen over, behalve de patch voor een ernstige kwetsbaarheid: dan heffen we die wachttijd per geval op en installeren we hem zodra hij is gepubliceerd. Elke ochtend controleert een geplande taak of een bekende kwetsbaarheid de geïnstalleerde componenten treft. We zetten ook monitoring van de servers op, met meldingen op de hierboven beschreven signalen. Een update van PHP of van een component gaat door dezelfde pipeline als de rest.

Beveiligingspatches en updates van dependencies vallen onder het onderhoud dat in ons aanbod is inbegrepen: software op maat met een vast maandbudget, met een nulregressiegarantie.

Daarnaast bieden we audits van softwareproductieketens en trainingen voor technische teams. De audit controleert of een lek dat in uw software wordt ontdekt, nog dezelfde dag kan worden verholpen en bij uw klanten kan worden uitgerold, en wat er nog moet worden ingericht.

Verder lezen

Een beveiligingsupdate bereikt de productie op de dag van publicatie wanneer elke wijziging er al in kleine stappen aankomt. Ons artikel over Continuous Delivery en Continuous Deployment legt uit hoe dat werkt, en ons artikel over de voorspellende of adaptieve aanpak waarom deze manier van opleveren bij een adaptieve aanpak hoort.

Wilt u een applicatie overnemen waarvan de taal of de componenten niet meer worden onderhouden, dan legt onze pagina over het vervangen of vernieuwen van verouderde software uit hoe we te werk gaan.

Wilt u een applicatie laten ontwikkelen, of weer grip krijgen op een bestaande? Zullen we erover praten?

Bronnen

Lees ook

Shadow IT: betekenis, risico's en voorbeelden

Wat is shadow IT? De definitie van het Britse centrum voor cyberbeveiliging, voorbeelden (Excel, AI-tools), de risico's voor het bedrijf, en waarom het antwoord een tool is die bij het werk past.

Automatische updates van WordPress: inschakelen of uitschakelen?

Moet u de automatische updates van WordPress inschakelen of uitschakelen? Wij raden de updates af die WordPress zelf, zonder enige test, op plugins en thema's toepast. Een hostingprovider die elke update test voordat hij die toepast, kan dat van u overnemen; zonder zo'n provider werkt u één plugin tegelijk bij, en controleert u daarna de site.