Cyberbezpieczeństwo open source to tykająca bomba zegarowa

W marcu błąd oprogramowania groził wykolejeniem dużych obszarów sieci. Stwierdzono, że XZ utils , narzędzie do kompresji o otwartym kodzie źródłowym, wbudowane w niezliczone produkty programowe i systemy operacyjne, zostało wyposażone w backdoora.

Backdoor — ukryty punkt wejścia do oprogramowania — umożliwiłby osobie dysponującej wymaganym kodem przejęcie maszyn, na których działa, i wydanie poleceń jako administrator. Gdyby backdoor był szeroko rozpowszechniony, byłaby to potencjalna katastrofa dla milionów ludzi.

Na szczęście, zanim szkodliwa aktualizacja mogła zostać wypuszczona do szerszego obiegu, inżynier oprogramowania z firmy Microsoft zauważył nieprawidłowości w kodzie i zgłosił je. Projekt został następnie przejęty przez odpowiedzialne strony i od tego czasu został naprawiony.

Choć katastrofie udało się ledwo zażegnać, odcinek uwypuklił bieżące zobowiązania w modelu rozwoju oprogramowania typu open source, które są długotrwałe i niełatwe do naprawienia. Odcinek XZ nie jest pierwszym przypadkiem, w którym błąd open source grozi wykolejeniem dużych obszarów sieci. Z pewnością nie będzie to ostatnie. Zrozumienie irytujących dylematów związanych z cyberbezpieczeństwem, jakie stwarza oprogramowanie typu open source, wymaga wycieczki po jego bizantyjskim i niezbyt intuicyjnym ekosystemie. Tutaj, dla niewtajemniczonych, jest nasza próba zorganizowania tej wycieczki.

Sieć działa na FOSS

Obecnie zdecydowana większość baz kodów opiera się na kodzie open source. Szacuje się, że składa się z niego od 70 do 90 procent wszystkich „ stosów ” oprogramowania. Najprawdopodobniej zdecydowana większość aplikacji w Twoim telefonie została z nim zaprojektowana, a jeśli jesteś jedną z 2,5 miliarda ludzi na świecie korzystających z Androida, system operacyjny Twojego urządzenia to zmodyfikowana wersja oprogramowania, która wywodzi się z jądra Linuksa — największego projektu open source na świecie.

Kiedy ludzie mówią o „ łańcuchach dostaw ” oprogramowania — cyfrowym rusztowaniu obsługującym nasze ulubione produkty i usługi internetowe — znaczna część tego kodu składa się z komponentów typu open source. Jego wszechobecność sprawiła, że ​​obserwatorzy nazywają otwarte oprogramowanie „ infrastrukturą krytyczną ” Internetu – proteastyczną substancją, która jest zarówno niezbędna, jak i niezwykle potężna.

Jednak niezależnie od tego, jak ważne jest, oprogramowanie typu open source pozostaje tematem, który nie jest szeroko rozumiany przez większość ludzi spoza branży technologicznej. Większość ludzi nawet o tym nie słyszała.

Dlaczego warto korzystać z otwartego oprogramowania?

Dla niewtajemniczonych krótkie wyjaśnienie może wyglądać mniej więcej tak: W przeciwieństwie do oprogramowania „zamkniętego” lub zastrzeżonego, oprogramowanie bezpłatne i otwarte, w skrócie FOSS, jest publicznie dostępne i może być używane lub modyfikowane przez każdego. Jego użycie zależy od różnych umów licencyjnych i, co jest dość wyjątkowe, komponenty są często utrzymywane przez wolontariuszy — nieopłacanych programistów, którzy spędzają wolny czas na utrzymywaniu aktualności i dobrym stanie oprogramowania.

Projekty open source mogą rozpocząć się praktycznie od wszystkiego. Często są to małe projekty dla cyfrowych majsterkowiczów, którzy po prostu chcą zbudować coś nowego. W końcu niektóre projekty zyskują popularność i prywatne firmy zaczną włączać je do swoich komercyjnych baz kodów. W wielu przypadkach, gdy korporacyjny zespół programistów decyduje się na utworzenie nowej aplikacji, skonstruuje ją przy użyciu szeregu mniejszych, już istniejących komponentów oprogramowania, które składają się z setek, a nawet tysięcy linii kodu. Obecnie większość tych komponentów pochodzi od społeczności open source.

Może być trudno wyobrazić sobie, jak działa ta dziwna relacja pomiędzy oprogramowaniem komercyjnym a ekosystemem open source. Na szczęście kilka lat temu twórca komiksów internetowych Randall Munroe stworzył dobrze znany obecnie mem, który pomaga zwizualizować tę sprzeczną z intuicją dynamikę:

