7 risico's van open source software en hoe je jezelf kunt verdedigen

Wat is open source software?

Veel bedrijven en producten, volgens sommige schattingen 90%, gebruiken minstens één open-source component, zelfs als ze zich er niet van bewust zijn. Open-source software is software waarvan de code beschikbaar is voor publieke inspectie, wijziging en verbetering. Meestal wordt deze software gemaakt door samenwerking in een gemeenschap en wordt het onderhouden en bijgewerkt op vrijwillige basis.

Open source software kan worden gebruikt volgens verschillende licenties, afhankelijk van wat de makers hebben geïmplementeerd. Linux OS, Apache Web Server, WordPress en Mozilla Firefox zijn slechts enkele van de meest gebruikte software.

Risico's van het gebruik van open source software

Door de opbouw van de gemeenschap en de grotendeels ongereguleerde distributie, brengt het gebruik van open source software een verscheidenheid aan risico's met zich mee, waaronder een aantal risico's op het gebied van cyberbeveiliging.

1. Kwetsbaarheden zijn algemeen bekend

Beveiligingslekken in open-source software worden openbaar gemaakt door de bijdragers zelf, maar ook door organisaties zoals het Open Web Application Security Project (OWASP) en de National Vulnerability Database (NVD).

Als je deel uitmaakt van de community voor een specifiek project, word je vaak vooraf gewaarschuwd voordat het openbaar wordt gemaakt aan groepen als OWASP en NVD, maar dat geldt ook voor anderen die deel uitmaken van de community. Dit betekent dat als je laks bent in het onderhouden van de laatste versies of het updaten van componenten, je jezelf blootstelt aan risico's, omdat kwetsbaarheden vaak worden geïdentificeerd en uitgebuit door cybercriminelen.

2. Gebrek aan beveiliging

Open-source software wordt geleverd zonder claims of wettelijke verplichtingen voor beveiliging en community-ondersteuning die u informeert hoe u het veilig kunt implementeren kan ontbreken. De ontwikkelaars die verantwoordelijk zijn voor het maken van software zijn vaak geen beveiligingsexperts en begrijpen mogelijk niet hoe ze best practices moeten implementeren.

Hoewel bronnen zoals de OWASP Top 10 -lijst met kwetsbaarheden openbaar beschikbaar zijn en gericht zijn op open-sourcegemeenschappen, bieden ze niet altijd instructies over hoe beveiligingsfuncties moeten worden geïmplementeerd om bescherming te bieden tegen deze kwetsbaarheden.

Vaak bevat open-source software of vereist het gebruik van bibliotheken van derden, die zonder inspectie uit pakketbeheerders worden gehaald. De black-box aard van deze bibliotheken maakt het moeilijker en tijdrovender om kwetsbaarheden te identificeren en te patchen.

3. Intellectueel eigendom

Er zijn meer dan 200 soorten licenties die op open-source software kunnen worden toegepast, waaronder Apache, GPL en MIT. Veel van deze licenties zijn onderling onverenigbaar, wat betekent dat bepaalde componenten niet samen kunnen worden gebruikt, aangezien je bij het gebruik van open-source software aan alle voorwaarden moet voldoen. Hoe meer componenten je gebruikt, hoe moeilijker het wordt om alle licentiebepalingen bij te houden en te vergelijken.

Sommige licenties bevatten "copyleft"-clausules die vereisen dat je alle software die je maakt met de gedekte componenten vrijgeeft als open-source, in zijn geheel. Dit maakt het onmogelijk om het te gebruiken in propriëtaire software en minder aantrekkelijk voor gebruik voor commerciële doeleinden.

4. Gebrek aan garantie

Open-source software biedt geen garanties op het gebied van veiligheid, ondersteuning of inhoud. Hoewel veel projecten worden ondersteund, gebeurt dit door vrijwilligers en kan de ontwikkeling ervan zonder kennisgeving worden stopgezet.

Communityleden evalueren de software meestal op beveiligingsproblemen en bieden ondersteuning via open forums, maar ze zijn hiertoe niet verplicht en zijn ook niet aansprakelijk voor foutieve begeleiding.

Omdat open source-software wordt gemaakt door gemeenschappen van soms anonieme bijdragers, is het moeilijk om te controleren of de code die wordt bijgedragen origineel is en niet is overgenomen van een bron van derden met gevestigde intellectuele eigendomsrechten. Wat dit in de praktijk betekent, is dat als u open source-software gebruikt die code blijkt te bevatten met geschonden rechten, u verantwoordelijk kunt worden gehouden voor de schending.

