Bezpieczeństwo łańcucha dostaw oprogramowania obronnego: SLSA, proweniencja, podpisywanie

Wdrożony obronny plik binarny to koniec długiego łańcucha zaufania. Zaczął się jako kod źródłowy napisany przez dewelopera, przeszedł przez dziesiątki zależności open source, został skompilowany na serwerze kompilacji, spakowany, podpisany i promowany do rejestru wydań, zanim w ogóle dotarł do sieci operacyjnej. Każde ogniwo tego łańcucha jest celem. Przeciwnicy państwowi wielokrotnie udowodnili, że najtańszą drogą do utwardzonej sieci obronnej nie są drzwi frontowe – jest nią system kompilacji lub zaufana zależność, skompromitowane u źródła, tak aby złośliwy kod został dostarczony, podpisany i pobłogosławiony przez własny potok ofiary. Bezpieczeństwo łańcucha dostaw oprogramowania to dyscyplina czynienia każdego ogniwa tego łańcucha weryfikowalnym, tak aby wdrożony artefakt można było kryptograficznie prześledzić wstecz do zrecenzowanego źródła poprzez kompilację odporną na manipulacje.

Model zagrożeń obronnego łańcucha dostaw

Komercyjne bezpieczeństwo łańcucha dostaw i obronne bezpieczeństwo łańcucha dostaw dzielą to samo słownictwo, ale innego przeciwnika. Zespół komercyjny martwi się o podatną zależność lub przypadkowy wyciek sekretu. Zespół obronny musi zakładać dobrze zasobowego aktora, który spędzi miesiące na wstępnym pozycjonowaniu implantu: zatruwając popularny pakiet open source, kompromitując runner kompilacji lub podstawiając zmanipulowany kompilator. Włamanie do SolarWinds – gdzie implant w systemie kompilacji wstrzyknął tylne wejście do legalnie podpisanej aktualizacji produktu – jest kanonicznym przykładem i przekształciło sposób, w jaki obronne zamówienia traktują pochodzenie oprogramowania.

Powierzchnia zagrożeń dzieli się na cztery strefy. Strefa źródła obejmuje system kontroli wersji i osoby z dostępem do commitów. Strefa zależności obejmuje każdy pakiet firm trzecich wciągnięty do kompilacji, bezpośredni i tranzytywny. Strefa kompilacji obejmuje usługę kompilacji, jej runnery i łańcuch narzędziowy. Strefa dystrybucji obejmuje podpisywanie, rejestr wydań i wdrażanie. Obronny framework kontroli łańcucha dostaw musi zaadresować wszystkie cztery – utwardzanie jednej przy pozostawieniu otwartej innej po prostu przesuwa punkt wejścia przeciwnika.

To, co czyni to trudniejszym dla obronności niż dla oprogramowania komercyjnego, to model konsekwencji. Skompromitowaną komercyjną aktualizację SaaS można wycofać; skompromitowane wgranie firmware'u na wdrożonym radiu lub ładunku walki elektronicznej może być nieosiągalne, trwałe i operacyjnie katastrofalne. Koszt pojedynczego zmanipulowanego artefaktu jest asymetryczny, dlatego framework musi być prewencyjny, a nie reaktywny – celem jest sprawienie, by złośliwy artefakt w ogóle nie mógł przejść przez potok, a nie wykrycie go po wdrożeniu. Poniższe mechanizmy kontroli są ułożone od źródła do wdrożenia właśnie po to, by każda strefa była zamknięta, zanim następna odziedziczy jej wyniki.

SLSA: model dojrzałości integralności kompilacji

SLSA – Supply-chain Levels for Software Artifacts – jest najszerzej przyjętym frameworkiem do rozumowania o integralności kompilacji. Jest celowo przyrostowy, definiując progresywne poziomy, tak aby organizacja mogła zmierzyć, gdzie się znajduje i jaka jest następna konkretna poprawa.

Poziom 1 wymaga jedynie, aby proces kompilacji generował proweniencję: opis tego, jak powstał artefakt. To samo w sobie wyłapuje błędy i zapewnia punkt odniesienia do analizy, ale proweniencja nie jest jeszcze chroniona przed manipulacją.

Poziom 2 wymaga hostowanej usługi kompilacji, która generuje i podpisuje proweniencję. Ponieważ atestację tworzy usługa, a nie stacja robocza dewelopera, manipulacja przez skompromitowaną pojedynczą maszynę staje się wykrywalna.

