Software vormt de kern van alle moderne bedrijven en is cruciaal in elk aspect van de bedrijfsvoering. Bijna elk bedrijf zal open source software gebruiken, bewust of onbewust, aangezien zelfs bedrijfseigen software afhankelijk is van open source bibliotheken. OpenUK's Uit het rapport 'State of Open' uit 2022 bleek dat 89% van de bedrijven op open source software vertrouwde, maar niet allemaal zijn ze duidelijk over de details van de software waarop ze vertrouwen.
Bedrijven eisen steeds meer informatie over hun bedrijfskritische software. Verantwoordelijke bedrijven hebben een gedetailleerde interesse in hun softwaretoeleveringsketen en maken een softwarelijst van materialen (SBOM) voor elke toepassing. Dit informatieniveau is cruciaal, zodat wanneer er beveiligingsfouten in hun software worden vastgesteld, ze onmiddellijk zeker kunnen zijn welke software en versies in gebruik zijn en welke systemen zijn getroffen. Kennis is macht in deze situaties!
Afhankelijkheid van vrijwilligers
Eind 2021 werd een beveiligingsprobleem genaamd Log4Shell werd geïdentificeerd in een veelgebruikt Java-logging-framework, Log4j. Aangezien dit een veelgebruikte open source-bibliotheek is, werd de kwetsbaarheid goed bekend gemaakt en werden er oplossingen verwacht. echter, de de beheerders van het project waren vrijwilligers. Ze hadden dagtaak en waren niet oproepbaar voor dringende beveiligingsoplossingen, zelfs niet als een groot aantal systemen was getroffen. Alleen al deze kwetsbaarheid had naar schatting 93% van de zakelijke cloudomgevingen getroffen.
Destijds was er enige negatieve pers over open source, maar de waarheid is dat als dit een closed-sourcecomponent was, de kwetsbaarheid misschien nooit publiekelijk bekend was, waardoor organisaties vatbaar waren voor aanvallen. Het open source-karakter van de bibliotheek betekende dat deze kon worden geïnspecteerd, de problemen konden worden gevonden en advies kon worden gegeven door anderen. Dus ja, de beheerders waren niet oproepbaar voor beveiligingsproblemen in hun vrijwilligersproject. De grote vraag is dan: hoe zijn we in een situatie terechtgekomen waarin grote bedrijven afhankelijk waren van software die de verantwoordelijkheid was van iemand die iets anders doet om hun rekeningen te betalen?
Het negeren van software-afhankelijkheden is een riskante zaak, ongeacht de licentie van de software, maar wanneer het open source is en op grote schaal wordt gebruikt, wordt het bijzonder gevaarlijk. Vasthouden aan het verhaal van één kwetsbaarheid; het probleem bestond al jaren in de codebase, maar werd niet opgemerkt. De tool die zo veel werd gebruikt, werd in feite niet zo breed ondersteund - en wat er daarna gebeurde is geschiedenis.
Dit verhaal wordt keer op keer herhaald, bij zoveel bedrijven die kritieke afhankelijkheden hebben, maar geen actie ondernemen om de beheerders of de projecten zelf te ondersteunen. Het hebben van een SBOM voor de software die een bedrijf gebruikt, betekent dat ze de informatie bij de hand hebben. Voor organisaties die software aan anderen leveren, is de verwachting om naast de code ook de SBOM te leveren steeds meer de norm.
Ken afhankelijkheden om risico's te beoordelen
Kennis van de afhankelijkheden maakt het gemakkelijker om het risico dat aan elke afhankelijkheden is verbonden, te beoordelen. Deze open source-projecten zijn het eenvoudigst te beoordelen: wordt er gereageerd op problemen en zijn er recentelijk releases geweest? Het kunnen zien van de beheerders en projectactiviteit voor elk project geeft een goed inzicht in de gezondheid van het project.
Bedrijven kunnen hun rol spelen om de risico's te verminderen door de projecten waarvan ze afhankelijk zijn te ondersteunen. Sommige projecten accepteren sponsoring rechtstreeks via het GitHub Sponsors-schema, andere waarderen in plaats daarvan aanbiedingen van hosting of een beveiligingsaudit. Elk open source project stelt bijdragen op prijs. Als uw bedrijf deze bibliotheek zelf had gemaakt, zouden de technici binnen het bedrijf elke bug zelf moeten oplossen.
Open source lijkt meer op een regeling voor gedeeld eigendom. We hoeven niet allemaal herhaaldelijk hetzelfde te bouwen, maar kunnen juist een bijdrage leveren, wat zowel minder moeite kost als tot een betere kwaliteit leidt. Een van de meest impactvolle dingen die bedrijven kunnen doen, is een beetje van hun technische middelen gebruiken en bijdragen aan bugfixes of functies voor projecten die zo essentieel zijn voor het bedrijf.
Uw eigen engineers betrokken houden bij een project heeft veel voordelen. Ze leren het kennen en kunnen een oogje houden op nieuwe features, of wanneer er een nieuwe release beschikbaar is. Cruciaal is dat het bedrijf inzicht heeft in de gezondheid en status van het afhankelijke project en deel uitmaakt van wat het gezond houdt, waardoor het risico voor het bedrijf van een probleem met een afhankelijkheid wordt verminderd. Een aantal organisaties, waaronder Aiven, heeft een OSPO (open source programmabureau), met personeel dat zich toelegt op het bijdragen aan of zelfs onderhouden van de projecten die door de organisatie worden gebruikt. Deze afdelingen dragen vaak bij aan de algemene aanwezigheid van het bedrijf in het open source-ecosysteem en stellen andere medewerkers in staat om met open source om te gaan.
Een andere benadering is het ondersteunen van de organisaties die bestaan om open source te ondersteunen. De OpenSSF (Open Source Security Foundation) werkt aan het verbeteren van de beveiliging van open source-projecten en wordt gefinancierd door de organisaties die afhankelijk zijn van die projecten. Het publiceert ook uitstekende leermiddelen zodat bedrijven zichzelf kunnen informeren over de risico's van de software die ze gebruiken. Een andere soortgelijke organisatie is Tidelift, die samenwerkt met beheerders om ervoor te zorgen dat aan bepaalde basisvereisten wordt voldaan, opnieuw gefinancierd door de organisaties. Tidelift biedt ook tools en onderwijs om bedrijven te helpen hun softwaretoeleveringsketen te beheren en best practices op dit gebied toe te passen.
Een veiligere softwaretoekomst veiligstellen
Bedrijven zijn afhankelijk van software, en dit omvat open source software, die veel wordt gebruikt en doorgaans veiliger is dan propriëtaire alternatieven.
Dit is een slimme zet, maar een nog slimmere zet is om duidelijke kennis te hebben van de softwaretoeleveringsketen en zijn afhankelijkheden. Wanneer er zich toch een probleem voordoet, helpt elke organisatie, afhankelijk van gezonde projecten en het beschikbaar hebben van de details van uw software. Als elke organisatie dit zou doen, wordt het risico op gebeurtenissen zoals de Log4Shell-kwetsbaarheid verkleind.
