Als de CVE komt, is het te laat

Istio brengt elke drie maanden een minor release uit. Patches komen vaker, vaak zonder veel gedoe. Klinkt planbaar.

In de praktijk zie ik regelmatig setups die al 18 maanden op dezelfde minor-versie staan. De reden: “Een update is te riskant, dat doen we als we er tijd voor hebben.”

Die tijd komt er niet. Die wordt genomen, meestal precies op het moment dat niemand meer tijd heeft.

Het typische verloop:

Er wordt een kritieke CVE gepubliceerd. Patch beschikbaar, maar alleen voor de laatste twee minor-versies. Je eigen setup loopt vijf releases achter. Opeens gaat het niet meer om “updaten wanneer het uitkomt”, maar om “updaten voor vrijdag, anders staat de compliance-afdeling op de stoep”.

Wat eerder werd verdedigd als beheerst risico, is binnen 24 uur veranderd in een ongeplande noodmigratie over vijf versiesprongen. Met alles wat daarbij hoort: breaking changes die niemand heeft getest. API deprecations die in de tussentijd hebben plaatsgevonden. Gedragsveranderingen in production traffic die in geen enkele changelog staan.

Patches zijn meestal stressvrij. Maar als er een CVE komt, staat de tent in de fik en heeft niemand een emmer bij de hand.

Dit is geen Istio-probleem. Het is een lifecycle-probleem.

Wat in de meeste setups ontbreekt:

Een vast proces voor quarterly updates dat niet elke keer opnieuw wordt uitgevonden. Een parallelle installatie of canary cluster waar development teams hun services tegen kunnen testen voordat de update naar productie gaat. Een helder beeld van welke eigen configuraties en CRD’s tussen versies compatibel blijven en welke niet.

In plaats daarvan zie ik vaak: updates worden behandeld als een project dat elk kwartaal weer van voren af aan begint. Discussie, risicobeoordeling, uitstel, op een gegeven moment frustratie, en dan toch maar niet. Dat werkt precies zo lang tot het niet meer werkt.

Wie Istio in production draait, heeft een quarterly lifecycle-probleem. Of je dat nu wilt toegeven of niet. Updates heeft iedereen nodig. De vraag is of jullie proces ook overeind blijft als een CVE opeens geen keuze meer laat.

Wie geen werkend proces heeft, heeft geen update-probleem. Die zit op een compliance-probleem dat tot nu toe gewoon nog niemand heeft getriggerd.

Welke onderwerpen zouden jullie in deze serie concreet verder helpen? Lifecycle, debugging, architectuur, multi-tenancy: zet het in de comments, dan verwerk ik dat in de komende weken.