Open- of closed source:wat is veiliger?

Wanneer organisaties keuzes maken over hun it-infrastructuur, speelt beveiliging een hoofdrol. Cyberaanvallen, datalekken en de toenemende druk vanuit wet- en regelgeving zorgen ervoor dat bedrijven kritischer kijken naar de software die ze gebruiken. Eén van de grootste discussies hierbij is of opensourcesoftware veiliger is dan closed software. Beide modellen hebben voor- en nadelen, maar wat betekent dat precies voor een organisatie?

Opensourcesoftware betekent dat de broncode van de software openbaar is. Iedereen mag de code bekijken, aanpassen en verspreiden. Bij closed source-software is dit niet het geval. Alleen de softwareleverancier zelf heeft toegang tot de code. Hoewel beide soorten software dagelijks intensief gebruikt worden, bestaat er een groot verschil in hoe ze ontwikkeld, verspreid en onderhouden worden. Dat verschil heeft directe gevolgen voor de beveiliging ervan.

Transparantie versus controle

Een belangrijk kenmerk van opensourcesoftware is het feit dat transparantie wordt geboden. Omdat iedereen toegang heeft tot de code, kan een gemeenschap van ontwikkelaars en beveiligingsexperts deze continu controleren op fouten en beveiligingsrisico’s. Voorstanders van opensource-software noemen dit principe vaak de kracht van ‘many eyes’. Hoe meer mensen naar de code kijken, hoe sneller fouten ontdekt worden.

Bij closed source-software ligt de verantwoordelijkheid voor het verhelpen van kwetsbaarheden uitsluitend bij de leverancier. Hoewel leveranciers vaak professionele beveiligingsteams in dienst hebben, is er minder transparantie. Gebruikers vertrouwen volledig op de leverancier om problemen op tijd te ontdekken en op te lossen. De gesloten aanpak kan daardoor zowel een voordeel als een nadeel zijn: aan de ene kant betekent het gecontroleerde en georganiseerde updates, aan de andere kant kan het betekenen dat problemen langer verborgen blijven.

Het tempo van beveiligingsupdates

Een ander verschil tussen open en closed source-software zit in hoe snel beveiligingsproblemen worden opgelost. Opensourcesoftware profiteert van de snelheid waarmee de gemeenschap werkt. Zodra een kwetsbaarheid wordt ontdekt, kan vrijwel direct een grote(re) groep ontwikkelaars aan een oplossing werken. In de praktijk heeft dit geleid tot situaties waarin kritieke problemen binnen enkele uren of dagen opgelost werden.

Closed source-software is afhankelijk van de interne processen bij de leverancier, maar bijvoorbeeld ook diens roadmap. Hoewel updates meestal gestructureerd en grondig worden getest, kan de levering ervan langer duren. Kwetsbaarheden blijven soms weken of zelfs maanden bestaan, totdat er een officiële update beschikbaar komt.

Het gebruik van opensourcesoftware vereist actieve monitoring door de organisatie zelf

Hoewel opensource-communities veelal snel reageren, kleven er ook risico’s aan deze benadering. Niet elk opensource-project heeft een actieve gemeenschap. Sommige software raakt verouderd of wordt onvoldoende onderhouden. Dit kan ertoe leiden dat bekende beveiligingslekken blijven bestaan zonder dat gebruikers dat direct doorhebben. Het gebruik van opensourcesoftware vereist dus actieve monitoring door de organisatie zelf.

Closed source-software kent nog een ander risico: afhankelijkheid van één leverancier. Als die failliet gaat of besluit om bepaalde software niet langer te ondersteunen, staat de organisatie met lege handen. Dit betekent dat gebruikers van closed source-software kwetsbaar zijn voor strategische keuzes van hun leveranciers. Een risico dat bij opensourcesoftware veel kleiner is, omdat de software niet aan één leverancier gebonden is.

Concrete beveiligingsvoorbeelden

Een goed voorbeeld van een probleem met opensourcesoftware was de Heartbleed-bug uit 2014. Deze ernstige kwetsbaarheid in OpenSSL, een veelgebruikte softwarebibliotheek, toonde aan dat ook populaire en goed onderhouden opensource-projecten kwetsbaar kunnen zijn. Tegelijkertijd liet de snelle reactie vanuit de community zien hoe effectief het model kan zijn: binnen enkele dagen was er een oplossing beschikbaar.