Poziom 3 utwardza samą platformę kompilacji: proweniencja staje się niemożliwa do podrobienia, a kompilacje przebiegają w izolowanych, efemerycznych środowiskach, które nie przenoszą stanu między uruchomieniami. To poziom, na którym skompromitowana zależność lub złośliwy skrypt kompilacji nie może już po cichu przepisać tego, co raportuje proweniencja. Dla oprogramowania misyjnego SLSA Poziom 3 powinien być traktowany jako punkt odniesienia, a nie aspiracja.

Postawa o najwyższym poziomie zaufania – historycznie opisywana jako Poziom 4, a obecnie wyrażana poprzez dodatkowe wymagania ścieżek – dodaje recenzję każdej zmiany przez dwie osoby oraz hermetyczne, odtwarzalne kompilacje. Odtwarzalna kompilacja pozwala niezależnej stronie ponownie zbudować to samo źródło i potwierdzić, bit po bicie, że otrzymuje ten sam artefakt. Dla komponentów powiązanych z uzbrojeniem lub kryptografią odtwarzalność jest najsilniejszą dostępną obroną przed zmanipulowanym łańcuchem narzędziowym.

Proweniencja kompilacji: jak powstał artefakt

Proweniencja jest sercem zapewnienia łańcucha dostaw i jest często mylona z podpisywaniem. Podpis na pliku binarnym dowodzi, kto go wydał i że nie zmienił się od momentu złożenia podpisu. Nie mówi nic o tym, czy kompilacja, która wyprodukowała plik binarny, była godna zaufania. Jeśli przeciwnik skompromituje runner kompilacji, może wyprodukować złośliwy artefakt, który następnie zostaje podpisany całkowicie legalnie – podpis jest ważny, artefakt jest zatruty.

Proweniencja zamyka tę lukę. Atestacja proweniencji to podpisany, czytelny maszynowo zapis opisujący commit źródłowy, tożsamość budowniczego, parametry kompilacji oraz skróty kryptograficzne każdego wejścia i wyjścia. Szeroko stosowanym formatem jest atestacja in-toto, która ujmuje to jako ustrukturyzowane oświadczenie, które podpisuje platforma kompilacji – a nie deweloper. Gdy weryfikator później sprawdza artefakt, potwierdza nie tylko podpis, ale i to, że proweniencja wskazuje oczekiwane repozytorium źródłowe, oczekiwanego budowniczego i commit, który przeszedł recenzję.

Co sprawdza weryfikator

Kontrola proweniencji w czasie wdrożenia odpowiada na precyzyjne pytanie: czy ten dokładny artefakt został zbudowany ze źródła i procesu, których oczekujemy? Weryfikator porównuje skrót artefaktu ze skrótem zapisanym w proweniencji, potwierdza, że proweniencja została podpisana kluczem zaufanej platformy kompilacji, i stwierdza, że tożsamość budowniczego oraz URI źródła pasują do listy dozwolonych. Niezgodność – artefakt, którego proweniencja wskazuje nieznanego budowniczego, lub którego skrót się nie zgadza – jest odrzucana, zanim dotrze do środowiska operacyjnego. To jest mechanizm kontroli, który oznaczyłby podstawienie w stylu SolarWinds.

Proweniencja umożliwia także reagowanie na incydenty, które w innym przypadku byłoby niemożliwe. Gdy ujawniona zostaje nowa podatność w narzędziu kompilacji lub zależności, organizacja z kompletną proweniencją może dokładnie zapytać, które wdrożone artefakty zostały wyprodukowane z dotkniętym komponentem, przez którego budowniczego i z którego commitu – zamieniając gorączkowe szacowanie w precyzyjną odpowiedź o promieniu rażenia. Proweniencja zachowana na operacyjny czas życia artefaktu nie jest zatem tylko bramką przedwdrożeniową, ale aktywem audytowym, który opłaca się przez lata po kompilacji.

Podpisywanie artefaktów w obronnych potokach

Podpisywanie pozostaje niezbędne; po prostu nie jest samo w sobie wystarczające. Nowoczesną praktyką jest podpisywanie bezkluczowe oparte o dziennik przejrzystości: efemeryczny klucz jest wydawany względem zweryfikowanej tożsamości obciążenia, używany do podpisania artefaktu i jego atestacji, a zdarzenie podpisania jest zapisywane w tylko-dołączalnym, publicznym lub prywatnym dzienniku przejrzystości. Usuwa to obciążenie operacyjne i ryzyko długowiecznych kluczy podpisujących rezydujących na serwerach kompilacji.

Dla komponentów o najwyższym poziomie zaufania – modułów kryptograficznych, bootloaderów, wszystkiego powiązanego ze sprzętowym korzeniem zaufania – programy obronne używają kluczy sprzętowych przechowywanych w sprzętowym module bezpieczeństwa (HSM). Klucz prywatny nigdy nie opuszcza HSM; operacje podpisywania są wykonywane wewnątrz niego. Łączy się to naturalnie z bezpiecznym rozruchem, gdzie firmware urządzenia weryfikuje podpis każdego etapu przed jego wykonaniem, rozszerzając łańcuch zaufania łańcucha dostaw aż do krzemu.

