Коротко: у березні 2026 GitHub випустив REST API версію 2026-03-10 — це перша календарна версія з breaking changes. Паралельно GitHub Actions отримав підтримку repo_property_* у OIDC-токенах, що дозволяє перейти від ручних allow-list до ABAC в AWS/Azure/GCP. Хороша новина: обидві задачі реально закрити за один спринт, якщо почати з інвентаризації і йти поетапно.

Що саме змінилося і чому це важливо

1) REST API 2026-03-10 уже в проді

GitHub офіційно оголосив нову версію REST API (2026-03-10) і підтвердив: це перший календарний реліз із несумісними змінами. Запити без заголовка X-GitHub-Api-Version далі за замовчуванням ідуть на 2022-11-28, але відкладати міграцію — погана ідея: техборг лише росте.

2) Є реальні точки поломки для інтеграцій

Серед змін, які найчастіше «стріляють» у проді:

Якщо ваш код жорстко парсить конкретну форму JSON, ризик інциденту дуже практичний.

3) OIDC custom property claims відкривають нормальний ABAC

Тепер org/enterprise адміністратори можуть додавати repository custom properties у OIDC claims. У токені вони зʼявляються як repo_property_<назва>. Це дозволяє видавати cloud-доступ не «цьому списку реп», а «репозиторіям із певними атрибутами» — наприклад environment=prod, data_class=internal, workspace_id=....

Результат: менше ручної рутини, менше configuration drift, швидший онбординг нових репозиторіїв.

Практичний план на 7 днів (один спринт)

День 1: інвентаризація і мапа ризиків

  1. Зберіть список усіх інтеграцій, що викликають GitHub REST API.
  2. Для кожної інтеграції зафіксуйте:
    • критичність (бізнес-вплив),
    • власника,
    • чи встановлюється X-GitHub-Api-Version,
    • які endpoint-и і поля реально використовуються.
  3. Позначте «крихкі» місця: ручний парсинг, strict schema, кастомні ретраї, жорсткі перевірки status code.

Артефакт дня: таблиця integration -> owner -> risk -> migration status.

День 2–3: тестовий прогін із новою версією API

  1. У staging/canary примусово задайте X-GitHub-Api-Version: 2026-03-10.
  2. Проганяйте контрактні тести і перевіряйте payload diff на критичних endpoint-ах.
  3. Виправляйте парсинг:
    • не покладатися на видалені поля,
    • коректно обробляти нові типи,
    • не «падати» від зміни неключових атрибутів.

Go/No-Go критерій: 0 критичних помилок у canary + стабільні SLI (error rate/latency).

День 4: захист від повторної поломки

  1. Додайте smoke/contract тести, які запускаються на кожному PR.
  2. Зробіть алерт, якщо API-запит іде без X-GitHub-Api-Version.
  3. Впровадьте fallback-логіку для неочікуваних полів/enum значень.

Мета: наступна міграція не повинна бути «аварією вручну».

День 5: OIDC модель атрибутів

  1. Визначте 3-5 org-level custom properties, які реально керують доступом (наприклад: environment, business_unit, data_class, workspace_id).
  2. Налаштуйте включення цих властивостей у OIDC claims.
  3. Переконайтеся, що репозиторії мають коректно заповнені значення.

День 6: ABAC-політики у хмарі

  1. Оновіть trust policy у хмарі так, щоб вона перевіряла repo_property_* claims.
  2. Приберіть дублюючі allow-list, які вже не потрібні.
  3. Перевірте 2 сценарії:
    • легітимний репозиторій отримує доступ;
    • репозиторій із неправильним атрибутом — ні.

День 7: staged rollout у прод і контрольний зріз

  1. Перемкніть на 2026-03-10 спочатку 10-20% інтеграцій.
  2. Моніторте помилки, статус-коди, бізнес-метрики.
  3. Розширте rollout до 100%, якщо немає регресій.
  4. Зафіксуйте пост-релізний звіт: що змінили, що відклали, які ризики залишились.

Мінімальні guardrails та rollback

Щоб не «тушити пожежу» вночі, домовтеся про прості правила:

Типові помилки команд (і як не наступити)

  1. “Поставимо нову API-версію одразу всюди”
    Ризик: масовий інцидент без локалізації.
    Краще: canary + staged rollout.

  2. “Залишимо старі allow-list, ABAC потім”
    Ризик: подвійна модель доступу й хаос у правах.
    Краще: короткий перехідний період і планове прибирання дублювань.

  3. “Поля в JSON стабільні назавжди”
    Ризик: крихкий парсер падає від дрібної зміни.
    Краще: tolerant parsing + контрактні тести на критичні поля.

Висновок

Окремо міграція API і окремо hardening доступу виглядають як дві великі задачі. Разом — це один нормальний інженерний спринт: спочатку сумісність (X-GitHub-Api-Version: 2026-03-10), далі керований ABAC через repo_property_* claims. Після цього менше ризику «зламати інтеграції», менше ручної рутини в доступах, і краще масштабування нових репозиторіїв.

Офіційні джерела: