Patchbeheer door derden: waarom het van cruciaal belang is en hoe je IT kunt automatiseren

Het dashboard voor patch-compliance geeft 96% aan. Windows is up-to-date, macOS is up-to-date, het beveiligingsteam geeft zijn goedkeuring en het rapport gaat naar de auditor. Het probleem is dat 96% alleen het beeld van het besturingssysteem weergeeft. Het endpoints dat onder die groene tegel zit, draait ook een Chrome-build van eind deze zomer, een Adobe Reader-versie met drie gepubliceerde CVE's, een Zoom-client die dateert van vóór het laatste beveiligingsadvies en een Java-runtime waar niemand in het team in de afgelopen achttien maanden nog aan heeft gedacht. Niets van dat alles komt terug in de score.

Dat is de kloof die patchbeheer voor applicaties van derden zou moeten dichten, en voor de meeste IT-teams en MSP’s is dit het deel van het patchprogramma dat, in verhouding tot het daadwerkelijke risico, stilletjes ondergefinancierd is. Uit de Qualys-benchmark voor ondernemingen uit 2026 blijkt dat de gemiddelde tijd die nodig is om complexe applicaties van derden te herstellen vijf maanden en tien dagen bedraagt. Aanvallers opereren binnen een tijdsbestek dat in dagen, soms zelfs in uren, wordt gemeten. Deze twee tijdschema’s zijn niet met elkaar verenigbaar.

De RMM-oplossingen van Kaseya verzorgen het patchbeheer voor miljoenen endpointsen voor MSP’s en interne IT-teams wereldwijd. Ze bieden een duidelijk operationeel beeld van waar patchprogramma’s van derden onder druk standhouden en waar ze tekortschieten. In deze gids wordt uitgelegd wat patchbeheer door derden inhoudt, waarom de uitvoering ervan lastiger is dan het patchen van besturingssystemen, waar de prioriteit moet liggen, hoe het programma operationeel moet worden opgezet en wat automatisering moet bieden om gelijke tred te houden met het releasetempo.

Wat is patchbeheer door derden?

Patchbeheer voor software van derden is het proces waarbij updates worden geïdentificeerd, geëvalueerd, geïmplementeerd en gecontroleerd voor de software die op uw eindapparaten draait en die niet door de leverancier van het besturingssysteem wordt geleverd. Dat is een brede categorie. Denk hierbij aan browsers, PDF-lezers, conferentieprogramma’s, runtime-omgevingen zoals Java en .NET, productiviteitspakketten, ontwikkeltools, compressieprogramma’s en de lange reeks bedrijfsapplicaties die zich in de loop van de tijd in elke omgeving opstapelen.

Het valt onder dezelfde bredere discipline van patchbeheer als het patchen van besturingssystemen, maar kent andere beperkingen. Microsoft, Apple en de grote Linux-distributies leveren hun updates via gestandaardiseerde, goed georganiseerde kanalen. Externe leveranciers doen dat niet. Er is geen ‘Patch Tuesday’ voor Slack. Er is geen centrale catalogus die het releaserooster van Adobe koppelt aan dat van Mozilla, aan dat van Oracle en aan de niche-bedrijfsapplicatie die het financiële team in 2019 heeft geïnstalleerd. Elke leverancier brengt updates uit volgens zijn eigen ritme, in zijn eigen formaat en via zijn eigen kanaal, en iemand moet ze allemaal tegelijk bijhouden.

De term ‘derde partij’ heeft hier een brede betekenis. Het omvat alles, van een browser die door alle gebruikers binnen het bedrijf wordt gebruikt tot een gespecialiseerde technische tool die op drie computers is geïnstalleerd. Beide vallen onder dezelfde operationele noemer en beide kunnen het startpunt vormen voor een inbreuk.

Waarom het installeren van patches van derden belangrijker is dan ooit

Jarenlang was de gangbare opvatting dat kwetsbaarheden in besturingssystemen de grootste zorg vormden en dat applicaties slechts een ondergeschikte zorg waren. Dat is al een tijdje niet meer het geval. De gegevens hebben zich gestaag aangepast aan wat aanvallers al wisten.

