Czym jest SLSA? Supply-chain Levels for Software Artifacts

Jaki problem rozwiązuje SLSA?

Można przejrzeć każdy wiersz kodu źródłowego, a mimo to dostarczyć coś innego, ponieważ użytkownicy uruchamiają wynik buildu. Jeśli build zostanie przejęty, jak w przypadku SolarWinds, czysty kod źródłowy daje zatrute wydanie. SLSA skupia się na tej luce: czy ktokolwiek może zweryfikować, że ten artefakt powstał z tego źródła, w tym procesie?

Poziomy SLSA

SLSA porządkuje wymagania w ścieżki (tracks). Obecna wersja 1.2 ma ścieżkę Build i ścieżkę Source. Ścieżka Build ma cztery poziomy.

Poziom	Nazwa	Czego wymaga	Co daje
Build L0	Brak gwarancji	Niczego	L0 oznacza brak SLSA
Build L1	Istnieją dane o pochodzeniu	Spójnego procesu buildu oraz danych o pochodzeniu generowanych przez platformę buildu i przekazywanych odbiorcom	Pomaga zapobiegać pomyłkom, ale łatwo to obejść lub sfałszować
Build L2	Hostowana platforma buildu	Buildy działają na hostowanej platformie, która generuje i podpisuje dane o pochodzeniu, a odbiorcy je weryfikują	Sfałszowanie danych o pochodzeniu wymaga już celowego ataku
Build L3	Utwardzone buildy	Uruchomienia są od siebie odizolowane, a sekret podpisujący jest poza zasięgiem kroków buildu zdefiniowanych przez użytkownika	Sfałszowanie danych o pochodzeniu wymaga wykorzystania podatności, co przekracza możliwości większości przeciwników

Poziomy to nie ocena, którą trzeba maksymalizować. Każdy chroni przed konkretnymi zagrożeniami, dlatego należy wybrać poziom odpowiedni do swojego ryzyka. Opiekunowie projektów open source korzystający z hostowanej usługi CI często mogą osiągnąć L2 bez większego wysiłku.

Czym jest pochodzenie (provenance)?

Dane o pochodzeniu to zapis tego, jak powstał artefakt. W SLSA mówią, która platforma go zbudowała, z jakiego źródła, w jakim procesie i z jakimi wejściami najwyższego poziomu. Od poziomu L2 dane o pochodzeniu są podpisywane, więc odbiorca może sprawdzić, że pochodzą z platformy buildu i nie zostały zmienione.

SBOM to składniki, a dane o pochodzeniu mówią, gdzie i jak przyrządzono danie. Odpowiadają na różne pytania i dobrze się uzupełniają: SBOM wymienia, co jest w środku, a dane o pochodzeniu mówią, skąd pochodzi artefakt.

Jak wdrożyć SLSA

Budować w CI, za każdym razem tak samo. Przestać publikować wydania z laptopów. To większość pracy potrzebnej do osiągnięcia L1.
Generować dane o pochodzeniu. W GitHub atestacje artefaktów (artifact attestations) tworzą podpisane dane o pochodzeniu. Zob. jak atestacje współpracują z SBOM-ami w GitHub Actions.
Weryfikować je tam, gdzie to ma znaczenie. Podpisane dane o pochodzeniu, których nikt nie sprawdza, nikogo nie chronią. Weryfikację należy dodać do kroku wdrożenia lub kontrolera dopuszczania (admission controller).
Utwardzać build. Izolować uruchomienia i trzymać klucze podpisujące z dala od kroków buildu. Zob. porównanie bezpieczeństwa runnerów.
Wymagać tego od zależności. Wybierać pakiety publikujące dane o pochodzeniu, co obsługują już rejestry takie jak npm.

Czego SLSA nie obejmuje

Podatności. Doskonale zbudowany artefakt może zawierać błąd. SLSA nie mówi nic o tym, czy kod jest bezpieczny.
Złośliwego kodu źródłowego. Jeśli napastnik zatwierdzi zmiany w repozytorium, dane o pochodzeniu wiernie zapiszą build tego kodu. Część tego problemu rozwiązuje ścieżka Source.
Tego, co build pobrał. Dane o pochodzeniu wymieniają wejścia najwyższego poziomu. Nic w ścieżce Build nie wymaga pełnej listy zależności, a właśnie do tego służy SBOM.
Zaufanych osób z wewnątrz. Tylna furtka w xz pojawiła się za sprawą zaufanego opiekuna i samo SLSA by jej nie zatrzymało.

SLSA a inne frameworki

SLSA dogłębnie zajmuje się integralnością buildu. NIST SSDF jest znacznie szerszy: obejmuje bezpieczne wytwarzanie jako całość, w tym praktykę ochrony i archiwizacji wydań, którą wspierają dane o pochodzeniu SLSA. SLSA jest projektem OpenSSF, a wiele zespołów używa obu razem. Szerszy obraz przedstawia strona czym jest bezpieczeństwo łańcucha dostaw oprogramowania.

Miejsce CRACI

CRACI nie tworzy podpisanych danych o pochodzeniu i nie deklaruje żadnego poziomu SLSA, więc jeśli jest on Państwu potrzebny, należy skorzystać z atestacji artefaktów GitHub lub podobnej usługi. CRACI dodaje to, co SLSA pomija: pełny zapis tego, co pobrało każde zadanie GitHub Actions. Każde zadanie działa we własnej, odizolowanej maszynie wirtualnej, każdy pobrany pakiet trafia do SBOM, a polityka ruchu wychodzącego blokuje połączenia zbędne dla buildu. Zob. generowanie SBOM w czasie buildu.

SLSA: najczęściej zadawane pytania

Co oznacza skrót SLSA?

Supply-chain Levels for Software Artifacts. Wymawia się go „salsa”.

Jakie są poziomy SLSA?

Ścieżka Build ma cztery: L0, brak gwarancji; L1, istnieją dane o pochodzeniu; L2, hostowana platforma buildu podpisująca dane o pochodzeniu; oraz L3, utwardzone buildy z izolowanymi uruchomieniami i chronionymi sekretami podpisującymi. Wersja 1.2 dodaje też ścieżkę Source.

Czym są dane o pochodzeniu w SLSA?

To zapis tego, jak zbudowano artefakt: na jakiej platformie, z jakiego źródła, w jakim procesie i z jakimi wejściami najwyższego poziomu. Od poziomu Build L2 są podpisywane, więc odbiorcy mogą je zweryfikować.

Jaka jest różnica między SLSA a SBOM?

SBOM wymienia, co jest w oprogramowaniu. Dane o pochodzeniu SLSA opisują, jak i gdzie je zbudowano. Zwykle potrzebne jest jedno i drugie.

Czy SLSA jest obowiązkowe?

Nie. To dobrowolny framework społeczności OpenSSF. Niektórzy klienci i organizacje mogą wymagać określonego poziomu, ale nie jest to prawo.

Do którego poziomu SLSA dążyć?

Warto zacząć od Build L1, budując w CI i generując dane o pochodzeniu, a następnie przejść na L2 na hostowanej platformie, co wiele zespołów osiąga szybko. L3 jest odpowiedni dla wydań, od których zależy wielu innych lub które wiążą się z wysokim ryzykiem.