Kwestia, czy oprogramowanie open source (OSS) jest odpowiednie w systemach obronnych, została zasadniczo rozstrzygnięta w latach 2000. i 2010.: odpowiedź brzmi tak, przy odpowiednim zarządzaniu. Memorandum Departamentu Obrony USA z 2009 roku w sprawie oprogramowania open source było jedną z pierwszych formalnych deklaracji, że OSS musi być oceniany według tych samych kryteriów co oprogramowanie własnościowe. To liberalne, ale zarządzane stanowisko jest teraz faktycznie powszechne wśród ram zamówień obronnych w demokratycznych krajach.

Obecnym wyzwaniem nie jest to, czy używać OSS, ale jak zarządzać nim rygorystycznie. Incydent z backdoorem XZ Utils z 2024 roku, w którym złośliwy aktor spędził dwa lata budując wiarygodność w projekcie open source przed wstawieniem wyrafinowanego backdoora, pokazał, że ryzyka łańcucha dostaw OSS nie są teoretyczne.

Obecne liberalno-zarządzane stanowisko wobec OSS

Obecne stanowisko DoD USA wobec OSS jest ujęte w kilku dokumentach politycznych. Spójny wątek: OSS nie jest ze swojej natury bardziej ani mniej bezpieczne niż oprogramowanie własnościowe — bezpieczeństwo zależy od konkretnego komponentu, praktyk jego społeczności deweloperskiej i zarządzania stosowanego przez organizację konsumującą. Programy DoD mogą generalnie używać OSS pod warunkiem: przeglądu licencji, oceny podatności i ciągłego monitorowania nowych podatności.

Ryzyka łańcucha dostaw: typosquatting, złośliwe aktualizacje i porzucone biblioteki

Typosquatting. Atakujący rejestrują nazwy pakietów zbliżone do popularnych legalnych pakietów. Deweloper, który pomyli się przy wpisywaniu nazwy pakietu, instaluje złośliwy kod zamiast zamierzonej biblioteki. Łagodzenie wymaga weryfikacji nazwy pakietu w momencie instalacji i plików blokowania zależności.

Złośliwe aktualizacje. Legalny, szeroko stosowany pakiet może stać się nośnikiem złośliwego oprogramowania, jeśli jego opiekunowie zostaną skompromitowani lub zastąpieni przez wrogich aktorów. Łagodzenie wymaga przypinania konkretnych wersji zamiast automatycznego przyjmowania aktualizacji do najnowszej wersji i monitorowania anomalnych zmian zachowania pakietów między wersjami.

Porzucone biblioteki. Projekty open source są często utrzymywane przez indywidualnych wolontariuszy lub małe grupy. Gdy opiekunowie zaprzestają aktywnego rozwoju, projekt może być nadal używany przez oprogramowanie downstream, gromadząc niezałatane podatności. Łagodzenie wymaga śledzenia statusu utrzymania zależności i posiadania polityki zastępowania lub forkowania niezarządzanych komponentów.

Zgodność licencji. Licencje open source nakładają zobowiązania na konsumentów. Licencje copyleft (GPL, AGPL) mogą wymagać ujawnienia kodu źródłowego pochodnego — stwarzając ryzyko prawne dla programów obronnych, które nie mogą ujawniać kodu źródłowego ze względu na klasyfikację lub względy konkurencyjne.

Proces zatwierdzania OSS: przegląd licencji, skanowanie podatności i proweniencja

Przegląd licencji określa, czy licencja komponentu jest zgodna z planowanym użyciem programu. Programy używające komponentów z niezgodnymi licencjami odkrywają ten problem podczas dostawy kontraktowej lub przeglądu prawnego.

Skanowanie podatności ocenia konkretną wersję komponentu rozważanego do włączenia w odniesieniu do znanych baz podatności. Ocena powinna obejmować nie tylko sam komponent, ale jego zależności tranzytywne. Skanowanie podatności w momencie włączenia jest konieczne, ale niewystarczające; musi być powtarzane ciągle w miarę ujawniania nowych podatności.

Ocena proweniencji ocenia wiarygodność procesu wytwarzania i dystrybucji komponentu: tożsamość i doświadczenie opiekunów; czy projekt ma proces ujawniania podatności bezpieczeństwa; czy wydania są podpisane; czy praktyki wytwórcze projektu zapewniają rozsądną pewność celowej jakości.

Kluczowe rozróżnienie: Skanowanie podatności identyfikuje znane podatności. Nie zapewnia ochrony przed nieznanymi podatnościami ani celowymi backdoorami. Ocena proweniencji i szersza pozycja bezpieczeństwa łańcucha dostaw projektu adresują przestrzeń ryzyka, której skanowanie podatności nie może objąć.

SBOM jako narzędzie zarządzania zależnościami OSS

Software Bill of Materials (SBOM) to formalny, maszynowo czytelny inwentarz wszystkich komponentów oprogramowania w systemie — w tym bibliotek open source, komercyjnych gotowych komponentów i wewnętrznie opracowanych modułów — wraz z ich wersjami, licencjami i relacjami zależności. SBOM jest coraz częściej wymagany dla oprogramowania obronnego.

Dla zarządzania OSS SBOM zapewnia dwie możliwości trudne do osiągnięcia w skali. Po pierwsze, umożliwia automatyczną korelację podatności: gdy ujawniana jest nowa podatność (np. publikowane jest CVE dla konkretnej wersji OpenSSL), może być automatycznie skorelowana z SBOM, aby zidentyfikować wszystkie programy zawierające zagrożoną wersję. Po drugie, SBOM umożliwia monitorowanie zgodności licencji w całym drzewie zależności, w tym zależnościach tranzytywnych.

Skuteczne programy SBOM integrują generowanie SBOM w potok CI/CD, tak aby SBOM był zawsze aktualny względem faktycznie wdrożonego kodu. Standardy formatu SBOM (CycloneDX, SPDX) są dojrzałe i mają szerokie wsparcie narzędziowe.