# GitHub Actions отримав lockfiles: supply-chain security без pin-хаосу

> Workflow dependency lockfiles у public preview: читабельні теги в YAML, виконання точних commits через .github/workflows/actions.lock, транзитивні actions і автооновлення Dependabot. Розбираємо механізм і межі.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: Backend і System Design
- Canonical: https://cookiesoftware.io/blog/github-actions-lockfiles

---

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 у твоєму репозиторії тримається на рядках типу:

```yaml
uses: some/action@v3
```

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

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

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

```yaml
uses: some/action@8f4b7f84864484a7bf31766abe9204da3cbe65b3
```

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

## Як працює lockfile

За [офіційним анонсом](https://github.blog/changelog/2026-10-14-github-actions-workflow-lockfiles-in-public-preview/), механіка така:

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](/blog/nodejs-permission-model): політика, прописана в правилах чи промптах, – це побажання; політика, зафіксована механізмом, – це інженерія.

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

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

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

## Перевір свої 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-му він звучить як запізнілий здоровий глузд.