GitHub Actions: lockfiles vážou tagy na konkrétní commity

GitHub 14. října 2026 zpřístupnil workflow dependency lockfiles ve veřejném náhledu pro plány Enterprise Cloud, Enterprise Cloud with data residency, Team a Free. Správci CI mohou v souborech GitHub Actions ponechat odkazy na tagy a větve, ale závislosti zařazeného workflow se při běhu načtou z commitů uložených v .github/workflows/actions.lock. Přesunutí tagu tak samo o sobě nemusí změnit kód, který se spustí při dalším běhu.

Bezpečnostní výzkumník François Proulx při testech Boost Security Labs zveřejněných 15. října 2026 ověřil, že uzamčená nepřímá závislost zůstala na původním commitu i po posunu větve. Výzkumníci zároveň našli chybu, při níž ručně připravený záznam mohl přijmout commit existující pouze ve forku. Po opravě na straně služby stejný pokus při opakovaném testu selhal; oprava kontroly v rozšíření CLI v době zveřejnění testu ještě čekala. Pro správce je to důvod začít omezeným pilotem a kontrolovat změny lockfile před zapnutím plošné zásady.

Co určuje spuštěný commit

Odkaz v YAML dál vyjadřuje požadovanou verzi akce, zatímco lockfile obsahuje commit, který GitHub Actions skutečně použije. Tag nebo větev se mohou po schválení workflow přesunout na jiný commit, aniž by se změnil soubor v repozitáři, kde workflow běží. U workflow zařazeného do lockfile musí mít každá závislost odpovídající záznam; při spuštění se použije uložený commit místo aktuálního cíle pohyblivého odkazu.

Rozdíl je zvlášť důležitý u složených akcí. Akce uvedená přímo ve workflow může být připnutá na pevný commit, ale uvnitř může volat další akci přes větev. Původní připnutí rodičovské akce tak samo neurčuje, jaký commit této vnitřní závislosti se později načte. Lockfile zaznamenává i takové nepřímé akce. U opakovaně použitelného workflow se naopak v repozitáři volajícího uzamkne odkaz na něj; jeho vlastní vnitřní akce patří do lockfile repozitáře, kde je opakovaně použitelné workflow definováno.

Uzamčení zachovává výběr kódu, samo však neposuzuje, zda byl vybraný commit bezpečný. První vytvoření souboru proto zachytí právě ty verze, na které odkazy v danou chvíli míří. Pozdější změna commitu je nová změna vykonávaného kódu a zaslouží stejnou pozornost jako úprava souboru workflow. Stejně tak lockfile akcí neurčuje verze balíčků nebo souborů, které si uzamčená akce stáhne až během běhu.

Nejprve vytvořit a ověřit soubor

Správcovský návod GitHubu staví pilot před zapnutí zásady Require lockfile v režimu Active. Vhodným začátkem je vybraný repozitář a jedno workflow, jehož závislosti lze zkontrolovat. Rozšíření GitHub CLI se instaluje příkazem gh extension install github/gh-actions-lock; příkaz gh actions-lock následně vytvoří soubor .github/workflows/actions.lock. Zadáním cesty ke konkrétnímu workflow lze zařazování rozdělit na menší kroky.

Nejdříve zkontrolovat odkazy na akce a opakovaně použitelná workflow, potom vygenerovat lockfile. Před potvrzením změny je nutné projít celý diff: rozšíření může upravit také odkazy uses v souborech workflow a u místních akcí změnit způsob jejich odkazování.
Spustit gh actions-lock --verify-local --no-fix jako rychlou lokální kontrolu úplnosti záznamů. Funguje bez připojení a bez přihlášení, ale uložené commity znovu neověřuje vůči GitHubu. Úspěch této kontroly proto sám nestačí k posouzení nově vybraného kódu.
Do pull requestů přidat kontrolu gh actions-lock --verify při změnách souborů workflow nebo definic místních akcí. Zastaralý či chybějící záznam se tím projeví ještě před sloučením, kdy jej autor může aktualizovat společně se změnou workflow.
Vymezit pilot zásady na repozitáře a workflow, které již mají záznamy. Tam, kde je dostupný režim Evaluate, lze dopad sledovat v Policy insights bez blokování běhů; tento režim je určen pro GitHub Enterprise.

Soubor v repozitáři a zásada vyžadující jeho použití řeší různé části zavedení. Zařazené workflow používá uložené commity, zatímco aktivní zásada brání spuštění cíleného workflow se závislostmi, pokud není v lockfile řádně zahrnuto. Dokumentace správcovského postupu uvádí jako oprávněné uživatele GitHub Enterprise Cloud, ačkoli samotný veřejný náhled lockfiles byl oznámen také pro další plány. Dostupnost zamykání závislostí tedy není důvodem předpokládat stejné možnosti centrální správy zásad u každého plánu.

Aktualizace musí projít kontrolou commitu

Dependabot při aktualizaci verze akce v již zařazeném workflow obnoví odpovídající položku lockfile ve stejném pull requestu. Recenzent tak může společně posoudit nový odkaz ve workflow i commit, který se bude spouštět. Dependabot ovšem nezařadí nově přidané workflow bez záznamů; pro něj je potřeba soubor vytvořit a následně hlídat jeho úplnost kontrolou v pull requestu.

Soubor .github/workflows/actions.lock má být uvedený v CODEOWNERS a ochrana větve nebo repository ruleset má vyžadovat schválení vlastníkem kódu. Tím dostane změna commitu konkrétního posuzovatele. Kontrola diffu je důležitá i tehdy, když změnu připravil automaticky Dependabot: schvalovanou skutečností je nový vykonávaný kód, nikoli jen čitelný název verze v YAML.

Kdy zásadu vynutit

Režim Active patří až na rozsah, v němž jsou cílená workflow zařazená, ověřovací kontrola zachytává zastaralé záznamy a změny lockfile procházejí schválením. Ověření v pull requestech má smysl ponechat i po zapnutí zásady: autor dostane zprávu o chybě při úpravě, zatímco zásada chrání samotný běh. Před rozšířením rozsahu je potřeba zahrnout také repozitáře, v nichž jsou definována sdílená opakovaně použitelná workflow.

Výsledkem pilotu má být jasně určené místo schvalování každé změny vykonávaného commitu. Čitelný tag může zůstat v souboru workflow, rozhodující verze závislosti však leží v kontrolovaném lockfile. Rozšíření zásady na další repozitáře pak závisí na tom, zda dokážou nové workflow do souboru průběžně zařazovat a změny jeho záznamů kontrolovat před sloučením.

Přečtěte si také: