Provenance nie jest pieczątką

Historia artefaktu jest częścią bezpieczeństwa

Współczesny pakiet nie powstaje już wyłącznie z kodu, który widzi jego autor. Wchodzą do niego zależności, obrazy bazowe, narzędzia budujące, cache, runner CI i registry. SLSA definiuje provenance jako weryfikowalną informację opisującą, gdzie, kiedy i jak powstał artefakt.^[1]

To zmienia pytanie z „czy plik ma podpis?” na „czy plik powstał w zaufanym procesie, z właściwego repozytorium, z właściwych zależności i z oczekiwanymi parametrami?”. Podpis mówi, kto coś podpisał. Provenance ma pomóc sprawdzić, co właściwie zostało zbudowane.

Lockfile zatrzymuje dryf, ale nie zna całej historii

Lockfile przypina wersje zależności i utrudnia przypadkową zmianę. Nie odpowiada jednak sam z siebie na pytania o to, kto uruchomił build, z jakiego commita, na jakim runnerze, z jakimi parametrami i czy artefakt nie został podmieniony po kompilacji. To nie wada lockfile. To inna warstwa kontroli.

W dyskusji r/netsec o kanarkach w CI/CD pojawił się trafny podział: kanarek może poinformować o użyciu sekretu po kompromitacji, ale nie zatrzyma złośliwej zależności przed wejściem do buildu.^[2] Właśnie dlatego detekcja i provenance powinny działać razem, nie jako konkurencyjne rozwiązania.

Co faktycznie sprawdza verifier?

Dokumentacja SLSA zaleca między innymi sprawdzenie tożsamości buildera, podpisu koperty provenance oraz zgodności typu buildu i parametrów z oczekiwaniami.^[3] Nie wystarczy więc zobaczyć, że provenance istnieje. Trzeba mieć własną listę zaufanych builderów i reguły, które mogą odrzucić artefakt.

1. Sprawdź digest artefaktu względem subject w attestation.
2. Sprawdź podpis i tożsamość buildera względem zaufanego root of trust.
3. Porównaj repozytorium, commit, parametry i zależności z polityką projektu.
4. Odrzuć wynik, jeśli pojawił się nieznany builder albo nieoczekiwany parametr.
5. Loguj decyzję — „odrzucony” bez śladu audytowego szybko staje się „przepuszczony ręcznie”.