5. Versoepeld toezicht op integraties

Teams hebben vaak onvoldoende of geen reviewprocessen als het gaat om welke open-source componenten worden gebruikt. Meerdere versies van hetzelfde component kunnen worden gebruikt door verschillende teams of ontwikkelaars zijn zich niet bewust van conflicterende functionaliteit of licenties.

Deze problemen kunnen ontstaan door gebrek aan kennis van software of beveiligingsfunctionaliteit, gebrek aan communicatie tussen teams of teamleden, of onvoldoende of afwezige tracking- en documentatieprotocollen.

In tegenstelling tot propriëtaire software van derden, die ingebouwde controles heeft om het gebruik van meerdere of incompatibele versies te voorkomen, vertrouwen open-source componenten meestal op de gebruiker om het juiste gebruik te verifiëren.

6. Operationele tekortkomingen

Het gebruik van open-source componenten kan veel extra werk opleveren voor teams die toch al onder tijdsdruk staan en het is vaak niet duidelijk wie verantwoordelijk is voor dit werk. Je moet bijhouden welke componenten worden gebruikt, welke versie ze zijn, waar ze worden gebruikt en hoe ze kunnen interageren met andere componenten die in gebruik zijn.

Daarnaast is het nodig om licenties te vergelijken en updates en patches te volgen wanneer deze beschikbaar worden gesteld, inclusief de impact die ze kunnen hebben op de functionaliteit. Als gebruikte componenten onnodige functionaliteit bevatten, kunnen ze complexiteit aan uw systeem toevoegen zonder voordeel.

7. Slechte ontwikkelaarspraktijken

Ontwikkelaars kunnen onbedoeld risico’s vergroten als ze stukken code uit open-source-software kopiëren en plakken in plaats van complete componenten te integreren. Hierdoor wordt het onmogelijk om die code te traceren vanuit het oogpunt van licenties of beveiliging.

Wanneer ontwikkelaars samenwerken met andere teamleden, kunnen ze componenten overdragen via e-mail in plaats van via een binaire repository manager of een gedeelde netwerklocatie. Deze methode kan code kwetsbaar maken voor manipulatie tijdens de overdracht, waardoor beveiligingslekken of kwaadaardige functionaliteit kan worden toegevoegd.

Hoe uzelf en uw organisatie te beschermen

Gebruik de juiste tools

Door DevSec-teams in te zetten, kunt u beveiliging in een vroeger stadium in uw SDLC integreren en open-source-software vanaf het begin op een veilige manier integreren. Beveiligingsmedewerkers kunnen de componenten die ontwikkelaars willen gebruiken gemakkelijker beoordelen en advies geven over het beperken van risico’s of het ontwikkelen van patches.

Automatiseringstools kunnen een enorme waarde bieden voor het volgen van open-source componenten en hun status, maar ook voor het evalueren van componenten. Open source code kan voor en tijdens gebruik gescand worden met behulp van Dynamic Application Security Testing (DAST) of Static Application Security Testing (SAST) tools.

Uitgebreide beleidsregels maken

Het beleid moet rekening houden met de geschiedenis van een open-source component, zoals de dichtheid van bekende problemen, de frequentie waarmee versies worden uitgebracht en de tijd die verstrijkt tussen de identificatie van het probleem en de patch. Het is belangrijk om te weten hoe robuust de gemeenschap is die betrokken is bij een project en te anticiperen op wat voor soort ondersteuning deze wel of niet zou kunnen bieden.

Beleid moet dicteren welke bronnen en licentietypen acceptabel zijn voor gebruik en moet ontwikkelaars helpen beslissen of ze individuele componenten of een hele codebase willen gebruiken.

Conclusie

Veel bedrijven profiteren van het gebruik van open-source software en er is geen reden waarom u niet ook zou profiteren. Echter, het kennen van de risico's van open-source software - voorafgaand aan het ontwikkelingsproces - zal u helpen valkuilen te vermijden die geassocieerd worden met het delen van crowd-sourced code. Door rekening te houden met de risico's die in deze blog worden beschreven en beschermingsstrategieën te implementeren, naast andere die nodig zijn om uw systemen te beveiligen, kunt u bijdragen aan een veilig gebruik van open source software.