До основного вмісту

Питання й відповіді · Безпека

Кожен інструмент для розробників хоче доступ до нашої GitHub-організації. Як вирішити, кому довіряти?

Кожен постачальник у вашому стеку в перший же день просить одне й те саме. Ось як ми вирішували б, хто це отримає.

Купа старих залізних ключів, перев’язаних мотузкою.
Кожна інтеграція — ще один ключ у зв’язці. Фото: Wikimedia Commons, CC0.

Команда Nythrex · 29.10.2026

Питання

Питає інженерний менеджер · так, як ми його зазвичай чуємо

«Наш спеціаліст з безпеки тепер за замовчуванням блокує нові інтеграції з GitHub. Я розумію чому, але кілька з них нам справді потрібні. Чи є адекватний чекліст, який не зводиться до „відмовляти всім“?»

Коротка відповідь

Оцінюйте кожен інструмент за трьома речами: що він читає, що зберігає і що отримає зловмисник, якщо зламають постачальника. Віддавайте перевагу доступу лише на читання, найвужчому обсягу дозволів, відсутності вмісту коду, якщо він справді не потрібен для роботи, і токенам, які можна відкликати в одному місці. Інструмент, що ніколи не отримує ваш код, не може його злити.

Два інциденти, які варто пам’ятати

Квітень 2022. GitHub виявив, що зловмисник використовує викрадені OAuth-токени користувачів, видані двом інтеграторам — Heroku і Travis CI, — щоб переглядати організації й завантажувати приватні репозиторії десятків організацій, серед них npm. GitHub вважав, що зловмисник шукав у завантаженому коді секрети для доступу до іншої інфраструктури. Токени викрали не з GitHub — їх викрали з інтеграцій.

Березень 2025. Зловмисники перенаправили теги версій популярної GitHub Action tj-actions/changed-files на шкідливий коміт, який виводив секрети CI в логи workflow. Цю action використовували понад 23 000 репозиторіїв. Інцидент отримав номер CVE-2025-30066 і був виправлений у v46.0.1. Команди, які закріпили action за SHA коміту, не постраждали від перенаправлених тегів.

Масивні двері сховища Bowery Savings Bank із круглими засувами, фото 1923 року.
Міцні двері важать менше, коли копії ключа зберігаються деінде. Фото: Architecture and Building, 1923, суспільне надбання.

П’ять питань до будь-якої інтеграції

Чекліст для надання доступу до GitHub-організації
ПитанняДобра відповідьТривожний сигнал
Що йому потрібно читати?Лише читання, і тільки репозиторії, з якими він працюєЗапис чи права адміністратора «про всяк випадок»
Чи отримує він код, диффи чи промпти?Лише якщо цього вимагає його роботаІнструмент для метрик, що копіює цілі репозиторії
Де і як зберігаються дані?Названий регіон, шифрування, перелік субпроцесорів«У хмарі»
Як зберігаються й відкликаються токени?Зашифровані, відкликаються з одного місцяЧіткої відповіді немає
Що буде, коли людина піде?Її доступ закінчується разом із членствомОсобисті токени продовжують працювати

Що ми зробили б цього кварталу

  1. 1

    Перелічіть, у кого вже є доступ

    Складіть список OAuth-застосунків і GitHub Apps, встановлених в організації, і того, хто їх авторизував. Більшість команд знаходить щось, чим ніхто не користується.
  2. 2

    Обирайте вузький доступ, який можна відкликати

    Віддавайте перевагу інтеграціям, що просять доступ лише на читання до конкретних репозиторіїв, а не широкі токени користувача.
  3. 3

    Закріплюйте сторонні Actions

    Посилайтеся на Actions за SHA коміту, а не за тегом, який можна перемістити, — урок tj-actions.
  4. 4

    Просіть опис потоку даних письмово

    Що інструмент отримує, що зберігає, де і як довго. Постачальник, який не може відповісти на одній сторінці, про це не думав.
  5. 5

    Переглядайте й відкликайте

    Раз на квартал видаляйте те, чим не користуються. Найбезпечніша інтеграція — та, якої у вас уже немає.

Де допомагає Nythrex — і де ні

  • Як він влаштований

    Nythrex має доступ лише на читання до кожного джерела і отримує метадані комітів і pull request-ів — SHA, автора, час, гілки, розмір зміни, — а не вміст коду, диффи, файли чи промпти. OAuth-токени зберігаються зашифрованими з ключами в Azure Key Vault, дані — в Azure Poland Central (ЄС), а видалення учасника відкликає його токени AI-інструментів.
  • Чого він не заявляє

    Nythrex не заявляє про сертифікацію SOC 2 чи ISO 27001. Сторінка безпеки перелічує заходи, які реально працюють у продукті, а для питань безпеки можна домовитися про дзвінок.

Що саме отримує Nythrex

Часті питання

Як вирішити, чи давати інструменту доступ до нашої GitHub-організації?

Перевірте, що йому потрібно читати, чи отримує він код, диффи чи промпти, де і як зберігає дані, як зберігаються й відкликаються його токени і що відбувається, коли учасник іде з команди. Віддавайте перевагу доступу лише на читання до конкретних репозиторіїв.

Що сталося з tj-actions/changed-files?

У березні 2025 року зловмисники перенаправили теги версій GitHub Action tj-actions/changed-files на шкідливий коміт, який виводив секрети CI в логи workflow. Цю action використовували понад 23 000 репозиторіїв; інцидент отримав номер CVE-2025-30066 і був виправлений у v46.0.1.

Чи читає Nythrex наш вихідний код?

Ні. Nythrex має доступ лише на читання й отримує метадані комітів і pull request-ів: SHA, автора, час, гілки й розмір зміни. Вміст коду, диффи, файли чи промпти він не отримує.

Перестаньте вгадувати.
Почніть бачити.

Без картки й без підписки: платні тарифи ще не запущені.

Створити акаунтБез картки й підписки