Uit het onderzoek ‘State of Patch Management 2025’ van Adaptiva, dat in samenwerking met Demand Metric werd uitgevoerd, bleek dat 87% van de organisaties het afgelopen jaar te maken had gehad met kwetsbaarheden in applicaties van derden waarvoor patches nodig waren. Dat is geen uitzondering. Het is de normale gang van zaken in vrijwel elke IT-omgeving waarin moderne software wordt gebruikt.

De CISA-catalogus van bekende misbruikte kwetsbaarheden (KEV ) vertelt hetzelfde verhaal vanuit een andere invalshoek. De KEV-lijst bevat kwetsbaarheden die actief door aanvallers worden misbruikt, niet alleen theoretische kwetsbaarheden met een CVSS-score, en een aanzienlijk deel van de nieuwe vermeldingen betreft applicaties van derden in plaats van de kern van besturingssystemen. Browsers, documentlezers, conferentietools en runtime-bibliotheken duiken maand na maand op. Ze worden op grote schaal ingezet, er worden regelmatig beveiligingsupdates voor uitgebracht, en de kloof tussen de release door de leverancier en de installatie door de eindgebruiker is precies waar aanvallers hun werk doen.

Het tempo maakt het nog ingewikkelder. Tijdens de Patch Tuesday van Microsoft in april 2026 werden alleen al in de eigen softwarestack 163 CVE’s aangepakt. Tel daar nog Adobe, Oracle, Google, Mozilla, Cisco, Atlassian en een tiental andere bedrijven bij op – en het maandelijkse volume waarmee elk patchprogramma gelijke tred moet houden, begint echt een zware opgave te worden. Het handmatig doorlopen van een feed van die omvang is geen strategie.

Uit het Verizon Data Breach Investigations Report 2025 bleek dat bij 20% van de datalekken misbruik van kwetsbaarheden de eerste toegangsweg was — een stijging van 34% ten opzichte van vorig jaar. Die stijging is niet alleen toe te schrijven aan zero-day-kwetsbaarheden op besturingssysteemniveau. Ze weerspiegelt de gestage toename van het misbruik van kwetsbaarheden in software van derden waarvan organisaties ofwel niet wisten dat ze die gebruikten, ofwel nog niet aan het patchen waren toegekomen.

Uitdagingen bij het beheer van patches van derden

Als je eenmaal weet dat het risico reëel is, rijst natuurlijk de vraag waarom zoveel programma’s die kwetsbaarheid dan toch open laten. Het antwoord is van technische aard, niet van motivatie. Het patchen van software van derden is structureel moeilijker dan het patchen van het besturingssysteem, en wel om vier onderling samenhangende redenen.

Versnippering van leveranciers

De update-infrastructuur van Microsoft is bedoeld voor Microsoft-software. Die van Apple is bedoeld voor macOS. Voor de rest bestaat er geen vergelijkbaar, uniform kanaal. Elke ISV onderhoudt zijn eigen releaseportaal, zijn eigen adviesformaat en zijn eigen distributiemechanisme. Het handmatig bijhouden van releases voor 50 of 100 applicaties van derden betekent dat je je moet abonneren op tientallen afzonderlijke feeds en elke feed moet omzetten in concrete actie. Dat is een fulltime functie waarvoor de meeste teams geen personeel hebben.

Variabiliteit in cadans

Patch Tuesday biedt je een vast ritme voor Windows. Releases van derden volgen geen vast ritme. Een kritieke browserfix kan halverwege de week verschijnen. Een runtime-update kan zonder voorafgaande aankondiging worden uitgebracht. Een conferentietool kan een beveiligingsupdate uitbrengen op dezelfde dag dat een leverancier van printerstuurprogramma’s een CVE publiceert. Het aantal updates is niet voorspelbaar en de timing evenmin, wat betekent dat een patchprogramma dat is opgezet rond een maandelijkse cyclus, door zijn opzet regelmatig tijdgevoelige updates van derden zal missen.

Diversiteit onder installateurs