Istnieje wiele powodów, dla których firmy sięgają po oprogramowanie open source w ramach swoich potrzeb rozwojowych. Oprócz tego, że jest bezpłatny, FOSS umożliwia także wydajne i szybkie tworzenie oprogramowania. Jeśli programista nie musi się martwić o podstawowe elementy składowe kodu aplikacji, może skupić się na elementach oprogramowania, które są bardziej rynkowe. W konkurencyjnym środowisku, takim jak Dolina Krzemowa – gdzie szybki czas wprowadzenia produktu na rynek jest kluczową zaletą – oprogramowanie open source jest w dużej mierze koniecznością DevOps.

Ale wraz z szybkością i zwinnością pojawia się wrażliwość. Jeśli FOSS jest wszechobecnym elementem nowoczesnego oprogramowania, istnieją również problemy strukturalne w ekosystemie, które zagrażają ogromnym ilościom oprogramowania. Problemy te mogą dość szybko się nasilić – często z katastrofalnymi skutkami.

Błędy z piekła rodem

Odcinek XZ nie zakończył się katastrofą, ale z łatwością mógł to zrobić. Jednym z przypadków, w którym użytkownicy sieci nie mieli tyle szczęścia, był słynny incydent z „log4shell”. Trzy lata temu, w listopadzie 2021 r., w popularnym wówczas programie open source log4j odkryto lukę w kodzie. Biblioteka rejestrowania . Programy takie jak log4j są regularnie integrowane z aplikacjami, gdzie programiści używają ich do rejestrowania i oceniania wewnętrznych procesów programu. Log4j, utrzymywany przez organizację open source Apache , był szeroko stosowany w momencie odkrycia błędu i został osadzony w milionach aplikacji na całym świecie.

Niestety, błąd log4j – nazwany „ log4shell ” – był dość poważny . Podobnie jak błąd XZ, wymagał on zdalnego wykonania kodu. Oznaczało to, że haker mógł z łatwością wstrzyknąć swój własny „dowolny” kod do programu, którego dotyczy luka, umożliwiając mu przejęcie kontroli nad maszyną, na której działa. Ze względu na popularność log4j zakres błędu był ogromny. Dotknęło to duże, wielomiliardowe firmy. Setki milionów urządzeń było podatnych na ataki. Kilka dni po ujawnieniu luki eksperci oszacowali , że luki te stanowią tykającą bombę zegarową i cyberprzestępcy już próbowali je wykorzystać.

Odkrycie błędu wprawiło korporacyjną Amerykę w pełną panikę i przestraszyło najwyższe szczeble rządu federalnego. Niektóre z największych firm na świecie były zagrożone , co czyniło to kwestią bezpieczeństwa narodowego. Kilka tygodni po odkryciu błędu Anne Neuberger, czołowa doradczyni prezydenta Joe Bidena ds. cyberbezpieczeństwa, zwołała w Białym Domu szczyt poświęcony bezpieczeństwu open source, zapraszając dyrektorów z Microsoft, Meta, Google, Amazon, IBM i innych wielkich nazwisk, a także wpływowe organizacje zajmujące się open source, takie jak Apache, Linux Foundation i Linux Open Source Security Foundation lub OSSF. Spotkanie mniej skupiało się na tym , jak zaradzić tej piekielnej bezbronności, a raczej na zastanawianiu się, jak zapobiec ponownemu wystąpieniu takich rzeczy.

Niedługo po spotkaniu kadra kierownicza Linux Foundation, w tym ówczesny dyrektor generalny OSSF Brian Behlendorf, rozpoczęli formułowanie tak zwanego „planu mobilizacji”, aby lepiej zabezpieczyć cały ekosystem FOSS. W międzyczasie rząd federalny zaczął opracowywać własne strategie dalszej regulacji branży technologicznej. Co najważniejsze, w opublikowanym w zeszłym roku planie cyberbezpieczeństwa prezydenta Bidena starano się nadać priorytet szeregowi nowych zabezpieczeń, aby zapobiec pojawianiu się nowych, wysoce destrukcyjnych błędów.

Jednak niebezpieczeństwa związane z luką XZ pokazują, że FOSS jest nadal środowiskiem, które w najwyższym stopniu jest podatne na błędy, które mogą mieć katastrofalne, ogólnosystemowe konsekwencje dla Internetu. Zrozumienie ryzyka w FOSS nie jest jednak łatwe. Wymaga to odwiedzenia wyjątkowego ekosystemu, w którym powstaje tak duża część światowego oprogramowania.

Zamknięte źródło nie oznacza bezpieczniejszego

