Nem múlt el hatástalanul az idei év IT-biztonsági frissítéseit meghatározó Log4J-sérülékenység körüli médiafigyelem. A kereskedelmi cégek rájöttek, hogy a nyílt forráskódú termékek IT-biztonságának megerősítéséhez iparági összefogásra és konkrét cselekedetekre van szükség, mert csak így lehet az open source termékekbe vetett bizalmat helyreállítani.
◼︎ A jó hírnevet elveszíteni könnyű, visszaszerezni szinte lehetetlen
A Log4J egy kicsinyke, ámde annál fontosabb összetevője rengeteg, nyílt forráskódon alapuló szoftvernek, a Java-programozók 2001 óta használják. A modul lényegében egy naplózó megoldás, amely figyeli és rögzíti a fejlesztett szoftver működését, megbízhatóan, kipróbáltan működött évtizedeken keresztül. Bármelyik fejlesztő egyszerűen beépíthette az összetevőt saját megoldásába. Azonban 2021 decemberében kiderült, hogy a népszerű összetevő sérülékenysége gyakorlatilag egy nyitott hátsó ajtó a rossz szándékú támadók előtt.
A komponenst rengeteg kereskedelmi megoldás fejlesztésénél használták fel. Az év elején sok vállalat küzdött azzal, hogy átvizsgálta saját szoftvereit: érintettek-e a hibában. Az érintett, nagy teherbírású és forgalmú vállalati rendszerek esetében maga a frissítés ütemezése sem volt triviális. A frissített komponens beépítése után a fejlesztőknek még tesztelniük is kellett a kapcsolódási pontokat, a szoftver működését, így 1-2 hét is eltelt, mire a patchelés végigfutott.
A Fehér Ház döntött
A nagy riadalom a politikusokat és cégvezetőket sem hagyta tétlenül: az Amerikai Egyesült Államokban a szoftverellátási lánc biztonságát fenyegető sérülékenység miatt egészen az amerikai elnök hivataláig jutottak a technológiai vállalatok képviselői. Egy január eleji találkozón a technológiai cégek képviselői szinte azonnal egy 30 millió dolláros alapot hoztak létre a nyílt forráskódú szoftver-ökoszisztéma biztonságának javítása céljából.
Az Amazon, Google, Intel, Ericsson és Microsoft képviselői – és még sokan mások – voltak jelen az Open Source Security Foundation és a Linux Foundation által kezdeményezett fehér házi megbeszélésen, ahol például elhatározták, hogy támogatják a biztonságos nyílt forráskód gyártását, hatékonyabbá teszik a sérülékenységek észlelését és javítását és csökkentik a hibák javítására szükséges időt. A nagyok elképzelése szerint az open source közösség számára biztonsági oktatásokat tartanának, illetve évente egy harmadik technológiai fél átvizsgálná a 200 legkritikusabbnak tartott nyílt forrású kódkomponenst.
Szoftverek komponensjegyzéke
Talán az egyik legfontosabb döntés, amely ezen a találkozón született, hogy a nyílt forráskódú szoftverek esetében is használják a programozók az úgynevezett software bill of materials (SBOM-ot) vagyis a szoftverkomponensek jegyzékét. Az SBOM gyakorlatilag a szoftver fejlesztéséhez felhasznált összetevőket sorolná fel, ami nagyban megkönnyíti az adott összetevők azonosítását, így a sérülékenységek javítása is felgyorsulna.
A technológiai óriások közül a Microsoft idén július közepén a saját, szoftverkomponens-jegyzéket generáló eszközét, a Salust elérhetővé tette a nyíl forráskóddal dolgozó közösség számára. Az eszköz Windows, Linux és Mac platformon is működik, segítségével a szabványoknak megfelelő jegyzéket tudnak készíteni a szoftverfejlesztők. Ezen túlmenően az open source komponensek megosztására szolgáló GitHub (amely 2018 óta a Microsoft tulajdonában van) a nyáron jelentette be, hogy támogatja a nyílt szoftverkomponensek aláírását. Ez a gyakorlatban azt jelentené, hogy a Sigstore kódaláíró platform segítségével tanúsított komponensek valóban azt tartalmaznák, amit mondanak magukról, így a fejlesztők az eredetit tölthetik le és építhetik be projektjeikbe.
A Linux Foundation (amely a napokban nyitotta meg európai irodáját) a redmondi óriástól függetlenül, de mindenképp erősítve annak nemes gesztusát egy sor iparági kutatást, oktatás és eszközöket biztosított, melyeknek célja a szoftveres anyagjegyzék felhasználásának gyorsítása a biztonságos szoftverfejlesztés területén.
Hibavadász program nyílt forráskódra
A Google augusztusban jelentette be, hogy egy új hibavadász-programot indít, melynek célja az általa valamilyen módon támogatott vagy kedvelt open source fejlesztéseinek tüzetes átvizsgálása IT biztonsági szempontból. A keresőóriás 100–31337 dollár közötti díjakat kínál azoknak, akik a szoftveres ellátási lánc biztonságát javítani szeretnék a biztonsági hibák felfedezésével. (A maximális összeg azért ilyen furcsa, mert ezek a számok kis fantáziával ELEET-nek, azaz elite-nek is olvashatók az internetes szlengben – vicces kedvűek a Google-nél.)
A program neve Open Source Software Vulneralbility Rewards Program (OSS VRP), és az első olyan hibavadász programok közé tartozik, amelyek a nyílt forráskódú fejlesztésekben felfedezett hibákért fizetnek. A Google olyan nagy open source programokat visz, mint az Angular, Bazel, Golang, Protocol Buffers és Fuchsia, ezek mind-mind gyakran használt fejlesztői eszközök. A program célja viszont nemcsak a Google termékekre terjed ki, hanem szinte az egész open source szoftverhalmazra ráhúzható: amelyek fenn vannak a GitHubon vagy amelyeket a Google saját maga is használ termékei fejlesztésében.
A nyáron bejelentett OSS VRP mellett az Open Source Maintenance Crew megalkotásával is kiálltak a nyílt forráskódú fejlesztők mellett. Ebben a projektben a Google egy csoportnyi dedikált szakembert fizet azért, hogy a kritikus nyílt forráskódú projektek megfelelően karban legyenek tartva. A nyílt forráskódú közösség önkéntes fejlesztőinek ugyanis gyakran nincs elegendő idejük arra, hogy az open source-problémákkal foglalkozzanak, mert ezekkel a projektekkel nem munkaidőben, hanem gyakran azon kívül foglalkoznak.
Az év elején megrendülni látszott a bizalom, amelyet fejlesztők milliói és a felhasználók milliárdjai vetettek a nyílt forráskódú megoldásokba. Az iparági szereplők összefogása azonban megmutatta, hogy érdemes a profitért dolgozó cégeknek is foglalkozniuk az open source biztonságával. Hiszen a nyílt forráskódú megoldások szorosan beépültek a kereskedelmi megoldásokba, nélkülük még drágább lett volna a kifejlesztésük.