OS-patches worden via gestandaardiseerde mechanismen geleverd. Toepassingen van derden maken gebruik van MSI, EXE, MSIX, App-V, leveranciersspecifieke updaters, webgebaseerde installatieprogramma’s en af en toe een op maat gemaakt implementatiescript. Elk formaat heeft zijn eigen vlaggen voor stille installatie, zijn eigen herstartgedrag, zijn eigen logica voor versiedetectie en zijn eigen foutmodi. Om deze verscheidenheid betrouwbaar te automatiseren, is ofwel een tool nodig met door de leverancier geteste ondersteuning voor elke toepassing, ofwel aangepaste scripts die voor onbepaalde tijd door uw team moeten worden onderhouden.

Ontdekking

Je kunt geen patches aanbrengen op iets waarvan je niet weet dat het er is. Gebruikers installeren applicaties buiten de door IT goedgekeurde kanalen om. Bij overnames worden onbeheerde softwareparken overgenomen. Afdelingen standaardiseren op tools waarvan het endpointteam niets heeft gehoord. Zonder continue, agent-gestuurde detectie die elke geïnstalleerde applicatie en versie op elk beheerd apparaat in kaart brengt, werkt het patchprogramma op basis van een inventaris die al onjuist is voordat het van start gaat.

Deze vier beperkingen verdwijnen niet door er hard aan te werken. Het zijn eigenschappen van het ecosysteem van software van derden zelf. Een goed werkend programma is een programma dat hierop is afgestemd in plaats van ertegenin te gaan.

Welke toepassingen verdienen het om als eerste prioriteit te krijgen?

Niet elke applicatie van derden brengt hetzelfde risico met zich mee — en door ze als één homogene groep te behandelen, lopen programma’s uiteindelijk hetzelfde risico als wanneer er helemaal geen programma’s zouden zijn. De juiste aanpak is om ze in categorieën in te delen op basis van de omvang van de implementatie, de geschiedenis van misbruik en de nabijheid van de netwerkrand, en vervolgens de frequentie van updates en de SLA te concentreren op de hoogste categorie.

Browsers staan bovenaan vrijwel elke lijst. Chrome, Edge, Firefox en Brave zijn op elk endpoints geïnstalleerd, geven per definitie onbetrouwbare inhoud van het internet weer en ontvangen meerdere keren per maand beveiligingsupdates. Vaak stellen ze de toepassing van updates uit tot na een herstart, wat betekent dat een beschikbare patch pas daadwerkelijk wordt geïnstalleerd als de gebruiker het venster sluit. Een SLA van 24 tot 48 uur voor kritieke browserupdates, met handhaving, is een redelijke basisnorm.

Vervolgens zijn er PDF- en documentlezers. Adobe Acrobat en Reader hebben een lange lijst met kritieke CVE’s en worden al jarenlang aangevallen via kwaadaardige documenten die via e-mail worden verspreid. Het installeren van de nieuwste versie op elk endpoints is voor de meeste teams de goedkoopste manier om het succespercentage van phishing-aanvallen aanzienlijk te verlagen.

Runtime-omgevingen vormen de derde groep. Java, OpenJDK, de .NET-runtimes en diverse JavaScript-engines vormen de basis voor bedrijfsapplicaties die voor beveiligingstools wellicht niet als afzonderlijke afhankelijkheden zichtbaar zijn. Een kwetsbaarheid in een runtime heeft gevolgen voor elke applicatie die daarop is gebouwd, en de omvang van de schade kan groot zijn, zelfs als de runtime zelf vrij onbekend lijkt.

Clients voor videoconferenties en samenwerking bevinden zich in een vierde categorie. Zoom, Teams (in de vorm van een zelfstandige installatie), Slack en soortgelijke tools worden overal geïnstalleerd, werken met onbetrouwbare externe links en bestanden, en worden regelmatig bijgewerkt. Hun aanvalsoppervlak is vergelijkbaar met dat van een browser, ook al wordt hun aanwezigheid in de inventaris van bedrijfsmiddelen anders weergegeven.