Closed source-software heeft vergelijkbare voorbeelden. Het Wannacry-ransomware-incident uit 2017 werd mogelijk gemaakt door een kwetsbaarheid in oudere versies van Microsoft Windows. Hoewel Microsoft al een patch had uitgebracht, waren veel organisaties niet snel genoeg met installeren, mede door de complexiteit en afhankelijkheid van de leverancier. En de problemen die Crowdstrike veroorzaakte, laten zien dat het ook met updates van closed software-producten soms meer dan oppassen is. In juli van 2024 werd de wereld opgeschrikt door een storing veroorzaakt door een defecte update in de beveiligingssoftware van CrowdStrike. De update liet wereldwijd miljoenen op Microsoft Windows draaiende computers crashen.

Flexibiliteit en maatwerk in beveiliging

Een ander punt van aandacht is flexibiliteit. Opensourcesoftware biedt organisaties meer ruimte om zelf aanpassingen te doen en de beveiliging specifiek af te stemmen op hun behoeften. Dit is vooral interessant voor bedrijven met zeer specifieke compliance- of beveiligingseisen. En niet te vergeten: zelf beschikken over voldoende technische kennis en vaardigheden.

Closed source-software biedt juist een gestandaardiseerde aanpak. Leveranciers volgen duidelijke richtlijnen en protocollen, wat voor sommige organisaties aantrekkelijker kan zijn vanwege voorspelbaarheid en uniforme processen. Dit kan met name gunstig zijn bij organisaties met beperkte interne IT-expertise.

Kosten en ondersteuning

Hoewel opensourcesoftware doorgaans gratis is, zijn er vaak indirecte kosten. Organisaties moeten bijvoorbeeld investeren in gespecialiseerde kennis of externe partijen inschakelen om ondersteuning te bieden en software te onderhouden. Dit kan, zeker bij complexe beveiligingsvraagstukken, tot aanzienlijke kosten leiden. Sowieso geldt vaak dat opensource-oplossingen door enterprise-organisaties uitsluitend gebruikt worden inclusief een betaald supportcontract. Gratis is hier dus relatief.

Bij closed source-software betalen organisaties doorgaans licentiekosten, waar ondersteuning en beveiligingsupdates veelal bij inbegrepen zijn. Hoewel dit meestal duurder is, biedt het wel zekerheid over ondersteuning en regelmatige beveiligingsupdates.

Organisaties die kiezen voor opensourcesoftware moeten zorgvuldig de gezondheid van het project en de betrokkenheid van de community beoordelen. Tools zoals GitHub en OpenHub kunnen hierbij helpen. Hoe actiever de gemeenschap, hoe groter de kans dat beveiligingsproblemen snel en adequaat aangepakt worden.

Bij closed source-software is evaluatie van de leverancier essentieel. Hierbij spelen ook factoren als reputatie en continuïteit een rol. Door due diligence uit te voeren, kunnen organisaties zich beter beschermen tegen risico’s.

Welke aanpak past het beste?

Er is geen absolute winnaar als het gaat om de vraag of opensource veiliger is dan closed source. Beide modellen hebben duidelijke sterke punten en specifieke risico’s. De keuze hangt sterk af van de eigen organisatie: interne expertise, beschikbare middelen en specifieke beveiligingseisen bepalen uiteindelijk welke aanpak het beste past.

Opensource biedt snelheid, transparantie en onafhankelijkheid, maar vraagt actief beheer en voortdurende monitoring. Closed source geeft stabiliteit, gecontroleerde updates en professionele ondersteuning, maar brengt ook risico’s met zich mee rondom afhankelijkheid en gebrek aan inzicht in de code.

Let bij opensource op de licentie

Hoewel opensource-software vaak geassocieerd wordt met vrij en onbeperkt gebruik, zijn er verschillende licentievormen die specifieke voorwaarden stellen. Bekende licenties zoals de GNU General Public License (GPL) of de Apache License zijn helder, maar soms voegen ontwikkelaars extra voorwaarden toe aan bestaande licenties. Hierdoor ontstaan varianten die gebruikers kunnen verrassen en mogelijk juridische risico’s opleveren.

Een voorbeeld is de toevoeging van de zogenaamde ‘Commons Clause’. Deze bepaling verbiedt commercieel gebruik van de software zonder expliciete toestemming, terwijl de oorspronkelijke licentie dit juist toestaat. Een ander voorbeeld is de Server Side Public License (SSPL), een variant van de AGPL (Affero General Public License, een variant op de GNU General Public License). SSPL verplicht bedrijven om ook software openbaar te maken waarmee de opensource-toepassing gecombineerd wordt, ook als die alleen intern of via de cloud wordt gebruikt.

Dit artikel staat ook in het Computable Magazine 2025 #2.