Zanim przejdziemy dalej, warto wyjaśnić jedną rzecz: to, że oprogramowanie ma „zamknięte źródło” lub jest zastrzeżone, nie oznacza, że ​​jest bezpieczniejsze. Rzeczywiście, eksperci ds. bezpieczeństwa i zwolennicy FOSS twierdzą, że jest odwrotnie. Powrócimy do tego problemu później, ale na razie zwrócę waszą uwagę na małą firmę o nazwie Microsoft. Mimo że firma ta jest znaczącym gigantem korporacyjnym o zamkniętym kodzie źródłowym, jej baza produktów została zhakowana niezliczoną ilość razy — czasami z katastrofalnym skutkiem. Wiele firm, które zamykają swoje produkty, ma podobne osiągnięcia i, w przeciwieństwie do oprogramowania typu open source, ich problemy związane z bezpieczeństwem są często utrzymywane w tajemnicy, ponieważ nikt poza firmą nie ma dostępu do kodu.

Opiekunowie

Jeśli chcesz porozmawiać o zagrożeniach bezpieczeństwa w oprogramowaniu typu open source, musisz zacząć od rozmowy o ludziach stojących za kodem. W ekosystemie open source osoby te nazywane są „ opiekunami ” i, jak można się spodziewać, są odpowiedzialni za utrzymanie jakości oprogramowania.

Wyjaśnienie roli opiekuna jest nieco skomplikowane. Konserwatorów można trafnie porównać do pracowników budowlanych, którzy w prawdziwym świecie budują nasze drogi i mosty. Albo inżynierowie, którzy je projektują. Lub oba. Krótko mówiąc, opiekun jest opiekunem (i często twórcą) konkretnego projektu open source, ale w wielu przypadkach współpracuje z „współautorami” — użytkownikami oprogramowania, którzy chcą wprowadzić ulepszenia w kodzie.

Opiekunowie hostują swoje projekty open source w publicznych repozytoriach, z których najpopularniejszym jest Github . Repozytoria te zawierają interaktywne mechanizmy, które ostatecznie są kontrolowane przez opiekuna. Na przykład, gdy współautor chce dodać coś do projektu, może przesłać „ prośbę ściągnięcia ” w GitHub, która zawiera nowy kod, który ma nadzieję dodać. Opiekun ma następnie za zadanie podpisać „scalanie”, które zaktualizuje projekt w celu odzwierciedlenia zmian wprowadzonych przez kontrybutora. To dzięki temu wspólnemu procesowi projekty open source stale się rozwijają i przekształcają.

Jako główny kontroler tych żywych, iteracyjnych projektów, praca opiekuna często wymaga ogromnej ilości pracy — od bieżącej korespondencji z użytkownikami i współpracownikami, przez podpisywanie zatwierdzeń kodu, po tworzenie przewodników „ dokumentacji ”, które pokazują, jak wszystko wewnątrz oprogramowanie faktycznie działa. Jednak za całą tę pracę wielu opiekunów nie zarabia szczególnie dobrze. Większość nie jest w ogóle opłacana . Open source ma być darmowe, pamiętasz? W świecie FOSS ciężka praca jest nagradzana niczym więcej niż świadomością, że Twój kod jest dobrze wykorzystywany.

Los opiekuna jest specyficzny i jest w dużym stopniu powiązany ze skomplikowaną historią open source, a także jego niezupełnie prostymi relacjami z korporacjami korzystającymi z jego kodu.

Błyskawiczna historia FOSS

Warto wziąć pod uwagę, że na początku open source nie miało wiele wspólnego z korporacjonizmem i pieniędzmi. W rzeczywistości było zupełnie odwrotnie.

FOSS wyrósł z idealistycznego ruchu hakerskiego z lat 80. XX wieku, zwanego ruchem „wolnego oprogramowania” . Ogólnie rzecz biorąc, ruch ten rozpoczął się od Richarda Stallmana – ekscentrycznego informatyka, który wygląda trochę jak Jerry Garcia i od dawna jest zwolennikiem śmiałej formy cybernetycznego idealizmu. W 1983 roku, pracując w laboratorium sztucznej inteligencji MIT, Stallman założył GNU , repozytorium wolnego oprogramowania. Ideą kolekcji była kontrola użytkownika. Stallman wzbraniał się przed myślą, że prywatne firmy mogłyby przechowywać oprogramowanie za otoczonym murem ogrodem. Uważał, że użytkownicy oprogramowania potrzebują możliwości kontrolowania używanych programów — sprawdzania, jak działają, a także zmieniania ich lub modyfikowania, jeśli chcą. W związku z tym Stallman postulował ideę „wolnego” oprogramowania – słynnie komentując, że miał na myśli wolność „jak wolność słowa, a nie darmowe piwo”. Oznacza to, że Stallman nie jest przeciwny zarabianiu przez programistów, ale ich kod powinien być otwarty i widoczny dla wszystkich w celu przyszłego ulepszenia.