Compressieprogramma’s, archiveringshulpmiddelen, afhankelijkheden voor ontwikkelaars en de lange staart van bedrijfsapplicaties vullen het geheel aan. Ze dragen elk een aanzienlijk deel van het risico, en het juiste kader om ze te rangschikken is hetzelfde risicogebaseerde model dat ook voor het patchen van besturingssystemen zou moeten gelden: ernst (CVSS), exploitatiestatus (KEV-lijst, threat-intelligence-feeds, openbare exploits) en bedrijfscontext (in verbinding met het internet, gevoelige gegevens, potentieel voor laterale beweging). Zie de best practices voor patchbeheer voor meer informatie over het integreren van dat raamwerk in het bredere programma.

Beste praktijken voor het toepassen van patches van derden: hoe stel je een programma op?

Een goed functionerend patchprogramma van een derde partij volgt in grote lijnen hetzelfde verloop als het bredere patchbeheerproces, maar bij de uitvoering in elke fase moet rekening worden gehouden met de extra complexiteit die software van een derde partij met zich meebrengt.

Het inventariseren van systemen moet continu, agentgestuurd en volledig zijn. Een wekelijkse software-audit van het activaregister volstaat niet. De agent moet elke geïnstalleerde applicatie, elke versie en elke door de gebruiker geïnstalleerde instantie op elk beheerd endpoints in kaart brengen, en deze gegevens vrijwel in realtime bijwerken. Zodra dat inzicht wegvalt, is het patchprogramma precies in die mate blind.

Monitoring volgt hetzelfde principe. Zodra je weet wat er is geïnstalleerd, heb je een feed nodig die je laat weten wanneer elke leverancier een beveiligingsupdate uitbrengt, bij voorkeur ingedeeld naar ernst. Het is een hele klus om die feed intern op te zetten voor vijftig leveranciers. De realistische oplossing is een patching-tool waarvan de leverancier nieuwe releases binnen enkele uren na publicatie door de leverancier toevoegt aan een geteste catalogus, zodat het team één feed hoeft te volgen in plaats van vijftig.

Op het gebied van prioritering wijkt het patchen van applicaties van derden in de praktijk het vaakst af van het patchen van het besturingssysteem. De hierboven beschreven risicoclassificatie wordt rechtstreeks verwerkt in uw SLA-structuur, die expliciet in uw patchbeheerbeleid moet worden vastgelegd. Een beleid waarin applicaties van derden worden genoemd, deze worden ingedeeld in ernstniveaus met vastgelegde SLA’s en waarin gedocumenteerde uitzonderingen worden vereist, maakt een einde aan de impliciete prioritering van „eerst het besturingssysteem, daarna applicaties van derden”, die de kloof in de eerste plaats veroorzaakt.

Het testen verloopt echt anders. OS-patches worden vóór de release gecontroleerd door Microsoft, Apple of de betreffende Linux-beheerder. Patches van derden worden gecontroleerd door de ISV en, idealiter, door de kwaliteitscontrole van de catalogus van uw patchplatform. Het resterende risico is interactie tussen applicaties: een browserupdate die het weergavegedrag verandert en een interne webapp onbruikbaar maakt, een Java-runtime-update die compatibiliteitsproblemen met een bedrijfssoftwarepakket aan het licht brengt, een Teams-build die een aangepaste integratie beïnvloedt. Een kleine pilotring van representatieve endpointsen, met een wachttijd van 24 tot 48 uur voor routine-updates en een verkorte smoke-test voor actief misbruikte kwetsbaarheden, vangt het meeste hiervan op voordat het de productie bereikt.

Bij de implementatie wordt de geteste update binnen de door u vastgestelde onderhoudsvensters naar de rest van het netwerk uitgerold, met een herhalingslogica voor endpointsen die bij de eerste poging offline waren en terugdraaipaden voor het geval er fouten optreden. Dit is het deel van het programma dat het meest in het oog springt wanneer het handmatig wordt uitgevoerd, omdat de omvang ervan de beschikbare uren opslokt en de afhandeling van uitzonderingen het routinewerk verdringt.

