Je software werkt nog. Maar loop je ongemerkt risico?

Je bestellingen komen binnen, medewerkers kunnen hun planning openen en klanten gebruiken het portaal. Als ondernemer zie je een systeem dat doet wat het moet doen. Wat je aan een werkend scherm niet kunt zien, is of de software eronder nog beveiligingsupdates krijgt.

Daardoor kun je ongemerkt bedrijfsrisico lopen, ook als je applicatie gewoon blijft werken. Dat vraagstuk speelt bij iedere technologie waarvan de gebruikte versie het einde van haar ondersteuning bereikt: van PHP en Python tot frameworks, databases en besturingssystemen. De concrete kwetsbaarheden en gevolgen verschillen per onderdeel en toepassing.

Bij End of Life (EOL) eindigt de ondersteuning voor een versie binnen het betreffende supportbeleid. Controleer vooral of je nog beveiligingsupdates ontvangt en van wie.

De vraag die je als ondernemer wilt kunnen beantwoorden: wie houdt dit overzicht bij, en wat gebeurt er wanneer ondersteuning stopt?

Wat betekent End of Life precies?

De maker bepaalt per versie welke reparaties nog worden geleverd en tot wanneer. De termen verschillen per leverancier, maar grofweg kom je drie situaties tegen:

• Actieve ondersteuning: de versie krijgt binnen het supportbeleid onderhoud, zoals bugfixes en beveiligingsupdates.
• Securityondersteuning: de ondersteuning is beperkter; bijvoorbeeld alleen nog reparaties voor bepaalde beveiligingsproblemen.
• End of Life: de ondersteuning voor deze versie binnen het betreffende beleid is beëindigd. Ga na of dit ook het einde van de beveiligingsupdates betekent.

Het einde van actieve ondersteuning is dus niet altijd EOL: beveiligingsupdates kunnen nog doorlopen. PHP kent bijvoorbeeld na actieve ondersteuning een periode voor kritieke securityproblemen. Pas daarna bereikt een release zijn EOL. PHP-supportbeleid.

EOL gaat hier over een specifieke versie of productlijn, niet over een programmeertaal die als geheel verdwijnt. De uitvoeromgeving voor PHP of Python, een framework zoals Laravel of Django en een database hebben elk een eigen levenscyclus.

Een leverancier kan na de oorspronkelijke supportperiode aanvullende beveiligingsupdates leveren. Laat aantonen voor welke versie, voor welke problemen en tot wanneer die dekking geldt.

Waarom je als ondernemer ongemerkt risico kunt lopen

Dat de ontwikkelaar nieuwe functies oplevert, toont op zichzelf niet aan dat ook het framework, de database en het besturingssysteem worden bijgewerkt. Een onderhoudsafspraak moet duidelijk maken welke onderdelen worden onderhouden en wie hun supporttermijnen bewaakt.

Een hypothetisch voorbeeld: een bedrijf laat regelmatig functies toevoegen aan zijn klantportaal. Klanten kunnen blijven inloggen en orders volgen. De database valt echter buiten de afgesproken onderhoudswerkzaamheden. Wanneer die versie geen beveiligingsupdates meer krijgt, verandert er voor de gebruiker niets zichtbaars. Zonder iemand die de supporttermijn bewaakt, kan de ondernemer denken dat het hele portaal wordt onderhouden.

Je hoeft als ondernemer niet ieder versienummer te kennen. Je moet wel kunnen vaststellen wie het overzicht heeft en handelt voordat een supporttermijn verstrijkt. Dat voorkomt dat je dit pas tijdens een storing of securitymelding moet uitzoeken.

Wat het PHP-incident leert over softwareonderhoud

Op 21 oktober 2026 publiceerde het PHP-team beveiligingsupdates voor twee kritieke kwetsbaarheden. Ook ondersteunde PHP-versies hadden die updates nodig. Het NCSC meldde dat organisaties websites uit voorzorg offline hadden gehaald en adviseerde de beschikbare patches te installeren. In een latere update nuanceerde het NCSC de ingeschatte kans op grootschalig misbruik, maar het patchadvies bleef staan. PHP-aankondigingen, NCSC-update.

