Steven Vaughan-Nichols Senior bidragande redaktör
Steven J. Vaughan-Nichols, alias sjvn, har skrivit om teknologi och teknikens verksamhet sedan CP/M-80 var det banbrytande PC-operativsystemet; 300 bps var en snabb Internetanslutning; WordStar var den senaste ordbehandlaren; och vi gillade det.
Fullständig biografi Publicerad i Linux och öppen källkod den 27 december 2021 | Ämne: Säkerhet
Linux finns överallt. Det är vad alla moln, även Microsoft Azure, kör. Det är det som gör att alla 500 av de 500 bästa superdatorerna fungerar. Heck, även desktop Linux växer om man kan tro Pornhub, som hävdar att Linux-användare växte med 28%, medan Windows-användare minskade med 3%.
Programvara med öppen källkod växer också med stormsteg. Enligt Gartners 2021 Hype Cycle for Open-Source Software (OSS): “Till 2025 kommer mer än 70 % av företagen att öka sina IT-utgifter för OSS, jämfört med sina nuvarande IT-utgifter. Plus, år 2025, mjukvara som en tjänst ( SaaS) kommer att bli den föredragna konsumtionsmodellen för OSS på grund av dess förmåga att leverera bättre operativ enkelhet, säkerhet och skalbarhet.”
Tänker på databaser, nötköttet och potatisen i företagsprogramvara, förutspår Gartner att över 70 % av nya interna applikationer kommer att utvecklas på en databas med öppen källkod. Samtidigt kommer 50 % av befintliga proprietära relationsdatabasinstanser att ha konverterats eller håller på att konverteras till DBMS med öppen källkod.
Jag köper de siffrorna. Jag har följt Linux och öppen källkod sedan dag ett. Vart jag än går och alla jag pratar med erkänner att paret driver mjukvaruuniversumet.
Men med stor kraft kommer också ett stort ansvar som Spider-Man vet. Och, som många utvecklare nyligen upptäckte när flera säkerhetsbrister med Apaches Java-loggning med öppen källkodsbibliotek log4j2 upptäcktes, kommer också stor huvudvärk.
Log4j2-problemen är hur illa som helst. Enligt National Vulnerability Database (NVD)-skalan är den klassad som 10.0 CVSSv3 vilket är helt fruktansvärt.
Dess verkliga problem är inte så mycket med öppen källkod i sig. Det finns inget magiskt med öppen källkodsmetod och säkerhet. Säkerhetsfel kan fortfarande ange koden. Linus lag är att med tillräckligt många ögonglober är alla insekter ytliga. Men om inte tillräckligt många utvecklare letar kommer säkerhetssårbarheter fortfarande att förbli obemärkta. Som det jag nu kallar Schneiers lag, “Säkerhet är en process, inte en produkt”, påpekar det att konstant vaksamhet behövs för att säkra all mjukvara.
Som sagt, den verkliga smärtan med log4j är hur Java döljer vilka bibliotek dess källkod och binärer använder i många Java Archive (JAR)-varianter. Resultatet? Du kanske använder en sårbar version av log4j och vet inte förrän den har utnyttjats.
Som Josh Bressers, Anchores vice president för säkerhet nyligen förklarade, “En av utmaningarna som log4j-sårbarheten innebär är faktiskt att hitta den. Java-applikationer och beroenden är vanligtvis i något slags paketeringsformat som gör distributionen och körningen väldigt enkel, men det kan gör det svårt att ta reda på vad som finns i dessa programpaket.”
Lyckligtvis finns det log4j-skannrar som kan hjälpa dig att upptäcka defekta log4j-bibliotek som används. Men de är inte perfekta.
Bakom log4j-röran finns ett annat problem, det är “Hur vet du vilka komponenter med öppen källkod som din programvara använder?” Till exempel har log4j2 använts sedan 2014. Du kan inte förvänta dig att någon kommer ihåg om de använde den första versionen i något program som du fortfarande använder idag.
Svaret är ett som communityn med öppen källkod började ta på allvar under de senaste åren: skapandet av Software Bills of Material (SBOM). En SBOM anger exakt vilka programvarubibliotek, rutiner och annan kod som har använts i något program. Beväpnad med detta kan du undersöka vilka komponentversioner som används i ditt program.
Som David A. Wheeler, Linux Foundations chef för Open Source Supply Chain Security, har förklarat, kan du genom att använda SBOMs och verifierade reproducerbara builds se till att du vet vad som finns i dina program. På så sätt, om ett säkerhetshål hittas i en komponent, kan du helt enkelt korrigera det istället för att söka som en galning efter eventuella problemkoder innan du kan fixa det.
“En reproducerbar konstruktion”, förklarar Wheeler förresten, är en “som alltid producerar samma utdata med samma indata så att byggnadsresultaten kan verifieras. En verifierad reproducerbar konstruktion är en process där oberoende organisationer producerar en build från källkod och verifiera att de byggda resultaten kommer från källkoden som görs anspråk på.”
För att göra detta måste du och dina utvecklare spåra dina program i en SBOM med hjälp av Linux Foundations Software Package Data Exchange (SPDX)-format. Sedan, för att ytterligare säkerställa att din kod verkligen är vad den utger sig för att vara, måste du notarisera och verifiera din SBOM med tjänster som Codenotary Community Attestation Service och Tidelift Catalogs.
Allt detta är lätt att säga. Gör det svårt. Under 2022 kommer i stort sett alla utvecklare med öppen källkod att spendera mycket tid på att kontrollera sin kod för problem och sedan bygga SPDX-baserade SBOM. Användare som är oroliga över katastrofer av typen Solarwind och log4j-säkerhetsproblem kommer att kräva detta.
Samtidigt jobbar Linux-utvecklare på att ytterligare säkra operativsystemet genom att göra Rust Linuxs andraspråk. Varför? Eftersom, till skillnad från C, Linuxs primära språk, är Rust mycket säkrare. Specifikt är Rust mycket säkrare än C för att hantera minnesfel.
Som Ryan Levick, en av Microsofts främsta förespråkare för molnutvecklare, förklarade: “Rost är helt minnessäker.” Det är en stor affär, eftersom, som Linux-kärnutvecklarna Alex Gaynor och Geoffrey Thomas påpekade vid Linux Security Summit 2019, kommer nästan två tredjedelar av säkerhetshålen i Linux-kärnan från minnessäkerhetsproblem. Och var kommer de ifrån? Inneboende problem med C och C++.
Nu ska Linux skrivas om i Rust. Åtminstone inte detta decennium, kolla med mig igen på 2030-talet, men en hel del Linux-drivrutiner och annan kod kommer att skrivas framöver i Rust.
Som Linus Torvalds sa till mig medan han “på inget sätt “pressar” för Rust,” är han “öppen för det med tanke på de utlovade fördelarna och undvika vissa säkerhetsfällor. Ändå, avslutade han, “Jag vet också att ibland går inte löften ut.”
Vi får se hur allt fungerar. Oavsett hur detaljerna går, en sak vet jag säkert. Vi kommer att se att säkerhetskoden blir toppfråga för Linux- och öppen källkodsutvecklare 2022. De har båda blivit för viktiga för att det ska gå någon annan väg.
Relaterade berättelser:
2022-teknik trendgranskning, del ett: Öppen källkod, moln, blockchainCodenotary: Notarisera och verifiera din mjukvarulistaRust tar ett stort steg framåt som Linuxs andra officiella språk Enterprise Software | Säkerhets-TV | Datahantering | CXO | Datacenter