GitHub тихо підкрутив безпеку репозиторіїв: більше секретів, сильніший push protection і кращий CodeQL

Коротко: GitHub непомітно підняв базову планку безпеки репозиторіїв. Додав нові детектори для секретів, підкрутив push protection і зробив CodeQL кориснішим для гілок, які реально живуть у команді, а не тільки для default branch. Це не «ще одна галочка в адмінці». Це шанс зловити витік раніше, ніж токен опиниться в логах, issue або в чужому форку.

Що саме змінилося

У березні GitHub привіз одразу кілька практичних оновлень для тих, хто зберігає код, CI і інфраструктуру в одному місці.

Перше — Secret scanning отримав дев’ять нових типів секретів і додаткові перевірки валідності для npm. Це означає, що GitHub краще відрізняє справжній токен від випадкового рядка і частіше ловить те, що раніше могло прослизнути повз.

Друге — Push protection для частини провайдерів стає жорсткішим і кориснішим за замовчуванням. У людському перекладі: шанс випадково закомітити секрет усе ще існує, але тепер платформа частіше скаже “стоп, це схоже на ключ” ще до того, як зміни підуть у віддалений репозиторій.

Третє — CodeQL у security overview почав показувати дані для всіх Protected branches, а не тільки для default branch. Це важливо, бо в реальних командах ризик часто живе не в main, а в release-, hotfix- або maintenance-гілках, куди дивляться значно рідше.

Чому це важливо звичайним командам

Більшість витоків не виглядає як кіберпанк-інцидент. Ніхто не приходить із капюшоном у серверну. Частіше це банальний секрет у YAML, токен у тестовому конфігу, ключ у PR-коментарі або service account, який випадково поїхав у форк.

Для маленьких і середніх команд проблема ще простіша:

• репозиторії ростуть швидше, ніж дисципліна;
• секрети розкидані між кодом, workflow, docs і issue templates;
• люди часто працюють у кількох гілках одночасно;
• безпечні налаштування є, але їх ніхто не перевіряв після першого увімкнення.

Оновлення GitHub корисні саме тут: вони не вирішують усе автоматично, але зменшують кількість місць, де можна тихо промахнутися.

Що перевірити за 20 хвилин

Ось короткий аудит, який можна зробити без великого рев’ю всього портфеля.

1. Визнач критичні репозиторії

Спочатку випиши 5–10 репозиторіїв, де найбільше шкоди від витоку:

• основний продукт;
• інфраструктура;
• CI/CD;
• automation-репозиторії;
• будь-які репозиторії, де є доступ до хмари, registry або білд-систем.

Якщо список не можеш скласти за 2 хвилини — це вже сигнал, що карта ризиків у команди не дуже чітка.

2. Перевір secret scanning

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

Зверни увагу:

• чи немає репозиторіїв, які “випали” з контролю;
• чи охоплюються токени саме тих провайдерів, які використовує команда;
• чи видно recent alerts, а не тільки порожню сторінку з green badge.

3. Перевір push protection

Тут важливе не просто “enabled”, а реальна поведінка.

Питання, які варто поставити:

• чи блокує GitHub пуш із секретом до основних репозиторіїв;
• чи знають люди, що робити, якщо блок спрацював;
• чи не перетворився bypass на звичний “ну я зараз один раз обійду”.

Якщо bypass використовують часто, значить проблема не в GitHub, а в робочому процесі.

4. Відкрий CodeQL / Security Overview

Перевір, чи бачиш ти тільки default branch, чи вже всі protected branches.

Це особливо важливо для:

• release-гілок;
• hotfix-галужень;
• довгоживучих maintenance-branch;
• репозиторіїв із кількома одночасними лініями розробки.

Якщо дані є лише по main, частина картини просто ховається.

5. Пройдися по місцях, де секрети люблять ховатися

Класичні схованки:

• .github/workflows/*;
• .env і sample .env;
• README з прикладами;
• issue templates і docs;
• тестові конфіги;
• коментарі в PR або commit message.

GitHub ловить багато, але не все. Особливо якщо команда любить зберігати “тимчасові” речі трохи довше, ніж планувала.

Що не робити

• Не вважати, що зелений badge = безпека.
• Не відкладати перевірку protected branches, бо “ми ж дивимось лише main”.
• Не використовувати bypass push protection як нормальний шлях роботи.
• Не думати, що secret scanning заміняє секрет-менеджер.
• Не залишати перевірку на один раз на рік після чергового інциденту.

Коли GitHub змінив правила гри

Є тонкий, але важливий момент: ці оновлення мають сенс лише якщо команда їх помітила і налаштувала під себе.

Наприклад:

• нові детектори корисні, якщо ваш стек реально використовує ті самі провайдери;
• push protection корисний, якщо люди знають, як працювати без обходів;
• CodeQL корисний, якщо ви дивитесь не лише на головну гілку, а на весь життєвий цикл змін.

Інакше вийде класична історія: функція є, а профітів немає.

Практичний висновок

Якщо коротко, GitHub зробив вашу базову репозиторну безпеку трохи розумнішою. Але це не заміна процесу — це підсилювач процесу.

Найкращий наступний крок сьогодні:

1. вибрати критичні репозиторії;
2. перевірити secret scanning і push protection;
3. відкрити CodeQL для всіх protected branches;
4. прибрати місця, де секрети можуть лежати без потреби;
5. домовитися, хто реагує, якщо push protection спрацює.

Якщо зробити це зараз, а не коли вже щось витекло, GitHub вперше за довгий час справді економить вам нерви, а не тільки видає ще один security report.