7 risico’s van open sourcesoftware en 7 ‘solutions’

Open sourcesoftware zit in veel toepassingen. Open source betekent dat de broncode van software openbaar is d.w.z. de voor programmeurs leesbare commando’s en niet alleen de ‘nullen en de enen’ wat de hardware ‘leest’. Dit maakt het doorgaans veiliger en privacy vriendelijker. Iedereen kan controleren of het programma veilig is en bijv. geen persoonlijke data verzamelt. Openbaarheid staat centraal in tegenstelling tot de meeste andere software, zodat gebruikers geen wijzigingen op ‘eigen houtje’ kunnen doorvoeren. De broncode is dus vrij in te zien, aan te passen en te hergebruiken. Dit gebeurt vaak door een wereldwijde ‘community’ met als voordeel dat het veel innovatie kan opleveren. Maar het brengt ook technische, juridische en organisatorische risico’s met zich mee, waarover meer hierna. 

Risico’s

1. Licenties en intellectueel eigendom

Er zijn honderden open sourcelicenties zoals GPL, MIT, Apache. Zij zijn niet altijd compatibel. “Copyleft”‑licenties kunnen zelfs eisen dat jouw software óók open source wordt. Onduidelijkheid is er soms over de herkomst van bijdragen. Dat kan leiden tot IE‑claims (inbreuk o.g.v. auteursrecht) of de verplichting je eigen broncode te openen en dus openbaar te maken.

2. Geen garantie en beperkte aansprakelijkheid

Veel licenties sluiten garanties en aansprakelijkheid helemaal uit. Er is dus geen recht op ‘support’, projecten kunnen stoppen en community-hulp is niet afdwingbaar. Als de broncode rechten van derden schendt, kun jij als gebruiker aansprakelijk zijn, terwijl de bijdragers anoniem en onbereikbaar kunnen zijn.

3. Kwetsbaarheden – openbaar

Kwetsbaarheden worden snel openbaar gemaakt via communities. Aanvallers hebben dus dezelfde informatie als jij. Als je updates en patches niet direct doorvoert, worden bekende lekken een makkelijk doelwit.

4. Beveiliging – niet gegarandeerd

Beveiliging is zelden het primaire ontwerpdoel en er zijn geen contractuele garanties. Ontwikkelaars zijn vaak geen securityspecialist en vertrouwen op third party libraries die beperkt zijn doorgelicht. Deze “black box”-afhankelijkheden maken kwetsbaarheden lastiger te herkennen en te verhelpen. De niet-ethische hackers zijn dus een risico (maar ook bij software zonder openbare broncodes).

5. Zwak toezicht op gebruik en integraties

Zonder strak proces gebruiken teams makkelijk verschillende versies van dezelfde library, met conflicterende licenties of functies. Documentatie over welke componenten waar draaien ontbreekt vaak. In tegenstelling tot commerciële software moet je zelf zorgen voor correct gebruik en versiebeheer.

6. Operationele belasting en complexiteit

Elke extra component vraagt om beheer: bijhouden wat je gebruikt, in welke versie, met welke licentie en welke updates nodig zijn. Zonder duidelijke verantwoordelijkheden en tooling wordt dit al snel een zware last voor drukbezette teams en ontstaat onnodige complexiteit.

7. Onzorgvuldige ontwikkelpraktijken

Risico’s nemen toe als ontwikkelaars losse codefragmenten copy‑pasten, componenten via e‑mail of losse zipbestanden delen en geen centrale repositories gebruiken. Daardoor is herkomst, licentie en beveiligingsstatus moeilijk te traceren en is manipulatie tijdens overdracht lastiger te detecteren.

Hoe bescherm je jezelf en je organisatie?

1. Integreer security in de ontwikkelcyclus (DevSecOps).

– Betrek security vroeg in het proces.

– Laat securityspecialisten meebeslissen over welke componenten worden gebruikt en onder welke voorwaarden.

2. Gebruik gespecialiseerde tooling.

– Automatiseer inventarisatie van componenten en licenties (Software Composition Analysis).

–  Scan code en applicaties met SAST-tools (een applicatie die op bekende patronen doorzoeken die kunnen duiden op fouten of kwetsbaarheden) en DAST‑tools (Dynamic Application Security Testing) om kwetsbaarheden tijdig te vinden.

3. Stel helder beleid op.

– Bepaal welke bronnen en licentietypen zijn toegestaan.

– Hanteer criteria als patchsnelheid, releasefrequentie, aantal bekende kwetsbaarheden en de vitaliteit van de community.

– Leg vast wanneer losse componenten zijn toegestaan en wanneer een volledige codebase wordt overgenomen.

Conclusie

Met een combinatie van beleid, tooling en duidelijke verantwoordelijkheden kun je de voordelen van open source benutten zonder onnodig risico te lopen. Check dus de juridische kant bij open source; het is ook een strategische keuze. De overheid geeft goede informatie. Wij geven graag advies bij uw juridische afweging.

Heeft u vragen naar aanleiding dit artikel of heeft u andere juridische vragen? Onze gespecialiseerde advocaten staan u graag te woord. U kunt ons bereiken via mail, telefoon of via het contactformulier.