De bredere les: ook met een ondersteunde versie moet je beschikbare patches kunnen installeren. Wie tijdens een incident eerst moet achterhalen waar de broncode staat of wie de applicatie beheert, moet tegelijk achterstallig beheer oplossen.

Softwareonderhoud is onderdeel van cybersecurity

Beveiligingsupdates horen bij softwareonderhoud én cybersecurity. Spreek af wie ze uitvoert, ook als beveiliging en applicatieontwikkeling bij verschillende partijen liggen.

Uitgesteld onderhoud kan de volgende update ingewikkelder maken. Een nieuwere uitvoeromgeving vraagt mogelijk om een ander framework, dat weer niet met een oude uitbreiding werkt. Zonder passende tests is bovendien lastig vast te stellen of de belangrijkste bedrijfsfuncties blijven werken.

Zo verandert een onderhoudstaak in een afweging over dienstverlening: kunnen orders nog worden verwerkt, kunnen medewerkers hun planning zien en kunnen klanten hun gegevens bereiken?

Zet supporteinddata daarom op de onderhoudsplanning, met een eigenaar en een vervolgstap.

Welke veelgebruikte softwareversies verdienen aandacht?

Onderstaande voorbeelden zijn geen volledige EOL-inventarisatie of beoordeling van jouw omgeving. Dezelfde vragen gelden voor technologieën die niet in de tabel staan.

Peildatum: 30 oktober 2026. De genoemde einddatum betreft de aangegeven ondersteuningsvorm. Controleer ook de exacte geïnstalleerde versie, patches, leverancier en eventuele aanvullende afspraken.

Bronnen bij de tabel: PHP · Python · Microsoft · Laravel · Django · PostgreSQL · MariaDB · Microsoft

“Versie X of lager” is geen universele beslisregel. Een oudere LTS-release kan langer ondersteuning krijgen dan een nieuwere release met een kortere looptijd. Bij .NET eindigde de ondersteuning van versie 6 bijvoorbeeld later dan die van versie 7. Microsoft-supportbeleid.

Kijk bovendien vooruit. Op de peildatum staan ook ondersteunde releases dicht bij hun einddatum: .NET 8 en 9 op 10 november 2026, PostgreSQL 14 op 12 november 2026 en PHP 8.2 op 31 december 2026. Een onderhoudsplan moet voldoende ruimte laten om de vervolgstap te onderzoeken en te testen. Microsoft, PostgreSQL, PHP.

Wanneer wordt EOL een bedrijfsrisico?

EOL is een belangrijk signaal, maar geen bewijs dat een systeem is gehackt. Andersom bewijst een ondersteund versienummer niet dat alle actuele patches zijn geïnstalleerd. Microsoft stelt voor ondersteunde .NET-releases bijvoorbeeld ook als voorwaarde dat systemen bijblijven met uitgebrachte patchupdates. Microsoft-supportbeleid.

Om prioriteit te bepalen, moet je verder kijken dan de kalender:

Blootstelling. Is de toepassing bereikbaar vanaf internet? Welke gebruikers en andere systemen hebben toegang? Een intern systeem heeft andere toegangspaden dan een openbaar klantportaal, maar intern gebruik sluit een beveiligingsrisico niet uit.

Gegevens en bedrijfsfunctie. Wat kan iemand bereiken als de toepassing wordt misbruikt? Welke dienstverlening stopt wanneer je haar moet uitschakelen? Neem ook koppelingen met andere processen mee.

Beschikbare reparaties. Levert de oorspronkelijke maker nog patches? Zo niet, bestaat er aantoonbare aanvullende ondersteuning die jouw installatie dekt? Een algemeen onderhoudscontract beantwoordt die vraag niet vanzelf.

Uitvoerbaarheid. Kun je een patch testen en uitrollen? Zijn broncode, toegangsrechten, afhankelijkheden en documentatie beschikbaar? Is er meer dan één persoon die het systeem kan beheren?

