Huidige schattingen zeggen dat 70 โ 90% van software maakt gebruik van open source. Maar hoe veilig is open source? Open source-pakketten worden wereldwijd gedeeld door ontwikkelaars, dus het gebruik van open source in uw eigen toepassingen betekent dat u code van derden in uw projecten introduceert. Dit kan beveiligingsrisico's met zich meebrengen, en hoe breder een open source-pakket wordt gebruikt, hoe groter de impact die een beveiligingslek erin kan hebben.
A nieuw onderzoeksproject van Snyk en de Linux foundation gericht op hoe organisaties hun open source-pakketten beveiligen. In het project werd gekeken hoe ontwikkelaars risico's detecteren en aanpakken. Een grondige analyse van de verzamelde gegevens bracht enkele grote misstappen aan het licht die organisaties maken als het gaat om open source-beveiliging. Hier zijn drie stappen die organisaties kunnen nemen om die misstappen te verhelpen en op weg te gaan naar sterkere beveiligingspraktijken rond open source.
1. Begrijp dat afhankelijkheden complexiteit met zich meebrengen
Het gemiddelde project heeft 49 kwetsbaarheden verspreid over 79 directe afhankelijkheden.
Open source-beveiliging wordt een grotere uitdaging als de software toeleveringsketen wordt complexer. Bijna alle moderne applicaties zijn gebouwd met componenten die afhankelijk zijn van andere componenten, waardoor een toeleveringsketen ontstaat met honderden componenten en meerlagige afhankelijkheden.
De software de toeleveringsketen is een aantrekkelijk toegangspunt voor kwaadwillende actoren omdat ze misbruik kunnen maken van kwetsbaarheden in kleine bibliotheken die veel worden gebruikt. Herinner je je Log4Shell nog? Het maakte alle inkomende gegevens die worden geregistreerd kwetsbaar voor RCE-aanvallen (remote code execution). Het was een kritieke zwakte binnen een populair open source logging-framework - een kwetsbaarheid binnen een afhankelijkheid.
Slechts 24% van de organisaties heeft vertrouwen in de beveiliging van hun directe afhankelijkheden. En hoewel 37% van de organisaties meldt dat afhankelijkheden gemakkelijk te traceren zijn, bevinden deze afhankelijkheden zich niet noodzakelijkerwijs in een veilige staat.
2. Leg de basis met beveiligingsbeleid
Slechts 49% van de organisaties heeft een beveiligingsbeleid dat expliciet ingaat op de ontwikkeling en het gebruik van open source-pakketten.
Dit is begrijpelijk in kleinere organisaties, waar de middelen beperkt zijn. Uit onderzoek bleek ook dat 27% van de middelgrote tot grote bedrijven geen vaststaand beveiligingsbeleid heeft. Als je bedenkt hoeveel gegevens elk van deze bedrijven mogelijk verwerkt, is 27% een alarmerende statistiek.
Elke organisatie heeft een CISO (chief information security officer) of een persoon nodig team belast met de belangrijkste beveiligingsverantwoordelijkheden. Wanneer de belangrijkste CISO-mogelijkheden aanwezig en beschikbaar zijn, volgt een open source-beveiligingsbeleid. Er moet een uitvoerbaar beleid worden ingevoerd en overal worden gesocialiseerd teams โ beginnend met CISO's en ontwikkelaars, en gaandeweg door de hele organisatie.
3. Gebruik de juiste tools
73% van de organisaties zoekt naar best practices om hun software veiligheid.
Organisaties moeten investeren in een diverse set tools om hen te helpen veiligere applicaties te bouwen. Vaak, SCA (software compositie analyse) tools kunnen een sterk voordeel bieden door het mogelijk te maken teams om kwetsbaarheden in open source-pakketten te vinden en te leren hoe u deze kunt oplossen. Sommige organisaties gebruiken andere tools, afhankelijk van hun voorkeuren met betrekking tot beveiligingstesten.
SAST-tools (static application security testing), die bij 35% van de organisaties worden gebruikt, scannen broncode, bytecode en binaire code om problematische coderingspatronen te identificeren. Sommige organisaties gebruiken een IaC-model (infrastructure as code) om ontwikkelaars te helpen bij het schrijven van veilige HashiCorp Terraform-, AWS CloudFormation-, Kubernetes- en Azure Resource Manager (ARM)-configuraties voordat ze met de productie beginnen. IaC-configuraties passen best practices op het gebied van beveiliging rechtstreeks in ontwikkelingsworkflows.
Elk van deze toolingopties kan organisaties helpen een grote stap te zetten in de richting van prioriteit geven aan open source-beveiliging.
De gecombineerde kracht van onderwijs, beleid en tools
Het veilig gebruiken van open source-pakketten vereist een nieuwe manier van denken over beveiliging voor ontwikkelaars die veel organisaties nog niet hebben overgenomen. Als u weet welke risico's bestaan โโin open source-pakketten en begrijpt hoe u bescherming tegen die risico's kunt bouwen, kan uw organisatie open source-technologie efficiรซnt en veilig gebruiken. Het vinden van de meest effectieve tools en beleidsregels voor open source-beveiliging is een goed begin.