Det finns öppen källkod i nästan alla programutvecklingsprojekt du kan tänka dig. Utvecklare älskar det. Men du måste förstå de dolda riskerna och hur du minimerar dem, annars kan du lämna din applikation öppen för okända säkerhetsproblem.
Kodning före öppen källkod
En gång i tiden skrev mjukvaruutvecklare allt från grunden. Då började kodbibliotek, verktygslådor och andra tillägg visas. Du kan få ett steg upp genom att använda en verktygslåda för att tillhandahålla vissa funktioner, till exempel en rapporteringsmodul eller en gränssnittswidget. Du kan lägga in dessa i ditt projekt som färdiga färdiga komponenter och använda dem direkt. Alternativet var att slösa bort tid, pengar och utvecklingsarbete för att återuppfinna hjulet.
Naturligtvis skulle du med tiden bygga upp ett eget bibliotek med rutiner och moduler som hade skrivits internt. Så när du utvecklade en ny kodrutin eller gränssnittselement hade du tre alternativ. Skriv det själv, återanvänd några tidigare skrivna interna koder, eller köp i ett bibliotek eller verktygslåda.
The Rise of Open Source
Tillkomsten av öppen källkod förändrade allt detta. Programvara med öppen källkod gör källkoden till ett projekt fritt tillgänglig för andra, inom gränserna för en — vanligtvis godartad — licens. Tillväxten och användningen av öppen källkod har båda varit häpnadsväckande. Ordet spridning verkar inte täcka det. Det har skett en fenomenal ökning av öppen källkodsprogramvara, och inte bara när det gäller det häpnadsväckande antalet öppen källkodsprojekt och produkter som finns, utan också i användningen av öppen källkod inom kommersiella produkter.
< p>Programvara med öppen källkod nådde en kritisk massa för några år sedan, och den har skjutit i höjden från en nischposition på sidlinjen till en fullt utvecklad allmänt utvecklad resurs. Eftersom det drivs och utvecklades av ett samhälle och inte av ett traditionellt kommersiellt företag, betraktades det också som en slags amatör.
Annonsering
Nu känns det som att öppen källkod har vuxit upp och mognat. Och det har det. Men den största förändringen har varit en större uppskattning av öppen källkod, en förståelse för de fördelar den medför och erkännande av att inkludering av öppen källkod i din produkt inte är något att skämmas för.
Uppskattningar tyder på att icke-triviala mjukvaruprojekt skriver högst 20 procent av originalkoden. De andra 80 procenten är öppen källkod. Den stora öppen källkodslager, GitHub, träffade över 100 miljoner lagringsplatser under 2018. Och det finns många andra Git-plattformar som värd, som GitLab och BitBucket.
Öppen källkod är ett fenomen för mjukvaruutveckling. Men det är inte alla rosor i utvecklingsträdgården. Det finns frågor som du måste vara medveten om och hantera.
Säkerhetsfrågorna
Att använda öppen källkodskomponenter i stora mjukvaruprojekt minskar utvecklingskostnaderna, förkortar utvecklingstiden från början till slut och det har hävdats att “främjar innovation”. Eftersom det frigör din utvecklingspersonal från det vardagliga gör det att de kan fokusera på de unika och marknadsattraktiva aspekterna av din produkt.
Det finns några produkter med öppen källkod som har en kommersiell enhet bakom sig. Organisationen släpper ut sin produkt under ett system med dubbla licenser. En kommersiell version kommer att ha en officiell, professionell, supportkanal och kan innehålla andra fördelar, till exempel proprietära tillbehör som följer med produkten. De släpper också en version som stöds av gemenskapen och som kommer att dra nytta av det kommersiella teamets kodningsinsatser samt av bidrag från det egna samhället. Betydande samhällsbidrag kommer också att ta sig tillbaka till den kommersiella versionen.
Majoriteten av projekt med öppen källkod är dock helt samhällsdrivna. De kan ha stöd av kommersiella enheter, men det stödet är donationer och sponsring, inte kodbidrag.
Annonsering
Oavsett deras ursprung, tenderar de öppen källkodskomponenter som väljs att ingå i nya utvecklingsprojekt att vara väletablerade och välrenommerade projekt i sig. De har förtjänat en hög grad av förtroende. Men så är inte alltid fallet. Ibland är den funktionalitet du behöver tillgänglig, men den finns i ett nytt och något obevisat projekt. Men du har väl källkoden? Du kan göra en kodgranskning av den.
Ur säkerhetssynpunkt är öppen källkod varken mer eller mindre säker än egenutvecklad hemodlad kod. Det är trots allt all mänskligt skriven kod. Förespråkare för öppen källkod pekar på Eric S. Raymonds lag som han namngav för att hedra Linus Torvalds, som säger att “ med tillräckligt med ögonbollar är alla buggar grunda. ” Med tillräckligt många som granskar koden och betatesterar den, bör problem identifieras, karaktäriseras och åtgärdas snabbt.
Det stämmer så långt det går. Men säkerhetsfrågor är inte nödvändigtvis buggar. En sårbarhet kan vara en omständighet som uppstår som en bieffekt av komplex logik i ett projekt med många källkodsmoduler som uppgår till miljoner koderader. Produkten gör vad den ska, och den anses därför fungera som avsett. Och så klarar den kodgranskning, produktverifiering, fälttester och får en ren hälsa.
Utanför blind lycka och händelse kommer den gransknings-, test-, prövnings- och släppslingan inte att upptäcka säkerhetsproblem.
Varför öppen källkod är attraktiv för hackare
Dessutom finns det aspekter av öppen källkod som är positivt attraktiva för hackare och hotaktörer. De kan också se källkoden. De kan leta efter sårbarheter med ett annat tänkesätt än den genomsnittliga samhällsbidragsgivaren som, även om de mycket väl kan vara en kompetent utvecklare, sannolikt inte har någon verklig säkerhetsbakgrund.
Naturligtvis bidrar det till öppen källkod finns i alla smaker med varierad bakgrund. Några av dem kommer utan tvekan att ha säkerhetserfarenhet i verkliga världen — men de kommer att vara minoriteten. Hotaktörer är ett annat djur helt och hållet. Och de är inte begränsade till att hitta sårbarheter, de kan också injicera dem.
Annonsering
Det har varit många fall där en hotaktör introducerade en sårbarhet via en patch som de skapade och skickade till ett projekt. Det tog sig igenom kodgranskning, in i kodbasen och in i nästa version av produkten.
Kanske var det ultimata exemplet på detta en JavaScript-komponent som kallas event-stream. Detta open-source-projekt underhålls av en enda utvecklare. Förvaltningsbördan för projektet växte ut honom. Han övertalades att överlämna den till en ny underhållare.
Den nya underhållaren var en hotaktör. De tog över projektet, körde det som vanligt under en kort period och lade sedan till skadlig kod till det. Varje kopia av alla andra program som använde den programvarukomponenten kapade tyst vissa typer av Bitcoin-plånbok för hotaktören.
Vad du kan göra för att minska risken
Som med många aspekter av säkerhet hanterar du denna risk genom att använda kontroller. Det kräver styrning — med andra ord, policyer och rutiner. Tack och lov finns det programvara som kan hjälpa.
Skapa ett Open Source -register
Du måste kvantifiera den öppna källkod du använder. Skapa ett register som listar de öppen källkodskomponenter du använder i dina projekt. Lista varje öppen källkodskomponent, versionen eller versionerna du har använt, de projekt du har använt dem i, vad den senaste versionen är och var den kan laddas ner. I designdokumentationen för vart och ett av dina projekt bör du lista de öppen källkodskomponenter som används.
Djävulen finns i detaljerna. Glöm inte beroenden och hierarkiska karaktären hos mycket öppen källkod. Öppen källkodsprojekt använder ofta andra projekt inom sig själva, kapslade som ryska dockor, eller så krävs att andra öppen källkodskomponenter installeras på målmaskinen så att de kan använda dem.
Annonsering
Utforska dessa beroenden och ange dem i ditt öppen källkod.
Kör automatiska granskningar
Sårbarheter i paket med öppen källkod är ett stort problem för NPM, pakethanteraren för JavaScript. För att åtgärda detta skapade de ett automatiskt granskningsverktyg som söker efter inaktuella paket med säkerhetsuppdateringar.
Detta har naturligtvis sina begränsningar, och det är viktigt att vara medveten och inte helt förlita sig på automatiskt verktyg. Det kommer bara att fånga paket med kända sårbarheter och uppdateringar. Om paketet har en sårbarhet, men inte har uppdaterats för att åtgärda det, kommer NPM -granskning inte att berätta något för dig.
RELATED: Granska dina NPM -beroende, De står för 86% av säkerhetsbuggarna
Skapa en sårbarhetskarta
Ditt öppen källkodsregister ger dig en tydlig bild av den öppna källan som du använder. Nästa steg är att kartlägga kända sårbarheter till det registret. Ibland kan dessa upptäckas genom att besöka projektets hemsida och titta på listan över kända problem.
National Vulnerability Database (NVD) ger dig en mycket mer detaljerad bild. Du kan använda deras söksida för att söka efter produkter efter namn för att ta reda på vilka vanliga sårbarheter och exponeringar som påverkar den programvarukomponenten. NVD är en bra resurs, även om formatet tar lite avveckling tills du vänjer dig.
Uppdatera ditt register och sårbarhetskarta
Naturligtvis är detta något du måste hålla koll på. Nya sårbarheter upptäcks hela tiden, så säkerheten för din produkt vid lanseringen kommer sannolikt att urholkas långsamt med tiden.
Annonsering
När det här nya behovet erkänns finns det kommersiella (Black Duck, WhiteSource) applikationer som hjälper till med detta. De kan skanna dina projekt och identifiera öppen källkod och leta upp sårbarheter automatiskt. Några av dessa (FOSSA) erbjuder en gratis nivå.
Statisk analys av din kodbas — inklusive öppen källkodskomponenter — borde i alla fall vara en standard del av din utvecklingsstriktighet. Verktyg som Coverity Scan kan hitta defekter i din kod som buffertöverflöden som kan leda till sårbarheter. Det kommer till och med att ge råd om hur de kan åtgärdas.
Kontrollera Open Source -licenser och följ dem
Se till att du förstår de licenser som gäller för den öppna källkod som du använder . Det finns många olika licenser, så kontrollera att du uppfyller alla krav. Involvera din licens- eller compliance officer, om du har en.
Att inte följa en öppen källkodslicens kan leda till tvister. Öppen källkodsprojekt svarar lika snabbt på licensbrott som kommersiella programvaruhus.
Uppdatera dina öppen källkodskomponenter
Eftersom sårbarheter åtgärdas av gemenskaperna i öppen källkod du använd, se till att du uppgraderar dina versioner så att du drar nytta av dessa korrigeringar. Öppen källkod använder en “ pull ” modell. De meddelar en ny fix och sedan måste du ladda ner den nya versionen. Detta är motsatsen till mycket kommersiell programvara som har en “ push ” modell där uppdateringar överförs till de registrerade användarna.
Annonsering
Övervaka projektsidorna för nya versionskungörelser och ladda ner och testa de nya versionerna.
Kostnaden för öppen källkod
Programvara med öppen källkod är gratis att få, men den kommer med en administrations- och styrningskostnad. Konsekvenserna måste förstås och kontrolleras för att kunna använda det säkert och med minimal risk.