Czy w open source można ukryć backdoora

Klient zapytał mnie, całkiem rozsądnie, skąd ma wiedzieć, że serwer, który mu właśnie postawiłem, nie wysyła jego plików gdzieś dalej. To jest właściwe pytanie do dostawcy, a uczciwa odpowiedź nie brzmi „niech mi pan zaufa" — jest opisem tego, co może sprawdzić, a czego nie.

To, co mu powiedziałem, jest tematem tego tekstu i jest węższe niż typowe twierdzenie o open source. „W otwartym kodzie nie da się ukryć backdoora" nie jest prawdą. To, co jest prawdą, jest bardziej konkretne i bardziej użyteczne.

Dwa różne pytania o zaufanie

Instalując zamknięte oprogramowanie, odpowiadasz na jedno pytanie: czy ufam firmie, która to zrobiła? Nie ma drugiej opcji, bo nie ma czego zbadać. Cała relacja opiera się na reputacji, umowach i presji regulacyjnej — które są realnymi rzeczami i w większości działają, a jednocześnie są całkowicie zewnętrzne wobec samego oprogramowania.

Przy otwartym kodzie dostępne jest drugie pytanie: czy ktokolwiek spoza dostawcy ma możliwość sprawdzenia? Na to pytanie można odpowiedzieć „tak" nawet wtedy, gdy nikt faktycznie nie patrzył, a różnica między „nikt nie patrzył" a „nikt nie mógł patrzeć" jest całością tego, co kupuje otwartość.

Chcę powiedzieć to tak wprost, jak umiem, bo przesadzona wersja tego argumentu robi realną szkodę. Otwarty kod nie jest automatycznie zbadany. Większość z niego nigdy nie zostaje przeczytana przez nikogo spoza projektu. Otwartość zmienia strukturę sytuacji: liczba możliwych audytorów rośnie z jednego do nieograniczonej, a koszt ukrycia czegoś rośnie z zera do trwałego ryzyka wykrycia.

Co pokazuje faktyczny zapis

W 2024 roku ktoś poświęcił mniej więcej dwa lata na zbudowanie zaufania w małej, szeroko używanej bibliotece kompresji, został jej współopiekunem i wprowadził backdoora, który dałby zdalny dostęp do ogromnej liczby serwerów. Został złapany na kilka dni przed dotarciem do systemów, z których korzysta większość ludzi — przez jednego inżyniera, który zauważył, że logowanie trwa o ułamek sekundy dłużej, niż powinno, i nie odpuścił.

Tej historii używają jako dowodu obie strony, co jest sygnałem, że czyta się ją niestarannie. Weźmy najpierw niewygodną połowę: zdeterminowany, cierpliwy, dobrze zaopatrzony napastnik wprowadził backdoora do open source, przez proces ludzki, a nie techniczny, a przegląd społeczności tego nie wyłapał. Kto twierdzi, że to się nie może zdarzyć, został zdementowany przez fakty.

Teraz druga połowa, ta, która mnie przekonała. Został znaleziony. Przez osobę z zewnątrz, bez niczyjego pozwolenia, bo mogła przeczytać kod i przeprowadzić eksperymenty. Atak zrekonstruowano publicznie w ciągu kilku dni, zidentyfikowano każdy dotknięty system, a poprawka rozeszła się globalnie w niecały tydzień. Zapytaj, jak wyglądałaby równoważna sekwencja w zamkniętym oprogramowaniu, a odpowiedź jest niewygodna: ten sam backdoor, wprowadzony przez pracownika, zostałby znaleziony przez wewnętrzny przegląd dostawcy albo nie znaleziony wcale, a ujawniony w terminie wybranym przez dostawcę.

Uczciwe ograniczenia

Trzy i mają znaczenie dla każdego, kto podejmuje decyzję, a nie prowadzi spór.

Przeczytanie źródła mówi Ci o źródle, a nie o programie działającym na Twojej maszynie. Jeśli nie skompilowałeś go sam, ufasz temu, kto go zbudował i spakował. Ta luka jest realna i jest zamykana przez powtarzalne budowanie — sposób weryfikacji, że dane źródło produkuje dokładnie ten plik, który dostałeś — ale nie wszędzie jest już zamknięta.

Uwaga nie jest rozłożona równomiernie. Szeroko używane projekty z korporacyjnymi użytkownikami dostają poważną kontrolę. Mała biblioteka trzy poziomy niżej, utrzymywana przez jedną osobę po godzinach, nie dostaje prawie żadnej — i dokładnie tam poszedł atak z 2024 roku, bo napastnik rozumiał ten rozkład lepiej niż społeczność.

I otwartość nie mówi nic o kompetencji. Kod, który każdy może przeczytać, wciąż może być źle napisany i bywał, spektakularnie i na skalę. Przejrzystość jest właściwością procesu, a nie gwarancją wyniku.

Co powiedziałem klientowi

Nie to, że jego serwer nie może zostać skompromitowany. To byłoby kłamstwo i słusznie by mi nie uwierzył.

Powiedziałem mu, że nie musi wierzyć mi na słowo co do tego, czy to wysyła gdzieś jego pliki, bo może popatrzeć. Skierować sieć na serwer DNS, który kontroluje, i zobaczyć, o co maszyna pyta. Ta kontrola nie wymaga zaufania do mnie, niczyjego pozwolenia ani umiejętności czytania kodu. Zajmuje wieczór i odpowiada na pytanie, które faktycznie zadał.

To jest ta wersja argumentu, której jestem gotów bronić. Nie zero backdoorów — tego nikt nie może obiecać. System, w którym osoba, która kupiła rzecz, może niezależnie zweryfikować twierdzenie, a dostawca o tym wie. Wolę sprzedawać na takich warunkach niż na takich, gdzie jedyną opcją mojego klienta jest uwierzyć mi.