Sigstore i SLSA: jak udowodnić, skąd naprawdę pochodzi Twój artefakt

Po serii głośnych ataków na łańcuch dostaw oprogramowania — od SolarWinds po robaki w npm — jedno pytanie stało się kluczowe: skąd wiesz, że pobrany artefakt (obraz kontenera, pakiet, binarka) jest tym, za co się podaje, i że zbudowano go tak, jak myślisz? Odpowiedzią są dwa uzupełniające się projekty: Sigstore (podpisywanie) i SLSA (weryfikowalna proweniencja). Rozłóżmy je technicznie.

Problem: podpisywanie kodu jest trudne, więc nikt tego nie robi

Klasyczne podpisywanie kodu (GPG, certyfikaty) teoretycznie rozwiązuje problem autentyczności. W praktyce upada na zarządzaniu kluczami: długożyjący klucz prywatny trzeba bezpiecznie wygenerować, przechować, chronić przed kradzieżą i unieważnić po wycieku. To na tyle uciążliwe, że większość projektów open source po prostu nie podpisuje wydań — a jeśli podpisuje, użytkownicy i tak rzadko weryfikują.

Sigstore: podpisywanie bez zarządzania kluczami

Sigstore wywraca ten model, eliminując długożyjące klucze prywatne. Zamiast nich stosuje podpisywanie oparte na tożsamości (keyless signing) z trzema komponentami:

• Fulcio — urząd certyfikacji, który na podstawie tożsamości z OIDC (np. konto GitHub, Google, tożsamość workflowu CI) wystawia krótkożyjący certyfikat (ważny minuty). Podpisujesz nim artefakt, po czym certyfikat wygasa — nie ma czego kraść ani przechowywać.
• Rekor — publiczny, niezmienialny dziennik przejrzystości (transparency log). Trafia do niego wpis o podpisie: co, kto (tożsamość), kiedy. Dzięki temu podpis jest publicznie weryfikowalny i niezaprzeczalny, a próba cichego podmienienia artefaktu zostawia ślad.
• cosign — narzędzie, którym w praktyce podpisujesz i weryfikujesz (szczególnie obrazy kontenerów w rejestrze OCI).

Efekt: podpisywanie staje się na tyle proste, że można je wpiąć w pipeline bez zarządzania sekretami. Podpis wiąże artefakt z tożsamością (np. „ten obraz podpisał workflow build.yml z repozytorium X”), a nie z anonimowym kluczem, który mógł wyciec.

# uproszczony przepływ
cosign sign  registry.example.com/app@sha256:...   # tożsamość z OIDC → Fulcio → Rekor
cosign verify registry.example.com/app@sha256:... \
  --certificate-identity=... --certificate-oidc-issuer=...

SLSA: proweniencja, czyli „jak to zbudowano”

Podpis mówi „to jest autentyczne”. Nie mówi jednak jak artefakt powstał. Tu wchodzi SLSA (Supply-chain Levels for Software Artifacts, czyt. „salsa”) — framework opisujący integralność procesu budowania.

Sercem SLSA jest proweniencja (provenance): podpisany, weryfikowalny dokument (atestacja, zwykle w formacie in-toto) opisujący, co, z czego i gdzie zostało zbudowane — jakie źródło (commit), jaki builder, jakie zależności. Konsument artefaktu może zweryfikować tę proweniencję i odrzucić wszystko, co nie spełnia jego polityki (np. „akceptuję tylko obrazy zbudowane przez nasz zaufany system CI z gałęzi main”).

SLSA definiuje poziomy rosnącej gwarancji, w uproszczeniu:

• Poziom 1 — proweniencja istnieje (wiadomo, jak zbudowano artefakt), choć niekoniecznie odporna na manipulację.
• Poziom 2 — proweniencja jest podpisana i generowana przez hostowany system budowania.
• Poziom 3 — build jest izolowany i odporny na ingerencję; proweniencja jest niepodrabialna, bo generuje ją zaufany, odseparowany builder, do którego nie ma dostępu kod budowanego projektu.

Im wyższy poziom, tym trudniej atakującemu — nawet z dostępem do repozytorium — wstrzyknąć złośliwy artefakt tak, by przeszedł weryfikację.

Jak to spina się w praktyce