W 1991 roku 21-letni fiński student programowania komputerowego, Linus Torvalds, zapoczątkował kolejną wielką innowację w historii open source. Podobno z nudów Torvalds stworzył nowy system operacyjny i nazwał go swoim imieniem, nazywając go „Linux”. Co najważniejsze, Torvalds stworzył „jądro” Linuksa, istotny komponent każdego systemu operacyjnego, który zarządza interfejsem pomiędzy sprzętem komputera a jego procesami cyfrowymi. Nie było to wtedy jasne, ale Linux stał się największym i najpopularniejszym projektem open source na świecie . Obecnie istnieją setki dystrybucji Linuksa (lub „dystrybucji”) korzystających z jądra stworzonego przez Torvaldsa.

W 1998 roku mała, ale wpływowa grupa społeczności wolnego oprogramowania zdecydowała, że ​​chce zerwać z idealistycznymi korzeniami ruchu i zająć się oprogramowaniem głównego nurtu. W Mountain View w Kalifornii odbył się szczyt , którego uczestnicy starali się omówić sposoby „przebrandowania” wolnego oprogramowania na coś, co „świat korporacji pośpieszyłby kupić” – pisze Eric Raymond, znany programista i jeden z uczestnicy spotkania. „Open source” zostało zaprezentowane jako „termin marketingowy” wymyślony w celu uchwycenia wyobraźni amerykańskich tytanów technologii i odciągnięcia ich od bardziej niejasnej, bardziej komunistycznej terminologii słowa „wolny” – wyjaśnia Raymond. Miała nadzieję, że biznesmeni zapomną o hippisowskich bełkotach Stallmana i skupią się na bardziej pragmatycznie brzmiącym określeniu.

Okazuje się, że jednak to kupili. To była bańka internetowa , Dolina Krzemowa kwitła, a prywatne przedsiębiorstwa były głodne nowych sposobów uwalniania zysków. Dla wielu firm oprogramowanie typu open source – które zapewniało wspólną pulę darmowej siły roboczej i przemysłowy model innowacji – wydawało się dobrym pomysłem . W ten sposób ruch „open source” w dużej mierze oddzielił się od ruchu „wolnego”, stając się własnym organizmem napędzanym przez korporacje, który z czasem zajmował coraz większą przestrzeń w branży oprogramowania. Linux stał się wszechobecny , Torvalds stał się sławny , a Stallman w dużej mierze nadal robił to, co zawsze: opowiadał się za swoimi wolnościami cyfrowymi i dyskredytował korporacyjnych gigantów oprogramowania. Dziś świat opiera się na „open source”, chociaż Stallman nadal kategorycznie odrzuca to określenie . Nadal woli określenie „wolne” oprogramowanie.

Kod do niczego

Oprogramowanie typu open source stało się wszechobecnym zasobem dla korporacji, ale programiści odpowiedzialni za tworzenie i utrzymywanie tego istotnego materiału nie zawsze mogli liczyć na wsparcie – finansowe lub inne – na które zasługują. Rzeczywiście, wiele firm często zadowala się przechwytywaniem kodu i scatem, zasadniczo wykorzystując darmową pracę, nie oddając nic projektom ani ich twórcom.

Od kilku lat firma Tidelift publikuje ankietę opartą na wywiadach z setkami opiekunów open source. Co roku badanie pokazuje mniej więcej to samo: konserwatorzy są przepracowani, niedoceniani i wypaleni. Wyniki ankiety wykazały, że ponad połowa opiekunów oprogramowania open source w ogóle nie otrzymuje wynagrodzenia za swoją pracę. Podobnie ankieta przeprowadzona przez Linux Foundation 2020 wśród autorów wykazała , że ​​ponad połowa respondentów – czyli około 51,65 procent – ​​stwierdziła, że ​​nie otrzymuje wynagrodzenia.

Za incydent w XZ obwinia się wypalenie zawodowe konserwatora . Rzeczywiście, pierwotny opiekun projektu oprogramowania zgłosił, że czuje się „za” w stosunku do niego i ostatecznie przekazał odpowiedzialność użytkownikowi o imieniu „Jia Tan”. Ten użytkownik okazał się osobą, która wprowadziła backdoora do komponentu oprogramowania.

Od dawna wzywano sektor prywatny do większych wysiłków na rzecz wsparcia ekosystemu FOSS, ale w większości te apele pozostawały bez echa. Prawdą jest, że w ostatnich latach duże korporacje technologiczne inwestowały pieniądze w określone sektory ekosystemu open source – ale często tylko tam, gdzie jest to dla nich korzystne.