Verificatie maakt de cirkel rond. Het signaal dat voor jou van belang is, is de geïnstalleerde versie, niet de implementatiestatus. Een implementatierapport kan ‘verzonden’ aangeven, terwijl een stille installatiefout ervoor zorgt dat de oude versie op het apparaat blijft staan. Alleen door per applicatie en per apparaat te controleren welke versie daadwerkelijk draait, weet je of de patch ook echt is geïnstalleerd.

De rapportage is per applicatie, niet per apparaat. Een apparaat waarop de nieuwste versie van Chrome draait, maar waarop Java drie versies achterloopt, voldoet in geen enkel opzicht aan de eisen die een auditor zou accepteren. De rapportage moet worden uitgesplitst per applicatie, per ernstniveau en per SLA-overtreding, met de uitsplitsingen per klant die MSP’s nodig hebben voor verklaringen aan hun klanten.

Waarom geautomatiseerd patchbeheer door een externe partij essentieel is

Zonder dat klopt de rekensom gewoon niet. Vijftig applicaties van derden, tientallen releases per maand per grote leverancier, honderden of duizenden endpointsen, release-schema’s van leveranciers die niet op elkaar aansluiten en SLA’s die voor de patches met het hoogste risico in uren worden gemeten. Geen enkel team kan dat handmatig bijhouden — en degenen die het toch proberen, raken als eerste achterop bij de software van derden, omdat de kosten van die achterstand daar in de dagelijkse praktijk het minst zichtbaar zijn.

Geautomatiseerd patchbeheer neemt het routinematige werk uit handen van het team: vaststellen dat een applicatie een update nodig heeft, het geteste pakket uit de catalogus ophalen, het via een stille installatie implementeren tijdens het afgesproken onderhoudsvenster, het afhandelen van herstarts en het opnieuw proberen bij mislukkingen. Mensen blijven betrokken bij het afhandelen van uitzonderingen, het goedkeuren van wijzigingsvensters voor gevoelige systemen en het kleine percentage applicaties dat daadwerkelijk handmatige tussenkomst vereist.

Er zijn twee aspecten die specifiek zijn voor automatisering door derden en die het vermelden waard zijn, omdat ze in de bredere discussie over automatisering onvoldoende aandacht krijgen.

Ten eerste is er de kwaliteit van de catalogus. Automatisering is slechts zo goed als de applicatiecatalogus waarop deze is gebaseerd. Een platform dat twee weken nodig heeft om een cruciale browserupdate te verwerken, biedt gedurende die periode even weinig beveiliging als helemaal geen platform. De vragen die het stellen waard zijn bij het evalueren van patchmogelijkheden van derden zijn: hoeveel applicaties worden standaard ondersteund, hoe snel worden nieuwe releases van leveranciers in de catalogus opgenomen (met name voor beveiligingsupdates) en welke kwaliteitscontrole wordt er op elk pakket toegepast voordat het de productie-endpoints bereikt?

Het tweede punt is de afhankelijkheidssfeer. Een slechte OS-patch leidt vaak tot storingen in het besturingssysteem. Een slechte patch van een derde partij leidt vaak tot storingen in de applicatie die ervan afhankelijk is, wat kan betekenen dat een bedrijfsworkflow, een integratie of een productiviteitstool die het hele bedrijf gebruikt, niet meer werkt. De risicobeperkende maatregelen zijn dezelfde als bij elk patchprogramma: implementatieringen, wachttijden en geautomatiseerde terugdraaiing. De operationele tolerantie voor storingen is echter lager, omdat gebruikers een storing in Adobe Reader sneller opmerken dan een kernelupdate.

Het nalevingsaspect

