Odtwarzalny build

Odtwarzalny build daje identyczny bit po bicie wynik za każdym razem, gdy ktoś buduje ten sam kod źródłowy w tym samym środowisku buildu i według tych samych instrukcji buildu. Tak brzmi definicja projektu Reproducible Builds. Wynik oznacza tu artefakty, które build ma wytworzyć: pliki wykonywalne, pakiety dystrybucyjne, obrazy kontenerów lub systemów plików. Logi się nie liczą. „Znowu się buduje” to nie to samo; odtwarzalny oznacza, że bajty się zgadzają.

Dlaczego większość buildów nie jest odtwarzalna

• Rozwiązywanie zależności w trakcie buildu. Bez lockfile menedżer pakietów wybiera wersje w chwili uruchomienia buildu. Rozwiązywanie zależności w PyPI może dać różny wynik w zależności od kolejności nadchodzących odpowiedzi, zakres wersji przesuwa się po nowym wydaniu, a zmienny tag, taki jak latest, wskazuje coś innego.
• Środowisko. Znaczniki czasu, ścieżki plików, ustawienia regionalne i narzędzia hosta trafiają do artefaktów.
• Losowość. Kroki buildu mogą generować identyfikatory, sortować pliki według skrótu lub wykonywać zadania równolegle za każdym razem w innej kolejności.

Dwukrotne zbudowanie tego samego commita jeden po drugim nie gwarantuje więc ani tego samego wyniku, ani tego samego SBOM. Build, który pobiera kod niewymieniony w lockfile, czyli ukrytą zależność, jeszcze to pogarsza.

Jak zespoły uzyskują odtwarzalne buildy

• Przypinać i blokować każde wejście, także obrazy bazowe przez digest i narzędzia przez wersję (zob. lockfile).
• Używać stałego czasu zamiast zegara: SOURCE_DATE_EPOCH to standardowa zmienna środowiskowa zawierająca znacznik czasu Unix, którego narzędzia buildu używają zamiast bieżącego czasu.
• Usuwać lub normalizować ścieżki buildu, sortować listy plików i ustalać ustawienia regionalne.
• Budować w hermetycznym środowisku, którego zestaw narzędzi też jest przypięty. Nix to jeden ze sposobów.
• Weryfikować wynik: zbudować ten sam commit dwa razy, niezależnie (na innej maszynie, w innej ścieżce, innego dnia), i porównać wyniki. Tam, gdzie skróty się różnią, diffoscope pokazuje dokładnie, co się zmieniło.

Yocto Project pokazuje, dlaczego odtwarzalność jest właściwością, którą trzeba weryfikować, a nie zakładać. Jego dokumentacja podaje, że buildy projektu są odtwarzalne „aż do poziomu binarnego, łącznie ze znacznikami czasu” od wydania 3.1, że pełną odtwarzalność gwarantują tylko BitBake i OpenEmbedded-Core oraz że „w chwili dodania kolejnej warstwy ta gwarancja przestaje obowiązywać”. Projekt testuje to za pomocą oe-selftest.

Odtwarzalne buildy a SBOM

Gdyby każdy build był odtwarzalny, można by później ponownie zbudować stare wydanie i wygenerować jego SBOM. Większość taka nie jest, więc ponowny build lub dzisiejszy skan kodu źródłowego opisuje podobny build, a nie ten, który został dostarczony. SBOM pokazujący, co działa na produkcji, to SBOM zarejestrowany w buildzie CI, który wytworzył dane wydanie.

Nawet odtwarzalny build nie czyni tego zapisu zbędnym. Zgodne skróty dowodzą, że dwa buildy dały ten sam wynik; nie wymieniają, co do nich trafiło. Nadal potrzebny jest spis i rzetelna informacja o kompletności SBOM. Dlaczego CI jest miejscem na bezpieczeństwo łańcucha dostaw i dobre praktyki SBOM rozwijają ten argument.

SLSA traktuje odtwarzalność jako jeden ze sposobów sprawdzenia, czy build zrobił to, co deklaruje.

Odtwarzalność zespoły osiągają w swoim systemie buildu, za pomocą narzędzi takich jak Nix, Yocto czy narzędzia Debiana. CRACI nie sprawia, że buildy stają się odtwarzalne: rejestruje SBOM każdego buildu w trakcie jego działania, więc zapis tego, co dostarczono, nie zależy od ponownego budowania. Zob. SBOM z czasu buildu.