Dla zdecydowanej większości programistów FOSS utrzymanie projektów nadal wiąże się z niewielkim wynagrodzeniem lub nie wiąże się z żadnym wynagrodzeniem i często jest mniej zabawnym hobby lub prawdziwą pracą niż niewdzięczną krzątaniną – pomyślmy o ekonomii twórców z kodem. Na Reddicie można znaleźć wątek po wątku , w którym programiści omawiają sposoby uruchomienia finansowania FOSS. Niektórzy sugerują zwrócenie się do Liberapay, platformy crowdfundingowej typu open source, znanej z przekazywania pieniędzy programistom borykającym się z problemem braku gotówki. Inni uważają, że Patreon to dobra opcja . Co najmniej jedna osoba zachęca ludzi do skontaktowania się z Gitcoin, startupem Web3, który wykorzystuje dotacje kryptowalutowe do sponsorowania projektów FOSS. Wielu programistów po prostu włącza portale darowizn na swoich stronach projektów w Githubie — z linkami do takich rzeczy jak Stripe, PayPal czy Kup mi kawę. Jak w przypadku większości kreatywnych przedsięwzięć, żebranie o pieniądze okazuje się najpewniejszym sposobem na zarobienie pieniędzy.

Krwawienie z serca

Prawdopodobnie możesz sobie wyobrazić problemy bezpieczeństwa, które mogą wyniknąć z utrzymywania niezwykle popularnego oprogramowania za pośrednictwem wkładów typu OnlyFans. Badania wykazały , że zdecydowana większość aplikacji komercyjnych zawiera komponenty typu open source, które nie są już aktualizowane lub zostały porzucone przez ich opiekunów.

Niebezpieczeństwa związane z budowaniem cyfrowej infrastruktury przedsiębiorstwa w oparciu o zdecentralizowaną, czasami niestabilną siłę roboczą są łatwo widoczne, jeśli znasz historię Heartbleed.

Odkryty w 2014 roku błąd Heartbleed stanowił krytyczną lukę w zabezpieczeniach OpenSSL , protokołu szyfrowania typu open source, który w tamtym czasie był odpowiedzialny za większość programów bezpiecznej komunikacji w Internecie. Używały go duże firmy, takie jak Google, Facebook, Netflix i Yahoo, podobnie jak szeroki asortyment innych aplikacji i usług, od VPN po komunikatory internetowe i platformy e-mail. Naturalnie odkrycie błędu, który pozwolił osobie atakującej nakłonić podatne serwery do przekazania poufnych danych, takich jak nazwy użytkowników i hasła, wywołało prawdziwą panikę w dużej części Internetu.

„Odkryliśmy, że coś, z czego wszyscy korzystali, było wspierane przez zaledwie kilka osób, którym tak naprawdę wcale nie płacono” – powiedział Jon Callas, ekspert w dziedzinie kryptografii i inżynier oprogramowania, wspominając chaos, który wtedy wybuchł . Callas nie pracował w zespole OpenSSL, ale znał ludzi, którzy to robili i pracował wówczas nad podobnym projektem.

Jak wspomina Callas, problem z OpenSSL zdawał się nieuchronnie wracać do opiekunów. Rzeczywiście, okazałoby się, że OpenSSL, odpowiedzialny za zabezpieczanie usług prywatności i bezpieczeństwa dla rzesz największych największych firm, był w rzeczywistości utrzymywany przez mały, 11-osobowy zespół, do którego zaliczał się „podstawowy” zespół składający się z czterech osób i tylko jeden pracownik na pełen etat.

„To prawdziwy problem” – stwierdził Callas, o problemach związanych z konserwacją oprogramowania open source. Callas ma w tym pewne doświadczenie, będąc jednym z kluczowych architektów OpenPGP , otwartego standardu szyfrowania PGP szeroko stosowanego w Internecie. „Ogromnym problemem jest ustalenie, w jaki sposób pakiety oprogramowania — które w zasadzie stanowią infrastrukturę [cyfrową] — są objęte wsparciem i konserwacją”.

Heartbleed ujawnił prawdziwy problem związany z dotychczasowym paradygmatem operacyjnym bezpieczeństwa open source. Przez lata światem FOSS kierowała się doktryna mówiąca, że ​​oprogramowanie typu open source jest bezpieczniejsze niż oprogramowanie komercyjne. Rozumowanie jest takie, że przejrzystość FOSS, z jego kodem otwartym dla całej sieci, umożliwiła lepszy wgląd w jego wady, a tym samym większe możliwości ich naprawienia. Jest to tak zwany argument „więcej oczu” . Tak więc rozumowano, oprogramowanie komercyjne miało tylko jeden zespół programistów, który wypatrywał błędów; open source miał cały Internet.

Argument ten ma elegancką logikę, ale ma też wady. Argument „więcej oczu” sprawdza się w idealnym świecie – takim, w którym projekty FOSS otrzymują wszystko, czego potrzebują. Oczywiście w prawdziwym świecie open source jest tak bezpieczne, jak zasoby i ludzie przydzieleni do jego utrzymania. Najczęściej projekty FOSS mają mniej oczu, niż potrzebują, a nie więcej. A może patrzą na nich niewłaściwe oczy — jak cyberprzestępca.

Nie można zaprzeczyć, że pewna liczba projektów FOSS jest niezwykle bezpieczna. Mówi się , że od 2005 roku nad jądrem Linuksa pracowało około 14 000 różnych autorów. Linux Foundation zatrudnia około 150 osób i osiągnęła w ubiegłym roku szacunkowe przychody na poziomie 262,6 miliona dolarów, z których większość pochodziła z wkładów przedsiębiorstw i osób prywatnych. Pod wieloma względami to właśnie dzięki temu wsparciu i przejrzystości obserwatorzy byli w stanie uchwycić Jia Tan, rzekomego twórcę luki XZ. Jednak problem związany z używaniem Linuksa jako przykładu bezpieczeństwa open source jest dość oczywisty: większość projektów open source nie jest oparta na Linuksie i nie zapewnia wsparcia na poziomie Linuksa.

Kolekcja noży Backstabbbera

Wydarzenie Heartbleed uznano za „ pobudkę ” dla społeczności programistów. Incydent ten po raz pierwszy zasadniczo skierował uwagę amerykańskich korporacji na kwestie bezpieczeństwa związane z oprogramowaniem open source. Zmusiło to także Fundację Linux do utworzenia inicjatywy Core Infrastructure Initiative , która miała na celu identyfikację projektów open source o kluczowym znaczeniu, które wymagały dodatkowego wsparcia (została zastąpiona przez OSSF w październiku 2021 r.).

Jeśli jednak Heartbleed był kanarekiem w cyfrowej kopalni węgla, ostatecznie nie wszyscy go zauważyli. W rzeczywistości krajobraz zagrożeń od 2014 r. stał się jeszcze bardziej złożony, w miarę jak FOSS stał się większą i bardziej integralną częścią sieci. Obecnie problemy nie ograniczają się do okazjonalnych, katastrofalnych błędów. W rzeczywistości są one o wiele bardziej skomplikowane.

We współczesnym świecie oprogramowanie komercyjne jest wszędzie. Nasze życie jest bardziej cyfrowe i połączone niż kiedykolwiek wcześniej, a prawie wszystko, co posiadasz – od odkurzacza, przez sprzęt do ćwiczeń, po szczoteczkę do zębów – ma aplikację. W rezultacie znacznie wzrosła możliwość naruszenia bezpieczeństwa oprogramowania, na którym działają wszystkie te aplikacje. Obecnie stosunkowo powszechne są tak zwane „ataki na łańcuch dostaw” na oprogramowanie . Celem takich ataków są szczególnie słabe komponenty oprogramowania, co czasami pozwala cyberprzestępcom wykorzystać jeden słaby element w celu przejęcia lub uszkodzenia całego produktu lub systemu. Najczęściej komponentami umożliwiającymi początkowy dostęp do łańcuchów dostaw są FOSS . Istnieje tak wiele sposobów włamywania się do komponentów open source w łańcuchach dostaw, że w jednym ze znaczących artykułów z 2020 roku katalog luk został nazwany „kolekcją noży wbijających w plecy” .

Jedną z osób, która dobrze zna ten złożony krajobraz zagrożeń, jest Dan Lorenc. Lorenc, doświadczony specjalista ds. bezpieczeństwa z doświadczeniem w FOSS, spędził prawie dziesięć lat pracując w Google i co najmniej trzy lata pracując nad szczegółami cyberbezpieczeństwa w Google Cloud. Lorenc jest obecnie właścicielem firmy Chainguard zajmującej się bezpieczeństwem łańcucha dostaw, która zajmuje się wieloma tymi samymi problemami, które pojawiły się podczas jego pracy w Google.

„Myślę, że open source stoi przed pewnymi wyjątkowymi wyzwaniami, głównie ze względu na zdecentralizowany charakter [jego rozwoju]. Nie zawsze można ufać każdemu, kto napisze kod” – powiedział Lorenc. „Każdy użytkownik Internetu może przyczynić się do powstania otwartego kodu źródłowego, ale nie każdy w Internecie jest miłą osobą”.

Tak, niefortunna prawda jest taka, że ​​odcinek XZ nie jest pierwszym przypadkiem, w którym opiekun lub współpracownik FOSS wprowadził do projektu złośliwe oprogramowanie. Z raportu z 2020 r. wynika, że ​​chociaż większość błędów w FOSS to po prostu błędy w kodowaniu, około 17 procent – ​​czyli około jednej piątej – to błędy wprowadzone złośliwie, czyli to, co badacze nazywają „bugdoorami”. Jeden z głośnych przykładów miał miejsce w 2018 r., kiedy twórca popularnego programu typu open source o nazwie event-stream był zmęczony utrzymywaniem projektu i zdecydował się przekazać kontrolę innemu programiście – pseudonimowemu użytkownikowi sieci o imieniu „Right9ctrl”. Jedynym problemem było to, że „Right9ctrl” okazał się cyberprzestępcą, który następnie wprowadził do oprogramowania złośliwą aktualizację. Aktualizacja umożliwiła przestępcy włamanie się do portfeli kryptowalut określonej marki i kradzież znajdujących się w nich środków. Szkodliwy kod, pobrany około 8 milionów razy, pozostawał niezauważony przez około dwa miesiące.

