Автор: Надалі. Підготовлено за допомогою ШІ.
Що змінилося
2 листопада GitHub переніс типове блокування події pull_request_target з 2 листопада на 2 грудня 2026 року. До цього заплановано два пробні вікна обмежень: 9 і 16 листопада, 16:00–18:00 UTC.
Правило стосується публічних репозиторіїв у GitHub Free, Team та Enterprise Cloud; приватні, внутрішні репозиторії й Enterprise Server не охоплені цим оголошенням.
Кому корисно: власникам бізнесу, чий сайт або застосунок обслуговує команда чи підрядник через публічний репозиторій. Це зміна графіка захисту автоматичних процесів, не нова ШІ-функція й не повідомлення про злам вашого сайту.
Чому робочий запуск ще не означає безпеку
Документація GitHub пояснює ризик: ця подія працює з довірою основного репозиторію та доступом до його секретів. Виконання неперевіреного коду із зовнішньої пропозиції змін у такому контексті може відкрити ці секрети.
Типова політика поки працює в режимі оцінювання: запуск може пройти, хоча після застосування правила його заблокують. Вона не замінює вже налаштовану застосовну політику подій. Не варто давати загальний дозвіл лише заради зеленого індикатора.
Що доручити відповідальному
Редакційний порядок дій Надалі:
- З’ясуйте, чи є у бізнесу публічні репозиторії та хто відповідає за їхні автоматичні перевірки. Відсутність власного технічного відділу не відповідає на це питання: репозиторій може вести підрядник.
- Попросіть короткий перелік залежних процесів: назва, призначення, відповідальний і наслідок зупинки. Не додавайте до такого документа паролі або ключі.
- За інструкцією керування виконанням, перегляньте Policy insights — записи про заблоковані або потенційно заблоковані запуски. Не змінюйте політики без технічної перевірки.
- До першого вікна погодьте рішення для кожного потрібного процесу та спосіб перевірки результату. Розробник має оцінити безпечніший спосіб запуску або обґрунтувати вузький виняток, а не механічно дозволити все.
- Зафіксуйте, хто перевірить роботу після зміни. Повідомлення «налаштували» не замінює підтверджений результат потрібного бізнес-процесу.
Межі та висновок
Надалі прочитала джерела 3 листопада, але не перевіряла клієнтські репозиторії, не запускала процеси й не змінювала налаштування. Доступність режимів власних політик залежить від плану; їх не слід плутати з описаною типовою політикою.
Висновок: використайте відтермінування для перевірки залежностей, а не як підставу відкласти безпеку до грудня.
Обкладинка — повторно використана концептуальна ШІ-ілюстрація Надалі, не інтерфейс GitHub і не доказ виконаної перевірки.