Herstel. Kun je na een mislukte wijziging terug naar een werkende situatie? Zijn herstelprocedures getest? Back-ups helpen bij herstel, maar repareren de oorspronkelijke kwetsbaarheid niet.

Gebruik deze vragen om prioriteiten te bespreken. Volg bij een concrete kwetsbaarheid de actuele aanwijzingen van de maker, je leverancier en het NCSC.

Wat als je applicatie niet eenvoudig te updaten is?

Een moeilijke upgrade betekent niet automatisch dat je alles opnieuw moet bouwen. Maak eerst onderscheid tussen het acute probleem en de structurele blokkade.

Bij een beschikbare beveiligingspatch onderzoek je hoe die verantwoord kan worden toegepast. Voor de genoemde PHP-kwetsbaarheden waarschuwde het PHP-team dat tijdelijke beschermingsmaatregelen geen volledige oplossing boden: updaten was noodzakelijk. PHP-aankondigingen.

Wanneer de gebruikte versie geen reguliere ondersteuning meer heeft, beoordeel je de route naar een ondersteunde situatie. Soms volstaat een upgrade met beperkte codeaanpassingen. Soms moeten eerst een framework of verouderde afhankelijkheden worden aangepakt. Een gefaseerde modernisering kan helpen wanneer onderdelen afzonderlijk vernieuwd kunnen worden en de continuïteit daarmee beter te beheersen is.

Vervanging of herbouw kan passend zijn als de bestaande toepassing slecht aansluit op het bedrijfsproces, essentiële onderdelen niet meer onderhoudbaar zijn of gerichte aanpassingen geen werkbare toekomst bieden. Vergelijk ook standaardsoftware als die het proces voldoende ondersteunt. Laat de keuze volgen uit de beperkingen en bedrijfsbehoefte.

Aanvullende ondersteuning kan in sommige gevallen tijd geven om te migreren. MariaDB onderscheidt bijvoorbeeld verschillende supportvormen; Microsoft kent voor SQL Server 2016 een ESU-programma. Controleer de dekking en verbind de tijdelijke oplossing aan een einddatum en een migratieplan. MariaDB, Microsoft ESU.

Vijf vragen die je vandaag aan je IT-partner kunt stellen

Begin met één concrete opdracht: vraag je IT-partner om een overzicht van je belangrijkste applicaties, hun onderliggende versies, supporteinddata en de verantwoordelijke voor updates. Gebruik dat overzicht voor deze vijf vragen:

1. Welke versies gebruiken onze bedrijfskritische applicaties? Vraag ook naar runtimes, frameworks, databases en besturingssystemen.
2. Welke ondersteuning krijgen die versies en wanneer stopt die? Laat eventuele verlengde dekking aantonen.
3. Wie volgt beveiligingsmeldingen op en voert patches uit? Spreek af hoe urgentie en verantwoordelijkheid worden bepaald.
4. Hoe testen en herstellen we wijzigingen? Vraag hoe de belangrijkste bedrijfsfuncties worden gecontroleerd en hoe terugvallen werkt.
5. Wat doen we met onderdelen die niet meer veilig bijgewerkt kunnen worden? Vraag om opties, afhankelijkheden, een verantwoordelijke en een planning.

Stel deze vragen voor alle software waarvan je bedrijf afhankelijk is, ook als je geen PHP gebruikt. Begin bij één bedrijfskritische applicatie en leg vast wat er moet gebeuren, wie dat oppakt en wanneer. Zo maak je het risico zichtbaar voordat een incident je tot een spoedbesluit dwingt.

Onderzoek wat je met je bestaande software kunt behouden

Is een bedrijfskritische applicatie moeilijk te onderhouden of te veranderen? Met de Legacy Rescue Scan beoordeelt Syntograde het bestaande systeem, zijn afhankelijkheden en mogelijke moderniseringsroutes. Je ontvangt een gefaseerde aanbeveling voor een af te bakenen vervolgstap. De scan is geen garantie dat ieder systeem behouden kan blijven.

Onderzoek je legacysoftware.