Trend sabotowania własnych projektów przez deweloperów FOSS również ma tendencję wzrostową. W październiku 2021 roku opiekun popularnego zestawu bibliotek npm, niejaki Marak Squires, w niewytłumaczalny sposób zniszczył je serią dziwacznych aktualizacji. Aktualizacje spowodowały, że oprogramowanie wyrzucało strumień niespójnego bełkotu, który skutecznie zrujnował projekt, w którym uruchomiono oprogramowanie. Szacuje się , że ten akt cyfrowego samospalenia doprowadził do zniszczenia „tysięcy” projektów oprogramowania, których sukces opierał się na bibliotekach kodowania.

Lorenc mówi również, że na rynku jest zdecydowanie więcej „log4j” — krytycznych projektów, którym po prostu nie poświęca się uwagi i nie poświęca się im tyle uwagi, na ile zasługują. Właściwie tego rodzaju sytuacje pojawiają się „zawsze” – stwierdził.

W przypadkach, gdy takie projekty wybuchają w twarz użytkownikom korporacyjnym, często winę zrzuca się na opiekunów. Ludzie sugerują, że „nie wykonują swojej pracy profesjonalnie lub nie poświęcają jej wystarczająco dużo czasu” – stwierdził Lorenc. „Ale tak naprawdę to skomplikowany problem. Oni [opiekunowie] udostępniają coś za darmo, a potem ludzie zaczną budować na tym gigantyczny element krytycznej infrastruktury produkcyjnej, a później będą narzekać, gdy zostaną znalezione błędy.

Dokonywanie inwentaryzacji

Co więc zrobić? Jak uregulować przestrzeń technologiczną, która ze swej natury jest głęboko zdecentralizowana, nękana anonimowością i strukturalnie odporna na jakąkolwiek ingerencję nadrzędnej władzy?

To pytanie nie dawało spać wielu osobom w nocy. Od czasu porażki log4j w różnych momentach kontaktowałem się z kadrą kierowniczą OpenSSF, spółki zależnej Linuksa zajmującej się bezpieczeństwem, aby omówić postępy w realizacji „planu mobilizacji”, który, jeśli pamiętacie, został opracowany w celu stworzenia nowych zabezpieczeń dla środowiska FOSS po wykryciu błędu log4shell. Plan, który początkowo zaproponowano, zawierał wiele ruchomych części i nie było do końca jasne, które z nich będą miały pierwszeństwo. W 2022 r. rozmawiałem z dyrektorem zarządzającym OpenSSF Brianem Behlendorfem, który powiedział mi, że w planie mobilizacji znajduje się co najmniej kilka propozycji przygotowanych do działania – określił je jako „gotowe z łopatą”. Jedno z najbardziej obiecujących rozwiązań jest również najbardziej oczywiste: zmuszanie firm do inwentaryzacji kodu, którego używają.

Choć może to zabrzmieć dziwnie, wiele firm tak nie robi. OSSF stwierdziło, że firmy często „nie mają spisu wdrażanego oprogramowania i często nie mają danych na temat komponentów nabytego oprogramowania”. Niezbyt atrakcyjne, prawda? To trochę jak firma budowlana budująca drapacz chmur, ale nie mająca pojęcia, z czego zbudowany jest fundament. Czy chciałbyś mieszkać lub pracować w takim budynku?

Plan mobilizacji zakładał powszechne przyjęcie audytów kodu przeprowadzanych przez strony trzecie, znanych w branży jako „zestawienie materiałów oprogramowania” (SBOM). Narzędzia takie zapewniają inwentaryzację konkretnego oprogramowania, zebraną za pomocą algorytmu. Informując użytkownika, co znajduje się w jego własnym programie, SBOM umożliwiają dostawcom oprogramowania sprawdzenie, czy poszczególne komponenty są zagrożone, czy nie.

„Najlepiej spojrzeć na to jak na listę składników umieszczoną na boku opakowania żywności” – powiedział Tim Mackey, który współpracuje z firmą ochroniarską Synopsys, jedną z kilku firm oferujących usługi SBOM. „Zestawienie materiałów oprogramowania zawiera informacje o tym, co się w nim znajduje i skąd pochodzi”.

SBOM istnieją już od lat, ale używano ich głównie do eliminacji zagrożeń prawnych . Ponieważ korzystanie z FOSS opiera się na zawiłej różnorodności umów licencyjnych, firmy często korzystały z SBOM w celu określenia zawartości bazy kodu, a co za tym idzie, jakich umów prawnych należy przestrzegać, aby uniknąć pozwu . Teraz jednak obserwuje się adopcję w celu ograniczenia zupełnie innego rodzaju ryzyka.