Sigstore i SLSA grają razem: SLSA mówi, jaką gwarancję chcesz uzyskać, a Sigstore dostarcza kryptograficznego mechanizmu (podpis + dziennik przejrzystości) do jej realizacji. Typowy przepływ w dojrzałym pipeline:

1. System CI buduje artefakt w izolowanym środowisku.
2. Generuje atestację proweniencji (co, skąd, jak).
3. Podpisuje artefakt i atestację przez Sigstore (tożsamość workflowu, wpis w Rekor).
4. Przy wdrożeniu — kontroler dopuszczający (np. w Kubernetes) weryfikuje podpis i proweniencję według polityki i odrzuca artefakty, które jej nie spełniają.

To domyka lukę, którą wykorzystują ataki na łańcuch dostaw: nie wystarczy już podmienić pakiet w rejestrze — trzeba jeszcze podrobić weryfikowalny, publicznie zarejestrowany dowód pochodzenia, co przy wyższych poziomach SLSA jest praktycznie nieosiągalne.

Od czego zacząć

Nie trzeba od razu celować w SLSA poziom 3. Sensowna kolejność:

1. Generuj SBOM i podstawową proweniencję w pipeline CI/CD — wiedza „co i jak budujemy” to fundament.
2. Podpisuj artefakty przez cosign (keyless) — tanie wejście dające autentyczność i wpis w dzienniku przejrzystości.
3. Weryfikuj na wdrożeniu. Podpis bez weryfikacji jest bezużyteczny — dodaj kontrolę podpisu i tożsamości przy wdrażaniu (admission control).
4. Podnoś poziom SLSA stopniowo: izolacja buildera, niepodrabialna proweniencja, polityki akceptacji.
5. Rozszerz na dostawców. Pytaj kluczowych dostawców oprogramowania o podpisywanie i proweniencję — to konkretny element zarządzania ryzykiem dostawców.

Podsumowanie

Sigstore i SLSA odpowiadają na dwa pytania, które ataki na łańcuch dostaw uczyniły krytycznymi: „czy to autentyczne?” i „jak to zbudowano?”. Sigstore czyni podpisywanie na tyle prostym (bez długożyjących kluczy, z publicznym dziennikiem), że można je realnie wdrożyć; SLSA daje ramę do weryfikowalnej proweniencji o rosnącej gwarancji. Razem przesuwają zaufanie z „ufam, że pakiet jest czysty” na „mam kryptograficzny dowód pochodzenia i sposobu budowy”.

Jeśli chcecie wbudować podpisywanie artefaktów i weryfikację proweniencji w swój proces wytwarzania, porozmawiajmy — pomagamy projektować bezpieczne pipeline’y w ramach konsultacji bezpieczeństwa.

Najczęstsze pytania (FAQ)

Czym keyless signing w Sigstore różni się od zwykłego podpisu GPG? GPG opiera się na długożyjącym kluczu prywatnym, który trzeba chronić i który po wycieku kompromituje wszystkie podpisy. Sigstore używa krótkożyjącego certyfikatu wystawianego na podstawie tożsamości (OIDC) i zapisuje podpis w publicznym dzienniku przejrzystości. Nie ma trwałego sekretu do kradzieży, a podpis jest publicznie weryfikowalny i powiązany z konkretną tożsamością.

Czy SLSA to standard, który trzeba „wdrożyć w całości”? Nie — SLSA jest stopniowalny. Zaczynasz od generowania proweniencji (poziom 1) i podnosisz gwarancje w miarę dojrzewania procesu. Nawet niski poziom daje realną wartość: wiadomo, co i jak zostało zbudowane, co utrudnia ciche podmiany.

Czy publiczny dziennik Rekor nie ujawnia moich sekretów? Nie. Do dziennika trafiają metadane podpisu (skrót artefaktu, tożsamość podpisującego, czas), a nie sam artefakt ani jego zawartość. Celem jest przejrzystość i niezaprzeczalność, nie ujawnianie kodu.

Podpisuję artefakty, ale czy to wystarczy? Podpis ma wartość tylko wtedy, gdy jest weryfikowany przy pobieraniu i wdrażaniu — inaczej jest ozdobą. Kluczowe jest wpięcie weryfikacji podpisu i proweniencji w moment wdrożenia (np. kontroler dopuszczający w Kubernetes), z polityką odrzucającą artefakty spoza zaufanego źródła.