Computable.be
  • Thema’s
    • Security & Awareness
    • Cloud & Infrastructuur
    • Data & AI
    • Software Innovation
  • Computable Awards
    • Nieuws Computable Awards
    • Hall of Fame
  • Cybersec e-Magazine
  • Kennisbank
  • Inlog
  • Nieuwsbrief
[Illustratie: Erwin Suvaal]

Open- of closed source:wat is veiliger?

30 mei 2025 - 15:066 minuten leestijdAchtergrondSoftware Innovation
Robbert Hoeffnagel
Robbert Hoeffnagel

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.

Meer over

Opensource

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Meer lezen

    Java
    OpinieSoftware Innovation

    Java 30 jaar: legacy of alive?

    ActueelCarrière

    Valerie Taerwe is IT Person of the Year 2025

    ActueelSoftware Innovation

    Kort: Esri simuleert extreem weer, omkoping Coinbase, 6 cloudtrends Gartner (en nog meer)

    Groei
    ActueelSoftware Innovation

    SAP verrast met forse stijging omzet en winst

    AchtergrondCloud & Infrastructuur

    SAP ziet blijvende trend naar digitale soevereiniteit

    ActueelInnovatie & Transformatie

    Gartner: dynamische software verandert het zakendoen

    Geef een reactie Reactie annuleren

    Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

    Populaire berichten

    Meer artikelen

    Footer

    Direct naar

    • Kennisbank
    • Computable Awards
    • Colofon
    • Cybersec e-Magazine

    Producten

    • Adverteren en meer…
    • Persberichten

    Contact

    • Contact
    • Nieuwsbrief

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.be is een product van Jaarbeurs