GitHub Actions отримав workflow dependency lockfiles (public preview): у YAML лишається зрозумілий uses: some/action@v3, а виконується точний commit, записаний у .github/workflows/actions.lock – разом із транзитивними залежностями actions і reusable workflows. Lockfile генерується CLI-розширенням gh actions-lock, а Dependabot оновлює його в тому ж PR, що й версію. Це закриває стару дірку supply chain у CI – рухомі теги. Але не закриває головного: залочити можна й шкідливий commit, просто тепер він виконуватиметься стабільно.

Проблема, яку нарешті визнали

Кожен workflow у твоєму репозиторії тримається на рядках типу:

uses: some/action@v3

v3 – movable reference. Ти перевірив код action сьогодні, а через місяць автор (або той, хто захопив його акаунт) може перенести тег на зовсім інший commit. Твій CI навіть не помітить різниці – він чесно виконає те, на що тепер вказує тег. Для supply-chain атаки це подарунок: один перенесений тег у популярній action – і шкідливий код виконується з секретами тисяч репозиторіїв.

Старий компроміс: безпечно або читабельно

Security-рекомендація існувала давно – pin exact SHA:

uses: some/action@8f4b7f84864484a7bf31766abe9204da3cbe65b3

Безпечно. І нестерпно: рев'ю такого YAML перетворюється на звіряння хешів, оновлення – на ручну рутину, а головне – транзитивні залежності (actions, які викликають інші actions, reusable workflows) цей pin не покривав узагалі. Більшість команд чесно обирала читабельність і жила з ризиком.

Як працює lockfile

За офіційним анонсом, механіка така:

  1. Генерація. Встановлюєш CLI-розширення gh actions-lock – воно створює й підтримує .github/workflows/actions.lock.
  2. Що фіксується. Lockfile записує перевірені commits для actions, їхніх транзитивних залежностей і reusable workflows. Саме транзитивність – головна перевага над ручним SHA-pin.
  3. Виконання. Для «onboarded» workflow GitHub Actions вимагає, щоб кожна залежність була в lockfile, і використовує записаний commit – «навіть якщо тег чи гілка перемістились». YAML лишається з людським @v3.
  4. Оновлення. Dependabot, відкриваючи version-update для action, у тому ж PR регенерує відповідний запис lockfile – reference і закомічений SHA не розсинхронізовуються.

Доступність: public preview для Enterprise Cloud (включно з data residency), Team і Free планів.

Логіка рівно та сама, що з package-lock.json: маніфест для людей, lock для машини. Supply chain сказав: «місця у репозиторії вистачить усім».

Аналогія з npm правильна, але не повна

Lockfile гарантує відтворюваність. Він не гарантує, що залежність безпечна. GitHub пише це прямо: «Locking does not determine whether the dependency itself is safe, so review dependencies before locking them».

Якщо ти залочив шкідливий commit – lockfile чесно й стабільно запускатиме шкідливий commit. Тому процес навколо файла важливіший за сам файл:

  1. Review залежності перед першим lock – хоча б швидкий погляд на код action і її maintainer-історію.
  2. Lock через gh actions-lock.
  3. Review оновлень lockfile у PR – diff SHA має бути усвідомленим кроком, а не авто-merge.
  4. Алерти на застарілі залежності – залочене й забуте через рік стає окремим ризиком.

Це той самий принцип «enforcement замість наміру», що й у Node.js Permission Model: політика, прописана в правилах чи промптах, – це побажання; політика, зафіксована механізмом, – це інженерія.

Чому це особливо на часі: агенти редагують CI

Coding-агенти дедалі частіше правлять workflow-файли – додають кроки, оновлюють версії, чинять «зламаний CI». Агент, який необачно замінить @v3 на @main чи додасть невідому action, створює ту саму діру, що й необачна людина, тільки швидше.

Lockfile переносить контроль із «наскільки уважний prompt» на рівень репозиторію: що б не написав агент у YAML, виконається лише те, що пройшло через lock-процес. У зв'язці зі сканером секретів це дві частини однієї ідеї – репозиторій захищає себе сам, незалежно від того, хто в нього пише: людина чи агент.

Перевір свої workflow прямо зараз

  1. Виконай у своєму основному репозиторії: grep -rn "uses:" .github/workflows | grep -v "@[0-9a-f]\{40\}" – побачиш усі рухомі references.
  2. Постав gh extension install для actions-lock, згенеруй lockfile у тестовій гілці й подивись, скільки транзитивних залежностей ти насправді запускаєш (зазвичай це сюрприз).
  3. Увімкни Dependabot для actions, якщо ще не ввімкнений – без нього lockfile поступово перетворюється на музей.

Де lockfile дає хибне відчуття безпеки

  • Lock без review. Зафіксувати невідомий код – це консервація ризику, а не захист.
  • Авто-merge PR з оновленнями lockfile. Diff SHA – саме те місце, де supply-chain атаку ще можна зловити очима.
  • Віра, що preview-фіча = завершений захист. Це public preview: перевіряй поведінку на своєму плані й стеж за змінами механізму.
  • Pin тільки верхнього рівня. Якщо твій інструмент не бачить транзитивних залежностей – ти захистив двері, лишивши вікна.

Найкраще в цій новині – не сам файл, а визнання: CI-конфігурація стала повноцінною частиною supply chain, і їй потрібні ті самі інструменти, що й коду. Lockfile для YAML звучав як жарт у 2020-му. У 2026-му він звучить як запізнілий здоровий глузд.