Forrester Research Contributor
Forrester (Nasdaq: FORR) är ett av de mest inflytelserika forsknings- och rådgivningsföretagen i världen. Vi hjälper ledare inom teknik, marknadsföring, kundupplevelse, produkt- och försäljningsfunktioner att använda kundbesatthet för att påskynda tillväxten.
Fullständig bio publicerad i Forrester den 28 januari 2022 | Ämne: Säkerhet
Det har förekommit några högprofilerade säkerhetsproblem med programvara med öppen källkod. En missnöjd utvecklare levererade nyligen avsiktligt modifierade versioner av sina faker.js- och colors.js-paket, vilket bröt “tusentals projekt” som förlitade sig på dem. Vissa undrar om det överhuvudtaget är säkert att använda programvara med öppen källkod. Vita huset är det verkligen – de har bett stora teknikföretag att kommentera mjukvarusäkerhet i efterdyningarna av Log4j-frågan, som exponerade otaliga servrar för fjärrexploatering.
Är kod som är skriven av frivilliga mindre säker än kod skriven av professionella utvecklare? Behöver du få någon att stämma om en produkt misslyckas? Får du verkligen vad du betalar för?
Vad är öppen källkod?
Precis som det skulle vara ett misstag att säga att alla projekt med stängd källkod är buggfria, är det ett misstag att säga att alla projekt med öppen källkod är säkerhetsrisker. Olika projekt har olika fokus; några av dem är mycket mer bekymrade över säkerheten för sina utgivningar.
Josh Berkus har identifierat fem typer av projekt med öppen källkod baserat på deras struktur:
Ett solo-projekt är passionen för en individ eller som mest, några hängivna personer med samma vision.
En monarki är ett framgångsrikt soloprojekt som Linux som har fått stöd av en stor gemenskap av bidragsgivare, så den ursprungliga skaparen agerar som en välvillig tyrann.
Ett community-projekt som PostgreSQL dyker upp bland kamrater med liknande mål och drivs av konsensus.
Ett företagsprojekt släpps ofta som en del av ett kommersiellt projekt, som när Sun släppte OpenOffice som en öppen källkodsgaffel för StarOffice. Dess riktning styrs av företaget som släppte den.
En grund, den mest formella, är en fristående affärsstruktur – som Apache kanske är det bästa exemplet på. Där är det en styrelse som fattar besluten.
I allmänhet är soloprojekt de mest utsatta för säkerhetsrisker. Precis som en författare kan uppdatera sin webbsida med vilket innehåll som helst, kan en ensamutvecklare uppdatera sin kod på samma sätt. Ofta finns det inte tillräckligt med intresse i en gemenskap för att dela upp soloprojekt, så de blir de facto standarder. Vi såg detta med faker.js och colors.js, när Marak Squires modifierade sin kod för att skriva ut flaggor och gå in i oändliga loopar.
Säkerheten för projekt med både öppen och sluten källkod beror på deras bidragsgivares fokus snarare än på deras struktur. Vi har haft turen att Linus Torvalds har haft säkerhet som ett av sina bekymmer. Theo de Raadt, har varit medveten om säkerheten för OpenBSD från början. Däremot hade både StarOffice (kommersiellt) och OpenOffice säkerhetshål som möjliggjorde fjärrexekvering av godtycklig kod i XML-dokument.
Många ögon fokuserade någon annanstans?
En av ironierna med öppen källkod är antagandet att många ögon förbättrar säkerheten. I flera år har vi hört påståenden om att öppen källkod var säkrare eftersom “gemenskapen” kunde granska koden. Problemet: “Communityn” granskar sällan koden, och alla antog bara att någon annan gjorde det. Den falska känslan av säkerhet exploderade verkligen under Heartbleed — verkligheten med för mycket kod och för få ögon betyder att vi behöver bättre processer och automatisering för att förbättra säkerheten med öppen källkod.
Det finns dock en annan falsk känsla av säkerhet: Anta inte att programvara med stängd källkod har bättre processer bara för att du inte kan se dem. I fallet med Heartbleed granskade “gemenskapen” så småningom hålen i OpenSSL, och lösningen var … mer öppen källkod. LibreSSL, en gaffel av OpenSSL, hade fokus på säkerhet snarare än bakåtkompatibilitet.
Öppen källkod kräver delad ansvarighet
Även om du inte betalar pengar när du använder programvara med öppen källkod, betyder det inte att du inte har skyldigheter – för ditt företag, dina kunder och samhället. Var ansvarsfull när du använder programvara med öppen källkod:
Vet vad du använder. En av de största farorna med vissa ekosystem är hur lätt ett projekt med öppen källkod kan inkludera ett annat. Många projekt inkluderar idag andra projekt som komponenter. System som npm gör det enkelt att ta in kod utan att inse det. Det finns verktyg som hjälper till att generera mjukvaruförteckningar (SBOM) och för att skanna din kod för att se om du är beroende av något du inte visste om.
Undvik ensamma och övergivna projekt. En enda skadlig utvecklare kan injicera mycket skada – särskilt om du uppgraderar automatiskt. Faran med att använda övergivna projekt är att de kanske inte står för moderna sårbarheter. Utvärdera statusen för de projekt du använder med varje release.
Testa innan du släpper.Mycket av faran med projekt med öppen källkod kommer från uppgradering utan testning. Om din kod innehåller ett bibliotek med öppen källkod med en exploatering, kommer dina användare att hålla dig ansvarig. Certifiera med specifika versioner av projekt och håll dem uppdaterade. Fork open source-bibliotek som du använder och dedikerar resurser till att granska vad som har begåtts.
Planera för uppdateringar. Log4j-sårbarheten var särskilt farlig eftersom den tillät exekvering av godtycklig kod på plattformar som har programvara inbakad i ROM. För vissa internet-of-things-enheter finns det inget sätt att uppgradera Log4j-biblioteket för att fixa det. Detta lämnar en ihållande sårbarhet som inte kan åtgärdas. Placera inte din produkt i samma situation. Ange en sökväg för uppgradering (och nedgradering!) för varje komponent. Vänta inte på ett säkerhetsproblem för att uppgradera din kod heller – planera att uppdatera regelbundet till nyare versioner för att förbättra din kods hygien.
Bidra till projekt med öppen källkod. Många projekt med öppen källkod levererar användbar kod med få resurser. Förbind dig att bidra antingen ekonomiskt eller genom att tillhandahålla utvecklings- eller QA-resurser till de bibliotek med öppen källkod du använder. Begränsa inte dina bidrag med öppen källkod till den dag du hämtar biblioteket – öppen källkod behöver kontinuerligt stöd, så inkludera bidrag med öppen källkod i din årliga budget och långsiktiga planering. Du vill vara säker på att den senaste versionen är lika säker som den du först hämtade.
Investera i DevSecOps.Anta att frekventa uppdateringar är normen, inte undantaget. Oavsett om det är kod skapad av ditt eget team eller kod du hämtat från ett projekt med öppen källkod, inse att buggar kommer att hända, uppdateringar kommer att behövas och att det i vissa fall kommer att krävas snabb iteration för att hänga med i förändringar. DevOps, i form av CI/CD, är nu bordsinsatser; öka satsen genom att lägga till “Sec” — möjligheten att flytta åt vänster automatiska säkerhetskontroller direkt in i utvecklingscykeln så att när dessa uppdateringar kommer in, är du bättre förberedd på att få åtgärden ut genom dörren med färre hela natten och mycket mindre slit och stress.
Vakna upp ur mardrömmen
Om du är rädd för att använda öppen källkod är det för sent. Du kommer sannolikt inte att använda en produkt idag utan komponenter med öppen källkod. Det är nästan säkert att du läser detta med en webbläsare baserad på teknik med öppen källkod, som serveras av en webbserver som har en kärna med öppen källkod — allt byggt med verktyg med öppen källkod. Även om en mardröm inte är verklighet, kan den vara ett svar på legitim ångest. Använd öppen källkod på ett ansvarsfullt sätt för att undvika gåshud.
Det här inlägget skrevs av senioranalytiker Andrew Cornwall och det visades ursprungligen här.
ZDNet rekommenderar
Bästa Google Chrome-tillägget 2022: Gratis och användbara verktyg Bästa Chromebook-erbjudanden: Samsung, Acer, HP och fler Bästa Apple AirPods-erbjudanden: 99 $ AirPods och mer Deal : Spara $200 på den nyligen släppta GoPro Hero 10-kameran Köpa en begagnad bärbar dator: Var hittar du de bästa erbjudandena Säkerhets-TV | Datahantering | CXO | Datacenter