De recente ontdekking van een achterdeur in het datacompressiehulpprogramma XZ Utils – aanwezig in bijna alle grote Linux-distributies – herinnert ons er duidelijk aan dat organisaties die open source-componenten gebruiken uiteindelijk zelf verantwoordelijk zijn voor het beveiligen van de software.

XZ Utils wordt, net als duizenden andere open source-projecten, door vrijwilligers beheerd en heeft in dat geval één beheerder die het beheert. Dergelijke projecten beschikken vaak over weinig tot geen middelen voor het afhandelen van beveiligingsproblemen, wat betekent dat organisaties de software op eigen risico gebruiken. Dat betekent dat beveiligings- en ontwikkelingsteams maatregelen moeten implementeren om open source-risico's te beheersen, op dezelfde manier als ze dat doen met intern ontwikkelde code, zeggen beveiligingsexperts.

“Hoewel het onwaarschijnlijk is dat een organisatie [alle] blootstelling aan supply chain-risico’s effectief kan voorkomen, kunnen organisaties zich absoluut concentreren op een strategie om de kans te verkleinen dat een supply chain-aanval succesvol is”, zegt Jamie Scott, oprichter van productmanager bij Endor Labs.

Open source is niet hetzelfde als outsourcing: “Open source-beheerders van software zijn vrijwilligers. Op sectorniveau moeten we ze als zodanig behandelen. Wij zijn eigenaar van onze software; wij zijn verantwoordelijk voor de software die we hergebruiken.”

Goed bedoeld, te weinig middelen

Zorgen over de beveiliging van open source-software zijn bepaald niet nieuw. Maar er zijn vaak ontdekkingen nodig zoals de Log4Shell-kwetsbaarheid en achterdeur in XZ Utils om echt duidelijk te maken hoe kwetsbaar organisaties zijn voor componenten in hun code. En vaak is de code afkomstig van goedbedoelde, maar hopeloos gebrekkige open source-projecten die minimaal worden onderhouden.

XZ Utils is bijvoorbeeld in wezen een eenmansproject. Een ander individu slaagde erin sluip de achterdeur naar het hulpprogramma over een periode van bijna drie jaar, door geleidelijk genoeg vertrouwen te winnen van de projectbeheerder. Als een Microsoft-ontwikkelaar er eind maart niet op was gestuit bij het onderzoeken van vreemd gedrag dat verband houdt met een Debian-installatie, zou de achterdeur wellicht op miljoenen apparaten wereldwijd terecht zijn gekomen, inclusief die van grote bedrijven en overheidsinstanties. Het bleek dat de achterdeur een minimale impact had omdat deze versies van XZ Utils beïnvloedde die alleen aanwezig waren in onstabiele en bètaversies van Debian, Fedora, Kali, open SUSE en Arch Linux.

Het volgende compromis op het gebied van de open source-code zou nog veel erger kunnen zijn. “Het engste voor grote organisaties is dat hun applicaties bovenop open source softwareprojecten worden gebouwd, net als XZ Utils”, zegt Donald Fischer, medeoprichter en CEO van Tidelift. “XZ Utils is één pakket van tienduizenden pakketten dat elke dag door typische bedrijfsorganisaties wordt gebruikt”, zegt hij.

De meeste van deze organisaties missen voldoende inzicht in de veiligheid en veerkracht van dit deel van hun softwaretoeleveringsketen om risico's te kunnen evalueren, merkt hij op.

Een recente Harvard Business School In een studie werd de waarde aan de vraagzijde van open source-software geschat op een verbazingwekkende 8.8 biljoen dollar. Beheerders vormen de kern van dit ecosysteem en velen van hen vliegen solo, zegt Fischer. Uit een onderzoek dat vorig jaar door Tidelift werd uitgevoerd, bleek dat 44% van de beheerders van open source-projecten zichzelf omschrijft als de enige beheerders van hun projecten. Zestig procent identificeerde zichzelf als onbetaalde hobbyisten, en hetzelfde percentage zei dat ze gestopt waren of overwogen hadden hun rol als projectbeheerder op te geven. Veel beheerders beschreven hun inspanningen als stressvol, eenzaam en financieel onbelonend werk, zegt Fischer.

