Het beveiligen van open source in 2025 en daarna: een routekaart voor vooruitgang

Het is alweer meer dan drie jaar geleden dat Log4Shell, een kritieke kwetsbaarheid in een weinig bekende open-sourcebibliotheek, werd ontdekt. ​​Met een CVSS-score van 10, de relatieve alomtegenwoordigheid en het gemak van exploitatie, werd het aangemerkt als een van de ernstigste softwarefouten van het decennium. Maar zelfs jaren nadat het werd gepatcht, is meer dan één op de tien downloads van het populaire hulpprogramma van kwetsbare versies. Er is duidelijk ergens iets mis.

Een nieuw rapport van de Linux Foundation heeft nuttig inzicht in de systemische uitdagingen waarmee het open-source ecosysteem en zijn gebruikers worden geconfronteerd. Helaas zijn er geen gemakkelijke oplossingen, maar eindgebruikers kunnen ten minste enkele van de meest voorkomende risico's beperken door middel van best practices in de sector.

Een catastrofale casestudy

Open-source softwarecomponenten zijn overal te vinden, zelfs ontwikkelaars van propriëtaire code vertrouwen erop om DevOps-processen te versnellen. Volgens een schatting, 96% van alle codebases bevat open-sourcecomponenten en driekwart bevat open-sourcekwetsbaarheden met een hoog risico. Gezien het feit dat de naderende zeven biljoen componenten in 2024 zijn gedownload, vormt dit een enorm potentieel risico voor systemen over de hele wereld.

Log4j is een uitstekende case study van wat er mis kan gaan. Het benadrukt een grote zichtbaarheidsuitdaging, namelijk dat software niet alleen "directe afhankelijkheden" bevat - dat wil zeggen open source-componenten waarnaar een programma expliciet verwijst - maar ook transitieve afhankelijkheden. Deze laatste worden niet rechtstreeks in een project geïmporteerd, maar worden indirect door een softwarecomponent gebruikt. In feite zijn het afhankelijkheden van directe afhankelijkheden. Zoals Google legde uit Dit was destijds de reden waarom zoveel Log4j-instanties niet werden ontdekt.

"Hoe dieper de kwetsbaarheid in een afhankelijkheidsketen zit, hoe meer stappen er nodig zijn om deze te verhelpen", aldus het rapport.

Brian Fox, CTO van Sonatype, legt uit dat ‘slecht afhankelijkheidsbeheer’ in bedrijven een belangrijke bron is van open-source cyberbeveiligingsrisico’s.

“Log4j is een geweldig voorbeeld. We ontdekten dat 13% van de Log4j-downloads kwetsbare versies zijn, en dat is drie jaar nadat Log4Shell werd gepatcht,” vertelt hij aan ISMS.online. “Dit is ook geen probleem dat uniek is voor Log4j – we hebben berekend dat in het afgelopen jaar 95% van de gedownloade kwetsbare componenten al een vaste versie beschikbaar had.”

Open source-risico gaat echter niet alleen over potentiële kwetsbaarheden die verschijnen in moeilijk te vinden componenten. Dreigingsactoren planten ook actief malware in sommige open source-componenten, in de hoop dat ze worden gedownload. Sonatype ontdekte 512,847 kwaadaardige pakketten in de belangrijkste open source-ecosystemen in 2024, een jaarlijkse toename van 156%.

Systemische uitdagingen

Log4j was in veel opzichten slechts het topje van de ijsberg, zoals een nieuw Linux-rapport onthult. Het wijst op verschillende belangrijke uitdagingen voor de hele sector met open-sourceprojecten:

Oude technologie: Veel ontwikkelaars blijven vertrouwen op Python 2, ook al werd Python 3 in 2008 geïntroduceerd. Dit zorgt voor problemen met achterwaartse incompatibiliteit en software waarvoor geen patches meer beschikbaar zijn. Oudere versies van softwarepakketten blijven ook bestaan ​​in ecosystemen omdat hun vervangers vaak nieuwe functionaliteit bevatten, wat ze minder aantrekkelijk maakt voor gebruikers.

Een gebrek aan een gestandaardiseerd naamgevingsschema: Naamgevingsconventies voor softwarecomponenten zijn ‘uniek, geïndividualiseerd en inconsistent’, wat initiatieven om de beveiliging en transparantie te verbeteren beperkt.

