Steven Vaughan-Nichols Senior bidragende redaktør
Steven J. Vaughan-Nichols, aka sjvn, har skrevet om teknologi og teknologiens forretning, siden CP/M-80 var det banebrydende pc-operativsystem; 300bps var en hurtig internetforbindelse; WordStar var den nyeste tekstbehandler; og vi kunne lide det.
Fuld biografi Udgivet i Linux og Open Source den 27. december 2021 | Emne: Sikkerhed
Linux er overalt. Det er, hvad alle skyerne, selv Microsoft Azure, kører. Det er det, der får alle 500 af de 500 bedste supercomputere til at fungere. For pokker, selv desktop Linux vokser, hvis man kan tro Pornhub, som hævder, at Linux-brugere voksede med 28%, mens Windows-brugere faldt med 3%.
Open source-software vokser også med stormskridt. Ifølge Gartners 2021 Hype Cycle for Open-Source Software (OSS): “Gennem 2025 vil mere end 70 % af virksomhederne øge deres IT-forbrug på OSS sammenlignet med deres nuværende IT-udgifter. Plus, inden 2025, software som en service ( SaaS) bliver den foretrukne forbrugsmodel for OSS på grund af dets evne til at levere bedre operationel enkelhed, sikkerhed og skalerbarhed.”
Tænker på databaser, oksekødet og kartoflerne i virksomhedssoftware, forudsiger Gartner, at over 70 % af nye interne applikationer vil blive udviklet på en open source-database. Samtidig vil 50 % af eksisterende proprietære relationsdatabaseforekomster være blevet konverteret eller er ved at blive konverteret til open source DBMS'er.
Jeg køber de numre. Jeg har fulgt Linux og open source-software siden dag ét. Overalt, hvor jeg går, og alle, jeg taler med, erkender, at parret kører softwareuniverset.
Men med stor magt følger også et stort ansvar, som Spider-Man ved. Og som mange udviklere for nylig fandt ud af, da adskillige sikkerhedssårbarheder med Apache Java-logging open source-biblioteket log4j2 blev opdaget, kommer der også stor hovedpine.
Log4j2-problemerne er så slemt som muligt. Af National Vulnerability Database (NVD)-skalaen er den vurderet til 10.0 CVSSv3, hvilket er fuldstændig forfærdeligt.
Dets virkelige problem er ikke så meget med selve open source. Der er intet magisk ved open source-metodologi og sikkerhed. Sikkerhedsfejl kan stadig indtaste koden. Linus lov er, at givet nok øjeæbler, er alle insekter overfladiske. Men hvis ikke nok udviklere leder efter, vil sikkerhedssårbarheder stadig gå ubemærket hen. Som det, jeg nu kalder Schneiers lov, “Sikkerhed er en proces, ikke et produkt,” påpeger, at konstant årvågenhed er nødvendig for at sikre al software.
Når det er sagt, er den virkelige smerte-in-the-rump med log4j, hvordan Java skjuler hvilke biblioteker dens kildekode og binære filer bruger i adskillige Java Archive (JAR) variationer. Resultatet? Du bruger muligvis en sårbar version af log4j og ved det ikke, før den er blevet udnyttet.
Som Josh Bressers, Anchores vicepræsident for sikkerhed for nylig forklarede, “En af udfordringerne, log4j-sårbarheden udgør, er faktisk at finde den. Java-applikationer og afhængigheder er normalt i en form for pakkeformat, der gør distributionen og afviklingen virkelig nem, men det kan gør det svært at finde ud af, hvad der er inde i disse softwarepakker.”
Heldigvis er der log4j-scannere, som kan hjælpe dig med at finde defekte log4j-biblioteker i brug. Men de er ikke perfekte.
Bag log4j rod er et andet problem, det er “Hvordan ved du, hvilke open source-komponenter din software bruger?” For eksempel har log4j2 været i brug siden 2014. Du kan ikke forvente, at nogen kan huske, om de brugte den første version i et eller andet program, du stadig bruger i dag.
Svaret er et, som open source-fællesskabet begyndte at tage alvorligt i de senere år: Oprettelsen af Software Bills of Material (SBOM). En SBOM præciserer præcis, hvilke softwarebiblioteker, rutiner og anden kode, der er blevet brugt i ethvert program. Bevæbnet med dette kan du undersøge, hvilke komponentversioner der bruges i dit program.
Som David A. Wheeler, Linux Foundations direktør for Open Source Supply Chain Security, har forklaret, kan du ved at bruge SBOM'er og verificerede reproducerbare builds sikre dig, at du ved, hvad der er hvad i dine programmer. På den måde, hvis der findes et sikkerhedshul i en komponent, kan du simpelthen lappe den i stedet for at søge som en galning efter enhver mulig problemkode, før du kan rette den.
“En reproducerbar build,” forklarer Wheeler i øvrigt, er en “der altid producerer de samme output givet de samme input, så build-resultaterne kan verificeres. En verificeret reproducerbar build er en proces, hvor uafhængige organisationer producerer en build fra kildekode og kontroller, at de byggede resultater kommer fra den påståede kildekode.”
For at gøre dette skal du og dine udviklere spore dine programmer i en SBOM ved hjælp af Linux Foundations Software Package Data Exchange (SPDX) format. For yderligere at sikre, at din kode virkelig er, hvad den hævder at være, skal du notarisere og verificere din SBOM med tjenester såsom Codenotary Community Attestation Service og Tidelift Catalogs.
Alt dette er nemt at sige. Gør det hårdt. I 2022 kommer stort set alle open source-udviklere til at bruge meget tid på at tjekke deres kode for problemer og derefter bygge SPDX-baserede SBOM'er. Brugere, der er bekymrede over katastrofer af typen Solarwind og log4j-sikkerhedsproblemer, vil kræve dette.
Samtidig arbejder Linux-udviklere på yderligere at sikre styresystemet ved at lave Rust Linuxs andet sprog. Hvorfor? For i modsætning til C, Linuxs primære sprog, er Rust meget mere sikkert. Specifikt er Rust meget sikrere end C til at håndtere hukommelsesfejl.
Som Ryan Levick, en primær fortaler for cloududviklere fra Microsoft, forklarede: “Rust er fuldstændig hukommelsessikker.” Det er en kæmpe aftale, eftersom, som Linux-kerneudviklerne Alex Gaynor og Geoffrey Thomas påpegede på Linux Security Summit i 2019, kommer næsten to tredjedele af Linux-kernens sikkerhedshuller fra problemer med hukommelsessikkerhed. Og hvor kommer de fra? Iboende problemer med C og C++.
Nu skal Linux omskrives i Rust. I det mindste ikke i dette årti, tjek med mig igen i 2030'erne, men en masse Linux-drivere og anden kode vil blive skrevet fremadrettet i Rust.
Som Linus Torvalds fortalte mig, mens han “på ingen måde 'skubber' til Rust,” er han “åben over for det i betragtning af de lovede fordele og undgå nogle sikkerhedsfælder. Alligevel konkluderede han: “Jeg ved også, at nogle gange slår løfter ikke ud.”
Vi vil se, hvordan det hele lykkes. Uanset hvordan detaljerne går, er der én ting, jeg ved med sikkerhed. Vi vil se, at sikringskoden bliver topproblem for Linux- og open source-udviklere i 2022. De er begge blevet for vigtige til, at det kan gå nogen anden vej.
Relaterede historier:
2022-teknologi trendgennemgang, del et: Open source, cloud, blockchainKodenotar: Notar og verificer din softwarestyklisteRust tager et stort skridt fremad som Linuxs andet officielle sprog Enterprise Software | Security TV | Data Management | CXO | Datacentre