Weryfikacja zależności i SBOM

Większość kodu w każdej nowoczesnej aplikacji obronnej nie jest napisana przez program – jest wciągana jako zależności open source. Weryfikacja tych zależności jest więc mechanizmem kontroli o najwyższej dźwigni w całym łańcuchu. Kilka praktyk składa się tutaj na całość.

Przypinanie i hashowanie. Każda zależność jest przypięta do konkretnej wersji i skrótu kryptograficznego, tak aby rozwiązane drzewo zależności było deterministyczne. Kompilacja nie może po cichu zdryfować na nową, złośliwą wersję pakietu, ponieważ skrót przestałby pasować.

Lustrzane kopiowanie wewnętrzne. Zatwierdzone pakiety są kopiowane lustrzanie do wewnętrznego rejestru, a kompilacje pobierają wyłącznie z tego lustra – nigdy bezpośrednio z publicznego rejestru w czasie kompilacji. Daje to programowi kontrolowany punkt weryfikacji i przerywa zależność kompilacji od dostępności internetu, co jest obowiązkowe dla środowisk odseparowanych (air-gapped) i niejawnych.

Skanowanie podatności. Każda zależność jest skanowana względem danych o podatnościach takich jak baza doradcza OSV, a wyniki bramkują promocję. Wynikiem wyliczenia każdego tranzytywnego komponentu jest zestawienie komponentów oprogramowania (software bill of materials). W kwestii wymagań napędzanych zamówieniami, które są obecnie przypisane do tego artefaktu, zobacz naszą analizę zestawienia komponentów oprogramowania (SBOM) dla obronności. SBOM jest generowany w standardowym formacie – CycloneDX lub SPDX – i dołączany do artefaktu jako podpisana atestacja, tak aby podróżował razem z plikiem binarnym.

Egzekwowanie polityki: bramka dopuszczenia

Żaden z tych mechanizmów kontroli nie ma znaczenia, jeśli nie blokuje wdrożenia niezgodnego artefaktu. Punktem egzekwowania jest bramka dopuszczenia – moment bezpośrednio poprzedzający promowanie artefaktu do rejestru wydań lub wdrożenie go w środowisku operacyjnym. Na tej bramce silnik polityk wykonuje zestaw obowiązkowych kontroli: weryfikuje podpis artefaktu, waliduje proweniencję względem oczekiwanych tożsamości źródła i budowniczego, sprawdza SBOM względem danych o podatnościach i listy zabronionych komponentów oraz potwierdza, że zmiana przeszła wymaganą recenzję dwóch osób.

Krytyczną zasadą projektową jest to, że polityka musi blokować, a nie jedynie oznaczać. Powszechnym niepowodzeniem jest uruchamianie skanerów wcześniej w potoku, które emitują ostrzeżenia, podczas gdy krok promocji nie ma twardej bramki – więc oznaczony artefakt i tak trafia do wdrożenia, gdy inżynier nadpisuje pod presją terminu. Bramka dopuszczenia musi zawodzić w sposób zamknięty (fail closed): jeśli proweniencja nie może zostać zweryfikowana, artefakt nie zostaje wdrożony. Osadzenie tych bramek jako kodu, recenzowanego i wersjonowanego jak każdy inny etap potoku, jest naturalnym rozszerzeniem praktyki DevSecOps dla obronności, gdzie mechanizmy kontroli bezpieczeństwa są częścią każdego sprintu, a nie audytem przedwydaniowym.

Obsługa łańcucha w środowiskach niejawnych

W enklawie odseparowanej (air-gapped) lub niejawnej cały łańcuch musi działać bez dostępu do internetu. Wewnętrzne lustra przechowują zweryfikowane zależności, usługa kompilacji i dziennik przejrzystości działają wewnątrz enklawy, a klucze weryfikacyjne są dystrybuowane przez zatwierdzone kanały. Aktualizacje lustra zależności docierają przez kontrolowane transfery międzydomenowe, każda niosąc własną proweniencję, tak aby enklawa mogła ponownie zweryfikować pochodzenie przed dopuszczeniem pakietu. Zaprojektowanie łańcucha dostaw do działania offline od pierwszego sprintu – zamiast doposażania go później – jest tym, co stanowi różnicę między frameworkiem kontroli, który przetrwa akredytację, a takim, który zawali się przy zetknięciu z rzeczywistym wdrożeniem niejawnym.