Een beperkte groep bijdragers:

"Sommige veelgebruikte OSS-projecten worden onderhouden door één persoon. Bij het beoordelen van de top 50 non-npm-projecten, had 17% van de projecten één ontwikkelaar en 40% had één of twee ontwikkelaars die verantwoordelijk waren voor ten minste 80% van de commits," vertelt David Wheeler, directeur van OpenSSF voor open source supply chain security, aan ISMS.online.

“Een project met één ontwikkelaar heeft een groter risico op latere stopzetting. Daarnaast is er een groter risico op verwaarlozing of het invoegen van kwaadaardige code, omdat er mogelijk geen regelmatige updates of peer reviews zijn.”

Cloudspecifieke bibliotheken: Dit kan leiden tot afhankelijkheid van cloudleveranciers, mogelijke blinde vlekken op het gebied van beveiliging en leveranciersafhankelijkheid.

"De grootste les is dat open source steeds kritischer wordt voor de software die cloudinfrastructuur aanstuurt", zegt Fox van Sonatype. "Er is een 'hockey stick'-groei geweest in termen van open source-gebruik, en die trend zal alleen maar doorzetten. Tegelijkertijd hebben we niet gezien dat de steun, financieel of anderszins, voor open source-beheerders groeit om deze consumptie te evenaren."

Talen die niet veilig zijn voor het geheugen:De acceptatie van de geheugenveilige Rust-taal neemt toe, maar veel ontwikkelaars geven nog steeds de voorkeur aan C en C++, die vaak kwetsbaarheden in de geheugenveiligheid bevatten.

Hoe ISO 27001 kan helpen

As Red Hat-medewerker Herve Beraud merkt op, hadden we Log4Shell moeten zien aankomen omdat het hulpprogramma zelf (Log4j) geen regelmatige beveiligingsaudits had ondergaan en alleen werd onderhouden door een klein vrijwilligersteam, een risico dat hierboven is benadrukt. Hij betoogt dat ontwikkelaars zorgvuldiger moeten nadenken over de open-sourcecomponenten die ze gebruiken door vragen te stellen over RoI, onderhoudskosten, naleving van de wet, compatibiliteit, aanpasbaarheid en natuurlijk of ze regelmatig worden getest op kwetsbaarheden.

Experts raden ook software composition analysis (SCA) tools aan om de zichtbaarheid van open-source componenten te verbeteren. Deze helpen organisaties een programma van continue evaluatie en patching te onderhouden. Beter nog, overweeg een meer holistische benadering die ook risicomanagement over propriëtaire software omvat. De ISO 27001-norm levert een gestructureerd raamwerk om organisaties te helpen hun open-source beveiligingshouding te verbeteren.

Dit omvat hulp bij:

• Risicobeoordelingen en -beperkingen voor opensourcesoftware, inclusief kwetsbaarheden of gebrek aan ondersteuning
• Het bijhouden van een inventaris van open-source software om ervoor te zorgen dat alle componenten up-to-date en veilig zijn
• Toegangscontroles zodat alleen geautoriseerde teamleden opensourcesoftware kunnen gebruiken of wijzigen
• Beveiligingsbeleid en -procedures voor het gebruik, de bewaking en de update van componenten
• Leveranciersrelatiebeheer om ervoor te zorgen dat leveranciers van open source software zich houden aan de veiligheidsnormen en -praktijken
• Continue patchbeheer om beveiligingskwetsbaarheden in open-source software aan te pakken
• Incidentmanagementprocessen, inclusief detectie en reactie op kwetsbaarheden of inbreuken die voortvloeien uit open-source
• Bevorderen van een cultuur van continue verbetering om de effectiviteit van beveiligingscontroles te verbeteren
• Training en bewustwording voor werknemers om de risico's die gepaard gaan met open-source software te begrijpen

Er kan nog veel meer gedaan worden, waaronder bug bounty-programma's van de overheid, educatieve inspanningen en community-financiering van techgiganten en andere grote zakelijke gebruikers van open source. Dit probleem zal niet van de ene op de andere dag opgelost zijn, maar de wielen zijn in ieder geval begonnen te draaien.