Open source is de afgelopen decennia uitgegroeid tot een fundament onder vrijwel elke digitale keten. Maar de afgelopen jaren is duidelijk geworden dat betrouwbaarheid geen vanzelfsprekendheid is. De dreiging uit de wereld van supply chain-aanvallen, kwetsbaarheden op schaal en geautomatiseerde exploitatie maakt iets pijnlijk zichtbaar: voor organisaties telt niet alleen of code ‘open’ is, maar of die code op het juiste moment nog te vertrouwen is. Dat is precies waarom we kunnen spreken over open source volwassen security.
Waar veel mensen de afgelopen tijd “open source is dood” riepen, is een genuanceerder beeld waarschijnlijker. Licenties blijven bestaan. Wel verschuift het gebruiksmodel: enterprises gaan steeds meer kiezen voor een subset van projecten die aantoonbaar leeft, snel kan herstellen en procesmatig afspraken ondersteunt. In dit artikel zetten we uiteen wat er verandert, welke eisen daarbij horen en hoe dit gevolgen heeft voor beheer, leveranciers en migratiekeuzes.
Open source verdwijnt niet: het wordt selectiever gebruikt
De kern van open source zit in licentiedefinities en het feit dat partijen die licenties blijven erkennen. Dat is geen detail dat plots verdwijnt. In plaats daarvan verandert wat organisaties bereid zijn te consumeren — en, op termijn, wat ze simpelweg moeten kunnen aantonen in gereguleerde omgevingen.
Het gevolg is een splitsing. Aan de ene kant komt open source die voldoet aan de voorwaarden die ondernemingen nodig hebben: bereikbaarheid, een duidelijke disclosure-route, aantoonbare actualiteit en patchcapaciteit zodra er nieuwe kwetsbaarheden opduiken. Aan de andere kant blijft open source bestaan die niet aan die eisen (kan of wil) voldoen. Die projecten verdwijnen niet, maar worden minder vaak een dragende keuze voor risicovolle ketens.
De echte breuklijn: niet de licentie, maar de ‘state’
Een licentie is niet het belangrijkste onderscheid. De vraag is: is het project in de praktijk nog een betrouwbare partner? Is het aanspreekbaar als er iets misgaat? Kan het laten zien dat het actief onderhoudt? En is het in staat om de volgende update te leveren wanneer geautomatiseerde aanvallen de kwetsbaarheid al hebben gevonden?
Daarmee verandert de discussie van “mag het?” naar “kan het op het juiste moment?”. Het is een houding die een project inneemt, niet een nieuwe vork in de licentiewereld. Sommige projecten gaan die houding wél aannemen, andere niet — en ondernemingen zullen daar hun afhankelijkheden en risicoprofielen op aanpassen.
Proof of life: waarom je niet kunt wachten tot het te laat is
Een lastig punt in open source is dat je soms pas merkt dat een project dood is wanneer je het nodig hebt. Er is geen universeel ‘heartbeat’-systeem dat laat weten: dit project is morgen nog veilig en beheerd. Een repository kan er op dezelfde manier uitzien op de dag vóór en de dag nádat een maintainer stopt.
Daarom krijgt open source volwassen security een extra component: proof of life. Niet als marketinglaag, maar als praktisch bewijs dat iemand verantwoordelijkheid neemt en dat er een beveiligingsproces bestaat. Dat betekent doorgaans meer dan alleen commits: het vraagt ook om heldere afspraken over disclosure, onderhoud en het afhandelen van meldingen wanneer de eerste echte exploitatie zich aandient.
Ook afscheid moet geregeld zijn
Proof of life klinkt streng, maar het heeft een menselijke tegenhanger nodig: een manier om waardig te stoppen. Maintainers raken uitgeput, mensen verhuizen naar andere rollen en soms is er simpelweg geen haalbaar “blijven” meer. Een volwassen systeem houdt dus rekening met pensionering zonder dat gebruikers plots in het donker vallen.
In die richting wordt nagedacht over een “retirement home”: een plek of regeling waar een project heen kan wanneer de maintainerketen stopt, zodat downstreamgebruikers niet abrupt zonder ondersteuning zitten.
Free as in puppy: de kosten verschuiven naar beheer en actualiteit
In gesprekken over open source valt “gratis” vaak als argument. Toch gaat open source volwassen security niet primair over licentiekosten. Het gaat over de dagelijkse plicht van eigenaarschap: je moet je afhankelijkheden bijhouden, je moet blijven upgraden en je moet accepteren dat een stilstaande versie een risico wordt zodra de omgeving verandert.
In deze visie is “free” eerder te begrijpen als een puppy: je kunt hem adopteren zonder meteen te betalen, maar je betaalt later door tijd en zorg. Voor enterprises betekent dat: niet alleen installeren, maar ook onderhouden. Vooral wanneer het patchritme alleen nog voor recente versies echt wordt waargemaakt, verschuift de verantwoordelijkheid naar de organisatie die het gebruikt.
Waar vendors helpen: ontzorging bij onvoorziene uitval
Als je een subset kiest die wél proof of life levert, blijft het risico op incidenten nooit nul. Daarom ontstaat er een nieuwe rol voor leveranciers. Niet als poortwachters die open source “afsluiten”, maar als aanbieders van tijd, stabilisatie en migratieruimte.
In praktische zin betekent dit vaak twee dingen. Ten eerste: support voor teams die niet op het allerlaatste versiepad kunnen zitten, bijvoorbeeld via long-term onderhoud, backports of een gedragen upgradepad. Ten tweede: buffer wanneer een project ineens uit de subset valt, zodat je niet met spoed alles moet vervangen op het moment dat de druk al maximaal is.
In plaats van een “contract” zoals je dat in klassieke proprietary software kent, draait het om een professioneel vangnet voor het moment waarop het misgaat of wanneer onderhoudsgedrag verandert.
Waarom het niet simpelweg een ‘betaal-maintainers’-verhaal is
Het idee dat bedrijven “gewoon maintainers moeten betalen” klinkt sympathiek en is op zichzelf logisch. Maar de kern die hier naar voren komt, is dat het geen puur financieringsprobleem is. Het is een distributievraag: je hebt duizenden dependencies en elke dependency heeft eigen onderhoudswensen en eigen voorwaarden voor samenwerking.
Geld geven is één ding, geld goed verdelen én het koppelen aan de juiste match tussen organisaties en projecten is lastiger. Het vraagt om schaalbare structuren die niet alleen geldstromen regelen, maar ook één aanspreekpunt creëren, zodat duidelijk is wie accountable is en hoe de viability van het project geborgd blijft.
Regelgeving loopt al vooruit: de ‘steward’ als rol
Op beleidsniveau beweegt Europa in de richting van heldere verantwoordelijkheden rond open source voor commercieel gebruik. Een voorbeeld dat in deze denkrichting terugkomt, is de aanpak rond de steward-rol in de EU Cyber Resilience Act. Daarin wordt beschreven hoe een juridische entiteit langdurige ondersteuning en levensvatbaarheid kan borgen.
Belangrijk is dat dit geen vervanging is van open source licenties, maar een extra laag van organisatorische zekerheid toevoegt. Daarmee wordt open source volwassen security niet alleen een technische discussie, maar ook een governance- en accountabilityvraag.
Wat dit betekent voor je security-strategie
Stel jezelf voortaan minder de vraag “staat deze dependency op GitHub?” en meer: “wat gebeurt er als er morgen een serieuze kwetsbaarheid wordt ontdekt?”. Denk daarbij aan vier concrete aandachtspunten:
- Actieve status en bereikbaarheid: kun je een disclosure-route vinden en krijg je binnen redelijke tijd reactie?
- Patchdiscipline: levert het project updates op het moment dat het ertoe doet, of alleen voor oude versies?
- Proof of life: is er een mechanisme of beleid dat aantoont dat het onderhoud actueel is?
- Exit-plan: bestaat er een manier om met pensionering of uitval om te gaan, zodat je niet in één nacht moet herontwerpen?
Wanneer je deze punten meeneemt, wordt je supply chain minder afhankelijk van toeval. Je bouwt een model waarbij betrouwbaarheid meetbaar wordt en waarbij het team minder hoeft te gokken op “waarschijnlijk gebeurt er iets” zodra de druk toeneemt.
Meer dan techniek: lessen uit eerdere incidenten
De reden dat deze visie aan kracht wint, is dat aanvallen steeds vaker op ketenniveau worden ingezet. Denk aan het misbruik van distributiekanalen, gecompromitteerde componenten of kwetsbaarheden die op schaal worden ontdekt en ingezet. Ook in eerdere berichten op onze site zagen we hoe aanvallers gebruikmaken van concrete zwaktes in processen of infrastructuur — bijvoorbeeld rondom vishing-dreigingen en gestuurde accountaanvallen, of wanneer fouten in publieke componenten het doelwit versnellen.
Als je breder wilt kijken naar hoe aanvallen ketens beïnvloeden, lees dan ook Vishing-dreiging UNC6671: meerdere merken, één aanpak voor inzicht in hoe sociaal-technische sturing vaak samenvalt met technische zwaktes. Voor het deel van de keten dat web- en infrastructuurstack raakt, is HTTP desync: AI vond Apache zero-day en nieuwe technieken relevant om te zien hoe snel nieuw werkbaar misbruik kan ontstaan zodra er een zwakte bekend is.
Conclusie: open source volwassen security als nieuw normaal
De boodschap achter open source volwassen security is helder: open source verdwijnt niet, maar de manier waarop enterprises erop kunnen leunen wel. Licenties blijven overeind, maar organisaties gaan steeds vaker eisen stellen aan bewijs van actieve onderhoudsverantwoordelijkheid, patchbaarheid en een volwassen exit-route wanneer projecten stoppen.
Voor teams betekent dit dat dependencybeheer minder een opsomming wordt en meer een levend proces. Voor leveranciers betekent het dat support verschuift van ‘doorverkopen’ naar ‘ontzorgen’ met buffers, backports en stabilisatie. En voor de community wordt het een roep om structurele, humane governance: niet alleen bouwen, maar ook klaarstaan, ook als je moet stoppen.
Open source heeft een harde groeifase doorgemaakt. Nu is het volwassen: gehard, verantwoord en niet langer afhankelijk van het optimisme van vroeger.
Bron: https://thehackernews.com/2026/08/growing-up-hard-way.html
