Is open source veilig?

Tim Mackey, de belangrijkste veiligheidsstrateeg bij de Synopsys Cybersecurity Research Center, beantwoordt een vraag die veel IT-specialisten bezighoudt: is open source veilig?

Nu nieuwe kwetsbaarheden worden onthuld tegen open source-componenten en nieuwe aanvallen worden gelanceerd tegen repositories van open source-componenten, en zelfs tegen open source-ontwikkelingsmethodologieën, is het belangrijk om de vraag te stellen: hoe veilig zijn open source-componenten?

Om deze vraag te beantwoorden, moeten we eerst enkele parameters definiëren. Dit is cruciaal omdat open source-technologieën de moderne softwareontwikkeling aandrijven. In feite zijn er maar heel weinig softwaretoepassingen en -services die niet op zijn minst enkele open source-elementen bevatten.

Open source-componenten variëren van de fundamentele, zoals services die de klokken van servers, mobiele telefoons en computers synchroon houden of encryptiebibliotheken die worden gebruikt om internetverkeer te beveiligen, via verschillende softwareontwikkelingskits die snelle innovatie in IoT mogelijk maken, eindigend met eenvoudige hulpprogramma's die zijn ontworpen om automatisering van veelvoorkomende taken zoals software-implementatie eenvoudiger. Al deze miljoenen open source-projecten hebben één ding gemeen: de broncode is vrij te downloaden en iedereen kan een afgeleide van het hoofdproject maken zonder toestemming van de projecteigenaren.

Het is deze vrijheid die innovatie aandrijft en risico vertegenwoordigt. Immers, als iemand een afgeleide van een project kan maken, moet dat betekenen dat aanvallers elk project op elk moment kunnen vervalsen. Het eindpunt van dat argument is dat open source op de een of andere manier 'onveilig', gebrekkig of onveilig moet zijn.

Het contrapunt is dat commerciële software op de een of andere manier veiliger is vanwege strengere controles of meer middelen. Wat degenen die dit argument aanvoeren zich niet realiseren is dat commerciële software gemiddeld 70% open source is, maar belangrijker nog, alle software heeft bugs en geen enkel softwareontwikkelingsproces is perfect.

In het verlengde van dit punt, van de 1,500+ codebases die zijn gescand in de 2021 Open source beveiliging en risicoanalyse (OSSRA) rapport bevatte 98% open source. Bovendien bevatte 84% van de gescande codebases ten minste één kwetsbaarheid - een stijging van 9% ten opzichte van de bevindingen van de voorgaande jaren.

Omdat alle software bugs bevat, kunnen bugs worden misbruikt en zelfs de meest veilige software kan op een onveilige manier worden ingezet. Dus waarom komt de veiligheid en beveiliging van open source steeds ter sprake? Welnu, als open source-componenten goed genoeg zijn voor commerciële softwareleveranciers om te gebruiken, moet dat dan iets betekenen? En als open source-technologieën goed genoeg zijn voor de grootste wolk aanbieders, dat moet toch ook wat betekenen? Wat weten zij dat degenen die veiligheids- en beveiligingsvragen stellen niet?

Het blijkt dat het kernprobleem er een is van bekendheid en, nou ja, schuld. Er is geen leverancier die bekend staat als 'open source'. Dit betekent gedeeltelijk dat wanneer iemand een open source-oplossing wil aanschaffen, er geen contract hoeft te worden ondertekend en bij uitbreiding niets voor de inkoopteams van het bedrijf. Aangezien inkoopteams van bedrijven vaak de poortwachters zijn voor compliance binnen het bedrijf, betekent dit dat iedereen compliance kan omzeilen, en dat is een slechte zaak. Stelt u zich de chaos eens voor als iedereen de benodigde software vrij zou kunnen downloaden zonder tussenkomst van IT of inkoop.

Hoewel die laatste zin ironisch klinkt, is de realiteit dat software die een organisatie binnenkomt zonder tussenkomst van IT, waarschijnlijk niet wordt gepatcht. En patchbeheer in open source is heel anders dan bij commerciële software. Omdat er geen enkel oorsprongspunt is voor een open source-component, is het belangrijk om bij te houden waar elke component of applicatie vandaan is gedownload. Dat is waar eventuele patches of updates vandaan moeten komen.

Omdat we allemaal weten hoe belangrijk patchen is voor de beveiliging, is dat een risico als er niet-gepatchte open source-componenten in uw bedrijf zijn, vooral gezien de realiteit dat open source-software gratis kan worden gedownload zonder tussenkomst van IT.

Als je eenmaal weet waar de open source component vandaan komt, kun je er niet alleen een patchstrategie voor maken (hint: updates werken anders dan bij commerciële software), maar kun je ook de veiligheid van de component beoordelen. Onder componentveiligheid wordt in dit verband verstaan ​​hoe het onderdeel daadwerkelijk wordt ontwikkeld.

Veelvoorkomende vragen die u op dit moment kunt stellen, zijn onder meer:

• Ben ik op een echte oorsprong of op een vork? Echte oorsprong vertegenwoordigt de belangrijkste ontwikkelingsinspanning voor het onderdeel, en een vork is elke tak van het onderdeel. Tenzij je een hele goede reden hebt om een ​​vork te gebruiken, moet je altijd de ware oorsprong van het onderdeel gebruiken, ook wel 'stroomopwaarts' genoemd.

• Heeft het onderdeel een goed gedefinieerd beveiligingsbeleid? Alleen de meest populaire open source-projecten hebben een dergelijk beleid en het beleid beschrijft hoe beveiligingsincidenten worden beheerd.

• Is er een welomschreven bijdragemodel? Open source-projecten gedijen goed als er actieve bijdragers zijn, maar als er geen model voor vaste bijdragen is, is er waarschijnlijk geen set criteria voor hoe een bijdrage van hoge kwaliteit eruitziet. Sommige richtlijnen voor bijdragen stellen expliciet testvereisten voor elke bijdrage.

• Wie zijn de topbijdragers? Alle software heeft bijdragers, maar niet elke bijdrager begrijpt de volledige broncode. Als de topbijdragers nieuw zijn in het project, kan dat duiden op een verschuiving in de ontwikkelingsprioriteiten of dat de medewerkers al lang niet meer bij het project zijn geweest.

Hoewel er geen echt verschil is in de veiligheid van open source versus commerciële software, is de realiteit dat er binnen verschillende industrieën meerdere veiligheidsnormen zijn en dat alle software, ongeacht de oorsprong, moet worden getoetst aan de toepasselijke normen.

LEES VERDER:

• 'S Werelds eerste open-source framework voor botbeheer vandaag onthuld
• EA wordt slachtoffer van diefstal van broncode
• Het low-code raadsel en de impact ervan op de bedrijfsvoering
• Hoe low-code platforms effectiever te maken voor de onderneming

Voor gebruik waar geen veiligheidsnormen bestaan, is de kwestie van veiligheid echt een kwestie van beheer. Kunnen uw teams garanderen dat ze open source-componenten kunnen patchen en controleren de wijzigingen in eventuele updates? Als u geen goed open source-beheerproces heeft, zou de veiligheid van afzonderlijke componenten geen topprioriteit moeten zijn.

Voor meer nieuws van Top Business Tech, vergeet je niet te abonneren op ons dagelijkse bulletin!

Volg ons op LinkedIn en Twitter