W maju 2021 r. administracja Bidena wydała zarządzenie wykonawcze , które między innymi nakazywało wszystkim dostawcom oprogramowania współpracującym z rządem federalnym korzystanie z SBOM. Mackey powiedział, że od czasu realizacji zamówienia w jego branży nastąpił gwałtowny wzrost zainteresowania. „To był niesamowity impuls w biznesie” – powiedział. „Fantastyczny wzrost.”

Ale nawet jeśli SBOM są krokiem we właściwym kierunku, ostatecznie nie stanowią strukturalnego rozwiązania większych problemów związanych z bezpieczeństwem, jakie stwarza FOSS. W rzeczywistości nie robią nic, aby złagodzić ryzyko istniejące w kodzie. „Tak naprawdę to po prostu dokładny spis zasobów” – powiedział były programista Google, Dan Lorenc, zauważając, że „szaleniem” jest to, że większość firm jeszcze tego nie posiada. „One [SBOMy] nie naprawiają błędów, nie zapobiegają błędom, nie powstrzymują atakujących przed manipulowaniem przy czymś. Dają ci po prostu dobry punkt odniesienia”.

Cory Doctorow, wieloletni członek społeczności open source, twierdzi, że obecnie nie ma zachęt dla firm do tworzenia bezpiecznego oprogramowania. Kiedy dochodzi do ataków na łańcuch dostaw, obwinia się opiekunów oprogramowania open source, ale w rzeczywistości winne są firmy korzystające z kodu. „Znajdujemy się w tej strefie, w której nie tylko firmy nie mają żadnego pozytywnego obowiązku upewniania się, że ich oprogramowanie jest dobre i że ich opiekunowie czują się wspierani, ale ochotnicy, którzy ustawiają się w kolejce, aby ostrzec” te firmy i ich klientów „przed defektami” mogą zostać „uciszony przez firmę, jeśli uzna, że ​​szkodzisz jej publicznemu wizerunkowi”. Doctorow twierdzi, że nierzadko firmy technologiczne pozywają badaczy bezpieczeństwa, którzy próbują ujawnić błędy w ich produktach.

Całkowity brak działań ze strony firm pozostawia dużą część ciężkiej pracy związanej z bezpieczeństwem oprogramowania indywidualnym opiekunom i organizacjom open source, takim jak Linux Foundation. Trzeba przyznać, że organizacje te ciężko pracowały, aby znaleźć nowe rozwiązania problemów związanych z bezpieczeństwem stwarzanych przez FOSS. Oprócz zachęcania do przyjęcia SBOM, OpenSSF w ciągu ostatnich kilku lat podjął szereg innych inicjatyw związanych z bezpieczeństwem. Programy te obejmują tworzenie bezpłatnych aplikacji zabezpieczających, takich jak GUAC — bezpłatny mechanizm śledzenia oprogramowania, który pozwala programistom wyszukiwać problematyczne elementy w kodzie — oraz Sigstore — podpis kryptograficzny służący do weryfikowania ważności oprogramowania dewelopera.

Jeśli wysiłki te brzmią obiecująco, należy zauważyć, że mają one miejsce w kontekście rosnącej liczby ataków na łańcuch dostaw , ciągłego wypalenia się opiekunów i ogólnego poczucia, że ​​stan bezpieczeństwa środowiska open source nie zmienił się zbytnio od czasów log4j . Niektórzy argumentowali, że Internet nie jest w stanie zabezpieczyć niczego poza gruntowną przebudową całego systemu. Matthew Hodgson, współzałożyciel szyfrowanego protokołu Matrix, niedawno argumentował , że FOSS powinna być usługą finansowaną ze środków publicznych, która – podobnie jak prawdziwa fizyczna infrastruktura Ameryki – otrzymuje ciągłe fundusze i wsparcie federalne.

Oczywiście prawdopodobieństwo, że tak drastyczna transformacja faktycznie nastąpi, wydaje się marginalne, co stawia przed twórcami ekosystemu open source syzyfowe zadanie. Latem ubiegłego roku Brian Behlendorf przeszedł na inne stanowisko w Linux Foundation, przekazując pałeczkę bezpieczeństwa byłemu inżynierowi Google Cloud Omkharowi Arasaratnamowi, który obecnie pełni funkcję dyrektora generalnego OpenSSF. Arasaratnam opisuje swoją pracę jako „zabezpieczanie Internetu” i, jak przyznaje, jest to „niezwykle trudne”. Lepszym deskryptorem mogłoby być „niemożliwe”. Mimo to przyznaje, że choć nie ma złotego środka, nie może powstrzymać się od nadziei, bo stawka jest wysoka. „Jeśli dobrze to zrobimy, pomożemy 8 miliardom ludzi” – mówi.