Compliance-kaders doen niet langer alsof software van derden een apart aandachtspunt is. PCI DSS 4.0-eis 6.3.3 heeft betrekking op alle systeemcomponenten, waaronder applicaties, en niet alleen op besturingssystemen. ISO 27001:2022 Bijlage A 8.8 behandelt het beheer van technische kwetsbaarheden zonder uitzonderingen. De beveiligingsregel van de HIPAA is in handhavingsmaatregelen geïnterpreteerd als zijnde van toepassing op het patchen van applicaties als onderdeel van „redelijke en passende“ beveiligingsmaatregelen. NIS2, dat in alle EU-lidstaten van kracht is, vereist bewijs van tijdige afhandeling van kwetsbaarheden, waarbij geen onderscheid wordt gemaakt tussen besturingssystemen en applicaties. SOC 2 Trust Services Criteria CC7.1 heeft betrekking op monitoring en herstelmaatregelen voor nieuwe kwetsbaarheden in het gehele systeem.

De praktische consequentie is in alle gevallen dezelfde. Een audit waarbij uw patchprogramma wordt onderzocht en waarbij onbeheerde browsers, niet-gepatchte PDF-readers of Java-runtimes waarvan de levensduur is verstreken worden aangetroffen, zal bevindingen opleveren, ongeacht hoe vlekkeloos uw Windows-nalevingsrapport eruitziet. De verdediging tegen die bevinding bestaat uit operationeel bewijs: nalevingsrapportages per applicatie, gedateerde implementatiegegevens, gedocumenteerde uitzonderingen en SLA’s die in de praktijk worden nageleefd en niet alleen op papier.

Hoe Kaseya het installeren van patches van derden vereenvoudigt

Het aanbrengen van patches door derden is geen kennisprobleem. Elk IT-team en elke MSP weet dat applicaties gepatcht moeten worden. Het is een operationeel probleem, en dat operationele probleem is structureel van aard: meer leveranciers, meer patchcycli, meer installatieformaten, een groter detectieoppervlak en een standaardworkflow die de voorkeur geeft aan het patchen van besturingssystemen, omdat dat gemakkelijker te automatiseren is.

De oplossing is om third-party niet langer als een parallel programma te behandelen, maar het binnen hetzelfde raamwerk te brengen als de werkzaamheden die al lopen. Dezelfde inventaris. Dezelfde risicoclassificatie. Dezelfde SLA's in het beleid. Dezelfde implementatieringen. Dezelfde automatisering. Dezelfde nalevingsrapportage per applicatie. De onderliggende tooling moet een geteste catalogus van derde partijen ondersteunen in het tempo waarin leveranciers daadwerkelijk releases uitbrengen, maar het programmaontwerp is geen apart programma. Het is hetzelfde programma, met een volledige reikwijdte.

Dat ontwerpprincipe vormt de basis van de RMM-oplossingen van Kaseya: het installeren van patches voor besturingssystemen, software van derden en firmware verloopt via één agent, één beleidskader, één reeks onderhoudsvensters en één compliance-overzicht. De module ‘Advanced Software Management’ van Datto RMMis de genoemde functie voor software van derden, die de patchdekking uitbreidt tot meer dan 200 kant-en-klare applicaties met een catalogus die vóór de release op miljoenen apparaten is getest en voortdurend wordt uitgebreid.

De module ondersteunt ook het installeren en verwijderen van applicaties via hetzelfde beleidsraamwerk, waarmee een lacune wordt gedicht die de meeste patchingtools openlaten: applicaties waarvan de levensduur is verstreken en die moeten worden verwijderd – en niet alleen bijgewerkt – voordat er misbruik van kan worden gemaakt. Voor MSP’s betekent dit dat ze vanuit één console beleidsconfiguraties per klant kunnen uitvoeren en nalevingsrapportages per klant kunnen genereren. Voor interne IT-teams biedt het een uniform overzicht van de patchstatus van zowel het besturingssysteem als software van derden, inclusief het audittraject dat nalevingskaders vereisen. Dit overzicht ontstaat als bijproduct van de workflow en is geen kwartaalactiviteit waarbij bewijsmateriaal moet worden verzameld.

Het alternatief is dat een gedocumenteerd aanvalsoppervlak blootgesteld blijft, terwijl het dashboard voor OS-patches op groen blijft staan. Dat is precies de zwakke plek waarop aanvallers inspelen — en uit de huidige gegevens over misbruik blijkt dat ze daar gelijk in hebben.