Kort gezegd: Een patchbeheerproces legt vast hoe updates van binnenkomst tot bewijs verlopen: in welke klasse een patch valt, in welk venster hij wordt geïnstalleerd, hoe wordt getest en teruggedraaid, wie herstart en hoe het succes wordt aangetoond. Routine-updates lopen gepland in een vast ritme, noodpatches volgen een vooraf afgesproken snelle route. Zo wordt uit brandweeracties een herhaalbaar proces.
Als elke patch een noodgeval is
Op de avond van 21-10-2026 speelde zich bij veel bedrijven hetzelfde patroon af. De patches waren er, het BSI (Duitse federale dienst voor informatiebeveiliging) drong aan, en de vragen begonnen: mogen we nu zomaar bijwerken? Wie test? Wie herstart de diensten? Wie meldt de directie dat de shop even weg is? En hoe bewijzen we achteraf dat het gelukt is?
Bij bedrijven zonder proces moet dat alles ter plekke worden uitgezocht. Bij bedrijven met een proces staat het antwoord al vast. Het verschil zit niet in de techniek, maar in afspraken die vooraf zijn gemaakt.
De bouwstenen van een patchbeheerproces
Een werkbaar proces onderscheidt eerst hoe dringend een patch is. Drie klassen volstaan meestal:
| Klasse | Typische aanleiding | Venster | Test | Goedkeuring |
|---|---|---|---|---|
| Routine | foutherstel, beveiligingsupdates met laag risico | vaste maandelijkse datum | staging, standaardtests | IT, volgens plan |
| Dringend | hoge classificatie, systeem openbaar bereikbaar | op korte termijn naar voren gehaald | verkort, belangrijkste processen | IT-leiding |
| Nood | kritiek lek, aanvallen gemeld, bijv. PHP2Shell | direct | rooktest na installatie | vooraf verleende noodgoedkeuring |
Wie welke klasse toekent, moet net zo vaststaan als de criteria daarvoor. De beoordeling zelf hoort bij de voorafgaande stap, zie Kwetsbaarhedenbeheer voor het mkb.
Belangrijk is de vooraf verleende noodgoedkeuring. De directie besluit eenmalig in alle rust dat bij noodpatches direct mag worden gehandeld, ook als dat een korte onderbreking betekent. In een noodgeval hoeft dan niemand 's nachts toestemming te halen.
Even belangrijk zijn de rollen. Voor elk systeem moet vaststaan wie updates installeert, wie inhoudelijk test of de shop of het portaal daarna werkt, en wie wordt geïnformeerd. Bij uitbestede systemen horen hoster en bureau uitdrukkelijk erbij, met naam en bereikbaarheid. Het vaste onderhoudsvenster moet intern bekend zijn, zodat verkoop en klantenservice weten wanneer korte onderbrekingen mogelijk zijn.
Meet bovendien hoe lang uw proces werkelijk duurt: van publicatie van een patch tot aangetoonde afronding, per klasse. Deze eigen waarden laten zien waar het knelt en maken verbeteringen zichtbaar. Een proces waarvan niemand de doorlooptijd kent, is nauwelijks te sturen.
Het verloop van een patch in acht stappen
Elke patch, van welke klasse ook, doorloopt dezelfde stations. Alleen tempo en testdiepte verschillen.
- Binnenkomst: melding of beschikbare update wordt vastgelegd, met datum en bron.
- Classificatie: klasse bepalen, getroffen systemen vaststellen aan de hand van de inventaris.
- Voorbereiding: back-up of snapshot, terugweg beschrijven, betrokkenen informeren.
- Test: eerst in staging of op een minder kritiek systeem.
- Installeren: in het afgesproken venster, systeem voor systeem.
- Herstart: alle getroffen diensten en processen, niet alleen de pakketten.
- Bewijs: pakketstatus, changelog-vermelding en processtart vastleggen.
- Controle: werking controleren, bij beveiligingslekken bovendien letten op sporen van een eerdere inbraak.
Stap 6 wordt verrassend vaak vergeten. PHP laadt zijn code bij de start van de processen. Zolang oude PHP-FPM-workers of Apache-processen met mod_php draaien, werken ze door met de oude, kwetsbare stand. Waarom dat zo is en hoe u juist herstart, leest u onder Na de update: PHP-FPM en alle workers herstarten.
Bewijsstukken die later tellen
Een patch zonder bewijs is in geval van twijfel niet geïnstalleerd, althans tegenover klanten, verzekeraars of auditors. Leg per systeem vast welke pakketstatus is geïnstalleerd, of de CVE-nummers in de changelog staan en wanneer de draaiende processen zijn gestart. Op Debian- en Ubuntu-systemen helpen daarbij alleen-lezen opdrachten zoals deze (pas de pakketnaam aan uw systeem aan):
# Bevat het geïnstalleerde pakket de correcties?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Wanneer zijn de draaiende PHP-FPM-processen gestart?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Ligt het starttijdstip van de processen vóór de installatie van het pakket, dan ontbreekt de herstart. Uitgebreid beschrijft dat CVE-nummers aantonen in de pakket-changelog.
Een patch dicht een lek voor de toekomst. Hij verwijdert geen schadelijke software die eerder is binnengebracht en bewijst niet dat er daarvoor niets is gebeurd. Bij noodpatches hoort een sporenonderzoek daarom vast bij het proces.
Automatiseren waar het veilig kan
Automatische beveiligingsupdates voor pakketten van het besturingssysteem nemen veel routinewerk uit handen. Ze ontlasten echter alleen als er back-ups zijn, iemand de resultaten leest en ook de getroffen diensten worden herstart. Hoe u dat onder Linux inricht en welke grenzen er zijn, beschrijft Automatische beveiligingsupdates op Linux-servers.
Containers hebben een eigen route nodig. Daar wordt niet in het draaiende systeem bijgewerkt, maar wordt de image met de gecorrigeerde PHP-versie opnieuw gebouwd en uitgerold. Een patchproces dat alleen servers kent, mist deze systemen gemakkelijk. Neem daarom ook buildpipelines en image-registries op in de lijst van patchroutes, met een verantwoordelijke persoon en hetzelfde bewijs als bij klassieke servers: welke PHP-versie draait in de uitgerolde container, en sinds wanneer?
Toepassingen, CMS en plug-ins hebben meestal een eigen, geteste route nodig, omdat updates daar vaker functies wijzigen. De vaste maanddatum is daarvoor de juiste plek. Belangrijk is dat uiteindelijk alle routes in dezelfde documentatie samenkomen: één plek waar u ziet welk systeem op welke stand zit.
Hoe helpt PHP SOS concreet?
- Wij leggen samen met u de patchklassen, vensters en goedkeuringen vast, afgestemd op uw systemen en uw organisatie.
- Wij richten waar zinvol automatische beveiligingsupdates in met herstartcontrole en melding.
- Wij nemen noodpatches over, inclusief herstart, bewijs en sporenonderzoek, via onze PHP-patchservice.
- Wij voeren het bewijs per systeem zo dat u het aan klanten, verzekeraars of auditors kunt voorleggen.
Conclusie: Patchbeheer lijkt onopvallend zolang het werkt. Precies dat is het doel: komt de volgende kritieke melding, dan loopt een ingeoefend proces en hoeft niemand te improviseren.
Veelgestelde vragen
Wat is het verschil tussen patchbeheer en kwetsbaarhedenbeheer?
Kwetsbaarhedenbeheer legt lekken vast, beoordeelt ze en besluit wat er moet gebeuren. Patchbeheer voert dat besluit uit: updates testen, installeren, diensten herstarten en het succes aantonen. Beide grijpen in elkaar.
Moeten beveiligingsupdates automatisch worden geïnstalleerd?
Voor pakketten van het besturingssysteem is dat vaak zinvol, mits er back-ups zijn en na afloop wordt gecontroleerd. Belangrijk is dat ook de getroffen diensten herstarten. Bij PHP blijven anders oude processen met de kwetsbare code in het geheugen staan.
Hoe toon ik aan dat een patch echt werkt?
Met de geïnstalleerde pakketstatus en de CVE-nummers in de pakket-changelog, het moment van installatie en het starttijdstip van de draaiende processen, dat na de installatie moet liggen.
Wat als een update iets kapotmaakt?
Daarvoor is er de terugweg: een back-up of snapshot vóór de update en een beschreven procedure om terug te draaien. Bij beveiligingsupdates moet terugdraaien de uitzondering zijn en gepaard gaan met een overbruggende maatregel.