Dependency-updatehygiëne voor MSP's: van beleid naar Renovate

Deze gids is voor MSP-platformteams die de kloof willen dichten tussen het moment waarop een leverancier een fix uitbrengt en het moment waarop het hele park die daadwerkelijk draait: wat je inventariseert, hoe vaak je dependencies beoordeelt, en waar een tool als Renovate het repetitieve werk kan automatiseren zonder de risicobeslissing te automatiseren.

Weet wat er draait

De meeste incidenten met dependencies zijn geen zero-days. Het zijn bekende fixes die weken of maanden eerder zijn uitgebracht voordat een aanvaller het gat tussen release en adoptie benutte. Voor MSP-platforms met klantgerichte infrastructuur begint het dichten van dat gat met een inventaris — idealiter een echte software bill of materials in plaats van een spreadsheet met hostnamen. Die moet de gebruikte versie, waar deze is blootgesteld en wie eigenaar is vastleggen. Zonder dat is een patchmelding onuitvoerbaar: een team kan niet zien welke systemen zijn geraakt zonder ze een voor een handmatig te controleren.

Stel een cadans in en houd je eraan

Een vaste reviewcadans — wekelijks, tweewekelijks, wat past bij de verandertolerantie van het platform — werkt beter dan ad-hoc patchen dat alleen door een nieuwskop wordt getriggerd. Gefaseerde uitrol vangt regressies op in een canarygroep voordat ze alle klanten bereiken, en een rollbackplan dat in hetzelfde changeticket staat als de update voorkomt dat een slechte patch uitgroeit tot een langdurige storing terwijl iemand ter plekke een oplossing improviseert.

Hygiëne is geen isolatie

Goede updatehygiëne vermindert hoe vaak een dependency met een bekend lek is blootgesteld, maar vervangt geen isolatiemaatregelen. Een kwetsbare library die fail-open gedraagt, raakt nog steeds alleen de straal die hij kan bereiken — en die is kleiner wanneer een platform één tenant per klant afdwingt dan wanneer tenants een grens delen. De twee vullen elkaar aan: hygiëne vermindert hoe vaak iets breekt, isolatie beperkt wat daarmee meebreekt.

De pull request automatiseren met Renovate

renovatebot/renovate is een van de meest gebruikte tools om dependencies actueel te houden: het scant de pakketbestanden van een repository en opent pull requests om verouderde versies op te hogen, in plaats van de wijzigingen direct door te voeren. Het project, onderhouden door Mend.io, is gegroeid naar ruim 22.000 GitHub-sterren en dekt meer dan 90 pakketbeheerders, waardoor het een gemengde MSP-stack kan bestrijken in plaats van per ecosysteem een aparte bot nodig te hebben. Schema's en pakketregels zijn per repository in te stellen, zodat een rumoerige dependency-boom in de code van de ene klant geen kritieke update bij een andere overstemt.

Behandel het als een backlog, geen stempel

Het werk van Renovate stopt bij de pull request; het merget of deployt niet zelf. Een mens, of een policybot die tests en een vulnerability-gate afdwingt, moet de wijziging alsnog goedkeuren. Door het te combineren met een fail-closed scangate dat een build blokkeert zodra een dependency een bekend lek bevat, ontstaat een taakverdeling tussen beide tools: Renovate stelt de fix voor, de gate beslist of de pipeline zonder die fix verder mag. Behandel de resulterende pull requests als een operationele backlog met een eigenaar en een streefdatum voor de merge, in plaats van aan te nemen dat een open PR gelijkstaat aan een gesloten risico. Teams die een gestructureerde externe check willen op hun eigen update- en kwetsbaarheidsbeheer kunnen ook een gerichte beoordeling laten uitvoeren; de cybersecuritydiensten van Altovar omvatten penetratietests, kwetsbaarheidsbeoordelingen, incident response en NIS2/DORA/GDPR-compliance.

Wat te doen

1. Bouw een inventaris — idealiter een SBOM — van dependencyversies en waar elke versie draait.
2. Stel een vaste reviewcadans in in plaats van alleen te patchen bij spraakmakende CVE's.
3. Zet een tool als Renovate aan om automatisch update-pull requests te openen, per repository ingesteld.
4. Combineer dit met een fail-closed gate die merges blokkeert zodra een dependency een bekend lek heeft.
5. Faseer uitrol via een canary-laag voordat je naar het hele park uitrolt.
6. Leg het rollbackplan vast in hetzelfde ticket als de update, voordat je die toepast.

Bronnen: CISA Known Exploited Vulnerabilities Catalog, renovatebot/renovate op GitHub.