Den nyligen avslöjade Log4j-sårbarheten återuppstod samma gamla frågor kring den inneboende säkerheten för programvara med öppen källkod (OSS), särskilt programvara som inte stöds av skvadroner av heltidsutvecklare och säkerhetsteam.
En av de centrala underhållarna som är avgörande för att utfärda en Log4j-fix har ett heltidsjobb någon annanstans som mjukvaruarkitekt och arbetar bara med “Log4j och andra open source-projekt” på sin fritid. Även om detta användes av vissa för att hävda att gemenskapsdriven programvara inte är tillräckligt säker, menade andra att det helt enkelt lyfte fram behovet av att implementera en mer rigorös säkerhetsregim med alla program med öppen källkod som spelar en så grundläggande roll i kritisk infrastruktur.
Men det är också värt att notera att inte alla program med öppen källkod skapas lika. Visst, det finns mer än tillräckligt med bevis för att stödja argumenten att många projekt med öppen källkod är bedrövligt understödda i förhållande till deras genomträngning, men på baksidan stöds otaliga projekt – direkt eller indirekt – av megaföretag med miljarder dollar.
Säljarledd
En snabb titt på några av de bästa projekten med öppen källkod där ute visar att många började på några av världens största teknikföretag. Kubernetes, till exempel, dök upp från Googles tekniska valv 2014, och även om Google fortfarande är den mest aktiva bidragsgivaren idag, räknar projektet deltagare från stora företag inklusive Microsoft, Amazon, Intel och Alibaba. Dessutom erbjuder de “tre stora” molnföretagen (Google, Amazon och Microsoft) nu alla “Kubernetes-as-a-service”, med löfte om ytterligare support och säkerhet.
Så även om Kubernetes mycket väl kan vara “gemenskapsledd” under överinseende av Cloud Native Computing Foundation (CNCF), stöds det i slutändan av många stora företag med ett egenintresse av att Kubernetes lyckas.
Sedan finns det öppen källkod för IT-automatiseringsmotorn Ansible, som började som en oberoende enhet redan 2013, bara för att förvärvas av Red Hat för en rapporterad $100 miljoner. Red Hat själv togs sedan upp av IBM för coola 34 miljarder dollar, vilket påminner alla om hur värdefulla tjänster och support med öppen källkod har blivit.
På andra ställen har företag som bygger på en öppen källkodsbas slagit ut på de offentliga marknaderna i massor, med sådana som Elastic som nu är ett börsnoterat företag på 9 miljarder dollar (även om det sedan dess har flyttat bort från sitt ursprung med öppen källkod). Och så finns det HashiCorp, utvecklaren bakom populära produkter med öppen källkod som Terraform, som har haft en lite frostig start på livet som ett publikt företag sedan det gick upp på NASDAQ för två månader sedan.
Det kan finnas stora skillnader mellan projekt som underhålls av leverantörer eller på annat sätt har betydande företagsstöd, och samhällsledda strävanden som leds av osjälviska individer på sin fritid.
“Sårbarheterna i Log4j har tvingat kunder och användare att tänka på öppen källkod med mer nyans,” sa HashiCorps medgrundare och CTO Armon Dadgar till VentureBeat. “Bara för att ett projekt är öppen källkod på GitHub betyder det inte att du ska ta ett kritiskt beroende av det. De flesta kunder inser att det är vettigt att ha en kommersiell partner, särskilt för kritiska beroenden. Att ha ett servicenivåavtal (SLA), tillgång till support och att veta att det finns ett professionellt förhållningssätt till säkerhet och produktfärdplan är avgörande – särskilt för företag.”
Bortsett från säkerheten möjliggör leverantörsledda projekt också ett mer långsiktigt tillvägagångssätt för utveckling av programvara med öppen källkod, på grund av det enkla faktum att det finns betald personal som är dedikerad till att växa en kommersiell verksamhet. Detta kan leda till att en programvaras arkitektur utvecklas så att den är lättare att integrera och arbeta med; förbättra testfunktionaliteten för att lösa buggar eller prestandaproblem; eller mer generellt, att tillämpa en standardprodukthanteringsmetod för att prioritera nya funktioner.
“Som jämförelse tenderar samhällsledda projekt att vara mycket mer taktiska,” tillade Dadgar. “De flesta bidragsgivare löser bara sin specifika smärtpunkt. De är inte intresserade av att utveckla den övergripande arkitekturen eller hur deras problem passar in i den större helheten. Detta kan ofta lämna projekt med tekniska skulder, svaga tester som leder till buggar eller säkerhetsproblem, och en ad hoc-strategi för färdplanen och utvecklingen.”
Å andra sidan kommer leverantörsledda projekt med sina egna unika utmaningar, som att behöva balansera samhällsbaserade bidrag med det kommersiella företagets vision för projektet.
“Detta kan göras ännu mer utmanande när ett projekt har många olika leverantörer inblandade, särskilt om de har konkurrerande visioner,” sa Dadgar. “Du kan snabbt ha utarbetade styrnings- och styrstrukturer som behövs, vilket kan skapa mycket overhead.”
Även om samhällsledda projekt med öppen källkod kan ha det raka motsatta problemet (dvs. brist på tydligt ledarskap), lovar de en mer flexibel och “öppen” färdplan, som kan vara användbar för att utforska mycket specifika användningsfall som dyker upp som projektet utvecklas.
“Samhället kan börja tillämpa projektet i en domän och utveckla projektet för att bättre stödja det användningsfallet, även om det aldrig var förväntat”, förklarade Dadgar. “Denna typen av flexibilitet kan vara både användbar för att lösa nya problem, men kan också vara utmanande om det leder till räckviddskrypning (dvs. brist på riktning eller fokus).”
Så framgångsrika leverantörsledda projekt måste ofta passera en fin linje mellan att stödja sina egna affärsmål genom att förbli laserfokuserade på kärnfunktioner, samtidigt som det ger samhället tillräckligt med slack för att “klia sig själv” genom att bygga sina egna moduler och integrationer. Resultatet av allt detta – allt går bra – är en hälsosam, levande öppen källkodsgemenskap som aktivt bidrar till ett projekt.
”Det största incitamentet för [external] bidragen är att användarna löser sina egna problem”, konstaterade Dadgar. “Istället för att lämna in ett problem och vänta på att HashiCorp ska fixa något, kan de enkelt göra en pull-begäran, avblockera sig själva och bidra tillbaka till projektet. Ofta använder de våra projekt i sin startup eller stora företag, så det handlar verkligen om att lösa för sin verksamhet.”
Testtider
Sergei Egorov är en aktiv deltagare i flera projekt och gemenskaper med öppen källkod, samt är medunderhållare av Testcontainers – ett populärt Java-bibliotek med öppen källkod för integrationstestning. Från och med mars förra året är Egorov också medgrundare och VD för AtomicJar, ett företag som vill kommersialisera testcontainrar i företag.
Medan AtomicJar går i spetsen för Testcontainers utveckling, är Egorov snabb med att betona att företaget verkligen är “bara en annan medlem” i Testcontainers community. “Vi ser Testcontainers som ett gemenskapslett projekt,” sa han till VentureBeat.
Egorov noterade att en av huvudorsakerna till att gemenskapsdriven mjukvara ofta hamnar i en farlig position, är på grund av det faktum att den har vuxit organiskt från ingenting, utan en riktig plan på plats om det skulle slå ut på riktigt.
“Jag tror inte att någon framgångsrik inom öppen källkod någonsin har gett sig ut på att skapa ett framgångsrikt projekt med öppen källkod,” sa han. “Jag tror att för de flesta – om inte alla – framgångsrika projekt med öppen källkod hade skaparen en aning om att detta var en användbar sak, men de förväntade sig inte den ultimata graden av framgång.”
Och så med samhällsledda projekt finns det vad Egorov kallar en “omvänd effekt”, där ett projekt med öppen källkod börjar med få förväntningar, men sedan överstiger dessa förväntningar så småningom underhållarens kapacitet när det blir mer genomgripande och populärt.
“Det finns ingen leverantör att skylla på i ett community-drivet projekt med öppen källkod, vilket innebär att säkerhet blir en fråga om “post factum”-tänkande,” sa Egorov. “Medan leverantörsdrivna projekt alltid i förväg är oroliga över sitt offentliga ansikte och hur de kommer att behandlas om de skulle införa en säkerhetsrisk.”
Egorov tillade också att en stor fördel med community-ledda open source-projekt är att de vanligtvis kan locka bidrag från en mer mångsidig grupp utvecklare.
“Av konkurrensskäl är det ibland svårt för leverantörsledda projekt med öppen källkod att attrahera bidrag – att leverantörens konkurrenter uppenbarligen inte är intresserade av att bidra till projektet”, förklarade han. “Medan det med samhällsledda OSS-projekt inte finns några konkurrenter, drivs vi alla av samma motivation.”
Partnerskap
Närhelst ett stort problem med mjukvarusäkerhet dyker upp från projekt med öppen källkod som Log4j och OpenSSL innan det, kretsar diskussionen snart tillbaka till lösningar – hur kan vi alla fortsätta att dra nytta av flexibiliteten, tillgängligheten och skalbarheten hos community-driven programvara, utan att lita på på överarbetade, understödda underhållare?
Vita huset stod nyligen som värd för ett säkerhetstoppmöte med öppen källkod, som inkluderade deltagande från intressenter inom den offentliga och privata sektorn, som diskuterade hur man bäst kan stärka säkerheten för gemenskapsdriven programvara. Kort därefter lanserade den Linux Foundation-stödda Open Source Security Foundation (OpenSSF) Alpha Mega Project, ett nytt initiativ som stöds av sådana som Google och Microsoft och som är utformat för att säkra programvarans leveranskedja. Detta följde på ytterligare ett återkommande åtagande på 10 miljoner dollar som världens teknikjättar gjorde till OpenSSF.
Det blir allt tydligare att partnerskap och samarbete kommer att visa sig vara avgörande för alla ansträngningar att stödja OSS-försvaret, där världens regeringar tar en mer aktiv roll och driver företag att “ge tillbaka” till projekt med öppen källkod de drar nytta av.
“Jag tror att det är det bästa sättet att göra det [OSS security] hållbart är att ha det ett avlönat och primärt jobb för underhållarna”, sa Dadgar. “Detta kan göras på många olika sätt, men att skapa ideella organisationer som kan underhålla viktiga projekt och finansiera det genom statliga bidrag skulle vara en lösning.”
Egorov tillade att han inte tror att den privata sektorn kan lösa OSS-säkerhetsproblemet eftersom incitamenten är felaktiga på för många sätt. “Straffen för att förlora kunddata är till exempel fortfarande så relativt triviala att företag inte motiveras att göra rätt sak”, sa han.
Ett sätt att säkra kritisk infrastruktur och system på nationell nivå skulle vara att anställa fler cybersäkerhetsproffs på statlig nivå – men det är svårt att konkurrera med den privata sektorn om talang. Och det är därför partnerskap mycket väl kan vara namnet på spelet.
“För regeringens deltagande i OSS-säkerhet tror jag att partnerskap kan vara ett bättre tillvägagångssätt än att anställa,” sa Egorov. “Det finns stor talang hos många av världens cybersäkerhetsföretag – och även om inte många av dessa säkerhetsingenjörer skulle vara särskilt glada över att arbeta för regeringen, tror jag att många skulle vara glada över att arbeta regeringen med en möjlighet att hjälpa till att lösa detta bredare OSS säkerhetsfråga på medborgarnas vägnar.”
VentureBeats uppdrag ska vara ett digitalt stadstorg för tekniska beslutsfattare att få kunskap om transformativ företagsteknologi och handla. Läs mer om medlemskap.