“De XZ utils-hack brengt de risico’s van te weinig investeren in de gezondheid en veerkracht van de open source-softwaretoeleveringsketen [waar] bedrijfsorganisaties op vertrouwen, duidelijk naar voren”, zegt Fischer. “Ondernemingsorganisaties moeten zich realiseren dat het merendeel van de meest betrouwbare open source-pakketten wordt onderhouden door vrijwilligers die zichzelf omschrijven als onbetaalde hobbyisten. Deze beheerders zijn geen zakelijke leveranciers, maar er wordt van hen verwacht dat ze net zo werken en leveren.”

Gevaar: transitieve afhankelijkheden

A onderzoek dat Endor uitvoerde in 2022 bleek dat 95% van de open source-kwetsbaarheden aanwezig zijn in zogenaamde transitieve afhankelijkheden, of secundaire open source-pakketten of bibliotheken waarvan een primair open-sourcepakket afhankelijk zou kunnen zijn. Vaak zijn dit pakketten die ontwikkelaars niet direct zelf selecteren, maar die automatisch door een open source-pakket worden gebruikt in hun ontwikkelingsproject.

“Als je bijvoorbeeld één Maven-pakket vertrouwt, zijn er gemiddeld veertien extra afhankelijkheden die je impliciet vertrouwt”, zegt Scott. “Dit aantal is zelfs nog groter in bepaalde software-ecosystemen zoals NPM, waar je gemiddeld 14 andere softwarecomponenten importeert voor iedereen die je vertrouwt.”

Eén manier om te beginnen met het beperken van open source-risico's is door aandacht te besteden aan deze afhankelijkheden en selectief te zijn in de projecten die je kiest, zegt hij.

Organisaties moeten de afhankelijkheden onderzoeken, vooral de kleinere, eenmalige pakketten, bemand door teams van één of twee personen, voegt eraan toe Dimitri Stiliadis, CTO en mede-oprichter van Endor. Ze moeten bepalen of afhankelijkheden in hun omgeving over de juiste beveiligingscontroles beschikken of dat één individu alle code pleegt; of ze binaire bestanden in hun repositories hebben waar niemand iets vanaf weet; of zelfs als iemand het project überhaupt actief onderhoudt, zegt Stiliadis.

“Richt uw inspanningen op het verbeteren van uw reactie-effectiviteit. Fundamentele controles, zoals het bijhouden van een volwassen software-inventaris, blijven een van de meest waardevolle programma’s die u kunt hebben om softwarerisico’s snel te identificeren, te reiken en erop te reageren zodra ze zijn geïdentificeerd,” Scott adviseert.

Analysetools voor softwaresamenstelling, kwetsbaarheidsscanners, EDR/XDR-systemen en SBOM's kunnen organisaties ook allemaal helpen bij het snel identificeren van kwetsbare en gecompromitteerde open source-componenten.

Erkenning van de dreiging

“Het beperken van de blootstelling begint met gedeeld begrip en erkenning binnen de C-suite en zelfs op bestuursniveau dat ruwweg 70% van de ingrediënten van het gemiddelde softwareproduct open source-software is die historisch gezien door veelal niet-gecompenseerde bijdragers is gemaakt”, zegt Fischer van Tidelift.  

Nieuwe regelgeving en richtlijnen in de financiële dienstverleningssector, de FDA en NIST zullen bepalen hoe software de komende jaren wordt ontwikkeld en organisaties moeten zich daar nu op voorbereiden. “De winnaars hier zullen zich snel aanpassen van een reactieve strategie naar een proactieve strategie voor het beheersen van open source-gerelateerde risico’s”, zegt hij.

Fischer raadt organisaties aan om hun beveiligings- en engineeringteams te laten identificeren hoe nieuwe open source-componenten in hun omgeving terechtkomen. Ze moeten ook rollen definiëren voor het monitoren van deze componenten en proactief de rollen verwijderen die niet passen bij de risicobereidheid van het bedrijf. “Reageren op problemen in een laat stadium is de afgelopen jaren een ineffectieve manier geworden om met de omvang van het risico voor het bedrijf om te gaan. De Amerikaanse regering geeft signaal Dat tijdperk loopt ten einde”, zegt hij.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security