Jak zweryfikować, że artefakt GitHub Actions został zbudowany przez Ciebie, a nie przez atakującego

Ataki na łańcuch dostaw dawno przestały być teorią i stały się brutalną rzeczywistością. Załóżmy, że użytkownik pobiera wstępnie zbudowany plik binarny z sekcji Releases na GitHub. Jak może zweryfikować, że plik został faktycznie zbudowany przez serwer CI z kodu źródłowego konkretnego commitu, a nie przesłany przez hakera, który uzyskał dostęp do konta dewelopera?

Aby rozwiązać ten problem, GitHub wprowadził specjalną akcję actions/attest-build-provenance. Przyjrzyjmy się, jak to działa, dlaczego potrzebne są podpisy Sigstore i dlaczego będziesz potrzebować nieco innego narzędzia podczas tworzenia nowych pipeline'ów.

Gdzie powiązać podpis

Istota podpisywania pochodzenia jest dość prosta. Każdy gotowy plik potrzebuje cyfrowego paszportu. Ten dokument potwierdza: artefakt o określonym hash został zbudowany w określonym workflow, w określonym repozytorium i na określonym commicie.

Narzędzie generuje manifest zgodny ze standardem in-toto oraz specyfikacją SLSA (Supply-chain Levels for Software Artifacts). Następnie dzieje się najciekawsza część: podpisywanie tego manifestu.

Zamiast zmuszać deweloperów do generowania długowiecznych kluczy PGP i przechowywania ich w sekretach repozytorium, używana jest architektura Sigstore. Akcja żąda tymczasowego tokena OIDC od GitHub Actions i wymienia go na krótkotrwały certyfikat podpisujący.

W przypadku repozytoriów publicznych podpis jest generowany przez publiczną usługę Sigstore, a dane o nim trafiają do przejrzystego logu Rekor. Jeśli repozytorium jest prywatne, GitHub używa własnej prywatnej instancji Sigstore (ta funkcja jest dostępna w planie Enterprise Cloud).

Mała niespodzianka w dokumentacji

Jeśli otworzysz oficjalne repozytorium projektu, zobaczysz ważną notatkę na samym początku pliku README.

Począwszy od wersji czwartej, actions/attest-build-provenance stało się prostym wrapperem na bazową akcję actions/attest. Deweloperzy GitHub wyraźnie stwierdzają: jeśli utrzymujesz stare pipeline'y, możesz zostawić wszystko jak jest. Ale w przypadku nowych projektów powinieneś od razu zacząć od actions/attest.

Dlaczego GitHub dodał dodatkową warstwę? Początkowo zespół budował wąsko wyspecjalizowane narzędzie tylko do pochodzenia buildów. Później pojawiło się pragnienie podpisywania nie tylko plików binarnych, ale także SBOM (list zależności) lub wyników skanowania podatności. W ten sposób powstało bardziej uniwersalne actions/attest, a stara akcja została wycofana jako synonim.

Jak wyglądało podłączenie

W starszych wersjach akcji logika w .github/workflows/build.yml była skompresowana do zaledwie kilku linijek po kroku budowania artefaktu.

Co tutaj ważne, to uprawnienia id-token: write i attestations: write. Bez pierwszej opcji workflow nie będzie w stanie uzyskać tokena OIDC do bezhasłowego podpisywania przez Sigstore, a bez drugiej nie przesładuje wyniku do API GitHub Attestations.

Jak zweryfikować autentyczność artefaktu

Po utworzeniu zaświadczenia i powiązaniu go z repozytorium każdy użytkownik lub skrypt weryfikacyjny może sprawdzić plik lokalnie. Służy do tego oficjalne narzędzie CLI GitHub.

Polecenie weryfikacji wygląda następująco:

gh attestation verify app.sh --owner my-organization

Jeśli plik nie został zmieniony i został zbudowany w określonej organizacji, CLI wyświetli informacje o commicie i certyfikacie podpisującym. Jeśli jednak plik został choćby minimalnie zmodyfikowany, weryfikacja zakończy się błędem.

Czy warto to wdrażać

Jeśli tworzysz bibliotekę open-source lub narzędzie CLI, generowanie zaświadczeń daje użytkownikom łatwy sposób na weryfikację bezpieczeństwa Twoich wydań.

Z drugiej strony, jeśli masz mały projekt wewnętrzny bez rygorystycznych wymagań bezpieczeństwa łańcucha dostaw, dodawanie dodatkowych kroków do CI może być przesadą.

W przypadku nowych workflow'ów używaj bezpośrednio actions/attest zamiast actions/attest-build-provenance. Podstawowa funkcjonalność pozostanie taka sama, ale będziesz korzystać z aktualnego narzędzia bez przestarzałych wrapperów.