Практичне посилення безпеки для дій GitHub

Головна » Python » Практичне посилення безпеки для дій GitHub

Дії GitHub стали фактичним механізмом CI/CD для репозиторіїв, розміщених на GitHub., що забезпечує роботу всього: від модульних тестів до розгортання у виробничому середовищі та змін у інфраструктурі. Ця зручність має серйозний компроміс: робочі процеси часто виконуються з широкими привілеями, обробляють потужні токени та секрети, а також можуть безпосередньо звертатися до виробничих систем. Якщо ви навмисно не захищаєте їх, ви фактично надаєте кожній неправильній конфігурації, помилці залежностей або скомпрометованому обліковому запису швидкий доступ до ваших конвеєрів та хмарних облікових записів.

Цей посібник охоплює широкий, ретельно продуманий контрольний список для повного захисту дій GitHub.як правильно обробляти секрети, уникати впровадження скриптів, блокувати токени та тригери, оцінювати дії третіх сторін, керувати запускачами та використовувати вбудовані функції безпеки, такі як сканування коду, OIDC, Dependabot та журнали аудиту. Мета полягає в тому, щоб об'єднати розрізнені найкращі практики, важко здобуті уроки з нещодавніх інцидентів та власні рекомендації GitHub щодо посилення захисту в єдиний практичний довідник, який можна застосовувати в реальних проектах.

Реальний профіль ризику дій GitHub

На загальних рисах, робочий процес дій GitHub — це просто YAML-файл під .github/workflows що визначає одне або декілька завдань, кожне з яких складається з кроків. Кроки можуть або виконувати команди оболонки, або викликати дії повторного використання, опубліковані GitHub або спільнотою. Робочі процеси запускаються такими подіями, як push-запити, pull-запити, активність задач, розклади або ручні відправлення.

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

• Артефакти, скомпільовані бекдором (бінарні файли, контейнери, пакети), які ви пізніше відправляєте клієнтам.
• Викрасти потужні довговічні токени та секрети з пам'яті, журналів, кешів або артефактів.
• Зловживання привілейованими хмарними ролями надано CI для розгортання додаткових послуг, зміни мережі або доступу до даних.
• Проекти з переробки отруєнь шляхом компрометації конвеєрів релізів з відкритим кодом та розповсюдження заражених троянами релізів.

Нещодавні реальні інциденти підкреслили, наскільки привабливим є GitHub Actions як платформа для атак.Зловмисники зловживали вразливими робочими процесами для впровадження криптомайнерів в опубліковані пакети, а популярні... tj-actions/changed-files Дія була скомпрометована в результаті багатоетапної атаки, спрямованої на спробу проникнути на Coinbase. Шкідливий код витягував секрети з робочих процесів та записував їх у журнали збірки, створюючи потенційний каскад подальших порушень ланцюга поставок.

Ключова ідея, яку слід пам’ятати, полягає в тому, що більшість атак GitHub Actions стосуються співвідношення «ймовірність × вплив».Ви хочете зменшити ймовірність використання шкідливих або помилкових компонентів (дій сторонніх розробників, небезпечних програм запуску, ризикованих тригерів) і водночас суттєво обмежити радіус вибуху, якщо будь-який окремий компонент буде скомпрометовано.

Блокування секретів у діях GitHub

Секрети зазвичай є найпривабливішою ціллю в будь-якій системі CI/CD.У діях GitHub вони відображаються як секрети репозиторію, організації або середовища, а також як спеціальні значення, які ви можете випадково додати до конфігурацій, журналів, кешів або артефактів.

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

Щоб зберегти секрети, які можна було б зберегти за цією моделлю, дотримуйтесь цих базових правил:

• Застосовуйте принцип найменших привілеївБудь-які облікові дані, що використовуються в робочому процесі, повинні мати лише мінімальні дозволи, які їм абсолютно необхідні. Уникайте спільного використання токенів адміністратора загального призначення як секретів робочого процесу.
• Надавати перевагу секретам середовища над секретами репозиторію чи організації для конфіденційних значеньСекрети середовища доступні лише для завдань, які декларують це середовище, і ви можете обгорнути їх додатковими захистами, такими як обов'язкові рецензенти та обмеження гілок.
• Ніколи не зберігайте секрети у відкритому тексті у YAML-файлах робочого процесу або в коді, що передається до репозиторію. Уся конфіденційна інформація має проходити через механізм секретів GitHub або зовнішній менеджер секретів.
• Уникайте використання структурованих блобів (JSON, YAML, XML) як єдиного секретного значенняМаскування значною мірою залежить від точного зіставлення рядків; багатополеві блоби набагато складніше надійно видалити. Натомість, розділіть конфіденційні дані на кілька спеціальних секретних записів.
• Явно зареєструйте всі похідні секретиЯкщо ви трансформуєте секрет (Base64, URL-кодування, підпис JWT тощо), і цей результат може коли-небудь потрапити в журнали, зареєструйте трансформоване значення як окремий секрет, щоб GitHub міг спробувати його замаскувати.

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

Уникнення впровадження скриптів та небезпечної інтерполяції

Одним із найпоширеніших, але водночас малопомітних, класів помилок у GitHub Actions є впровадження скриптів через вирази.GitHub надає багаті «контексти», такі як github, env, secrets та корисні навантаження подій, на які ви посилаєтесь у робочих процесах за допомогою ${{ ... }} синтаксис. Ці вирази оцінюються GitHub перед тим ваш крок оболонки виконується.

Коли ви вбудовуєте ненадійний контекст безпосередньо в команду оболонки, ви запрошуєте впровадження команди.Наприклад, якщо ви це зробите:

run: echo "new issue ${{ github.event.issue.title }} created"

і зловмисник може контролювати назву проблеми, вони можуть подати заголовок типу $(id)Після обчислення виразу крок стає таким:

echo "new issue $(id) created"

який виконує id на бігункуЖодна кількість налаштувань лапок чи додавання простої перевірки в оболонці не врятує вас від цього шаблону.

Безпечний шаблон, який рекомендує GitHub, — це використання проміжної змінної середовища:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Тут потенційно вороже значення залишається в пам'яті як змінна середовища, а оболонка бачить лише $TITLE, а не динамічно побудований командний рядок. Вам все ще потрібна звичайна гігієна оболонки (лапки змінних, уникнення непотрібних eval тощо), але небезпечний крок інтерполяції видалено.

Щоразу, коли у вас виникає спокуса вбудувати ${{ github.* }} або інші дані, контрольовані користувачем, безпосередньо в run: блоки, зупиніться та проштовхніть його env: замістьЦя одна звичка усуває цілий клас проблем із впровадженням скриптів у ваші робочі процеси.

Безпечне налаштування дозволів і токенів

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

Першим кроком посилення захисту має бути встановлення дозволів для маркера робочого процесу за замовчуванням на читання. на рівні організації та/або репозиторію. Для цього є спеціальний параметр у конфігурації «Дії». Звідти ви вибірково надаєте додаткові дозволи для кожного робочого процесу або завдання, наприклад:

permissions:
contents: read
pull-requests: write

Ця модель «заборонити за замовчуванням, дозволити, де потрібно» значно зменшує можливості зловмисника щодо скомпрометованого робочого процесу.Це також змушує авторів задуматися про те, які можливості насправді потрібні для їхньої роботи, замість того, щоб успадковувати універсальний токен.

Якщо вашу організацію було створено до початку 2023 року, вам слід чітко перевірити ці налаштування за замовчуванням.Багато старіших організацій досі мають токени робочого процесу з увімкненою можливістю запису, оскільки вони були створені раніше безпечнішого стандартного режиму та ніколи не погоджувалися на цю зміну.

Окрім областей видимості токенів, будьте дуже обережні з налаштуваннями, які дозволяють GitHub Actions схвалювати або створювати пул-реквести.Дозвіл робочим процесам затверджувати PR-запит відкриває шляхи зловживання, коли скомпрометовані завдання об’єднують шкідливий код без перевірки людиною. Якщо у вас немає вагомого варіанту використання та суворих захисних бар’єрів, вимкнути цю функцію.

Вибір та закріплення дій третіх сторін

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

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

• Почніть з невеликого, перевіреного білого спискуДії, що підтримуються GitHub (наприклад actions/checkout, actions/setup-node) та дії на торговельному майданчику від перевірених авторів зазвичай є безпечнішою основою, ніж випадкові репозиторії. Багато організацій забезпечують це за допомогою опції «Дозволити вказані дії та робочі процеси повторного використання» на рівні організації.
• Надавати перевагу популярним, активно підтримуваним діямДослідження показують, що багато дій на торговельному майданчику мають низькі оцінки OpenSSF Scorecard, єдиних розробників та короткочасні або дуже молоді облікові записи власників. Широко використовувані дії, як правило, потребують більшої уваги та швидших виправлень.
• Слідкуйте за великою кількістю відкритих PR-запитів Dependabot у репозиторії дії.Це часто ознака того, що розробник не застосовує оновлення безпеки, залишаючи транзитивні вразливості невиправленими.
• Надавати перевагу діям з кількома розробниками та неархівованою, активною кодовою базоюСотні дій на ринку архівуються, що означає відсутність нових виправлень чи оновлень сумісності та зростання ризику з часом.

Закріплення версій – ще одна важлива темаЯкщо ви вказуєте дію лише за тегом, наприклад some-org/some-action@v2, ви довіряєте, що цей тег ніколи не переміститься до шкідливого коду. Теги можна перенаправити, якщо обліковий запис адміністратора або репозиторій скомпрометовано.

Найбільш захисним підходом сьогодні є закріплення на повному SHA-коміті.:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Закріплення до SHA робить код фактично незмінним з вашої точки зору. (якщо не враховувати атаку SHA-1 на об'єкти Git через колізію). Недоліком є ​​операційна складова: вам потрібно оновлювати SHA, коли потрібні нові функції або виправлення, а різні робочі процеси можуть переходити до різних SHA, якщо ви не будете обережні.

Щоб полегшити цей дискомфорт, деякі команди централізують використання дій третіх сторін у спільних або складених робочих процесах.Окремі репозиторії посилаються на ці спільні робочі процеси за допомогою тегу, тоді як спільні робочі процеси закріплюють базові дії за перевіреними SHA та оновлюються з контрольованою частотою, іноді за допомогою інструментів, які відкривають PR для нових SHA.

Яку б стратегію ви не обрали, пам’ятайте, що закріплення — це не чарівний брандмауер.Дія все ще може динамічно отримувати код під час виконання (наприклад, через curl | bash шаблони) та обійти свій PIN-код. Вам все одно потрібно перевірити джерело на наявність явно небезпечних шаблонів, перш ніж довіряти дії із секретами або токенами, придатними для запису.

Розробка безпечніших робочих процесів та завдань

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

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

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

На серверах, розміщених на GitHub, кожне завдання в робочому процесі виконується в новій віртуальній машині., що забезпечує певний ступінь ізоляції між завданнями. Це не еквівалентно захищеній пісочниці, і існують відомі вектори перехресного розподілу завдань (наприклад, спільні кеші гілок), але розділення завдань все одно змушує зловмисників працювати інтенсивніше та зменшує випадковий витік секретів на непов'язані кроки.

Використовуйте середовища, щоб пов’язати конфіденційні кроки із захистомЗавдання розгортання може оголосити:

environment: production

і production середовище можна налаштувати так, щоб воно приймало розгортання лише із захищеної гілки., можливо, з обов'язковими ручними погодженнями. Поєднання цього зі суворими правилами захисту гілок (обов'язкові перевірки, відсутність перемотування, відхилення застарілих погоджень) наближає вас до принципу «чотирьох очей» для змін у виробництві.

Зрештою, будьте обережні з артефактами, кешами та журналамиЦе зручні способи обміну даними між завданнями та робочими процесами, але:

• Не об'єднуйте секрети в кеші, особливо не такі відомі місця, як ~/.docker/config.json які можуть містити прості облікові дані Docker.
• Уникайте логування секретів або запису цілих контекстів у журнали, оскільки це може перешкодити маскуванню або розкрити похідні значення, які GitHub не знає, що потрібно редагувати.
• Пам’ятайте, що будь-хто з доступом на читання до репозиторію зазвичай може завантажувати артефакти та переглядати журнали., включаючи зовнішніх співробітників, якщо ви надасте їм доступ.

OIDC та короткочасні хмарні облікові дані

Одна з найефективніших змін, яку ви можете внести, — це повне припинення зберігання довготривалих облікових даних постачальника хмарних послуг як секретних даних GitHub.Натомість використовуйте OpenID Connect (OIDC), щоб отримати короткочасні, чітко визначені токени, прив’язані до певного ідентифікатора робочого процесу.

Потік високого рівня простий:

• Ваш хмарний постачальник (AWS, Azure, GCP тощо) налаштований на довіру до постачальника OIDC GitHub.
• Ви визначаєте політику ідентифікації, яка говорить «приймати токени лише з цієї організації/репозиторію/гілки або середовища».
• Під час виконання завдання GitHub може запитувати токен OIDC, а ваш робочий процес використовує дію, специфічну для хмари (наприклад aws-actions/configure-aws-credentials) щоб обміняти це на короткочасну роль або токен облікового запису служби.

Умова довіри – це те, де можна отримати дуже детальну інформаціюДля AWS типова політика може включати:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Це гарантує, що роль можуть виконувати лише робочі процеси з певного репозиторію та гілки.Якщо вам потрібне ще точніше визначення області застосування, ви можете прив’язати роль до певного середовища, а не до гілки, а потім вимагати це середовище лише для завдання розгортання. Скомпрометована дія третьої сторони в завданні, що не пов’язане з розгортанням, призведе до того, що виклики OIDC просто завершаться невдачею.

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

Захист гілок, набори правил та середовища, що працюють разом

Багато страшних шляхів атаки в GitHub Actions зводяться до «зловмисник впроваджує шкідливі зміни в захищену гілку».Захист гілок та набори правил – це ваша основна лінія захисту там.

На гілках, як main or production, зазвичай ви хочете принаймні:

• Вимагати запит на злиття перед об'єднанням – заборонити прямі натискання.
• Вимагати принаймні одного (часто більше) схвалювального відгуку від когось іншого, ніж від останнього штовхача.
• Відхиляти застарілі схвалення, коли додаються нові коміти – щоб зловмисники не могли підкрастися в код після перевірки.
• Вимагати схвалення останнього переглядуваного push-повідомлення – запобігає зловмиснику захопити чужий PR, розповсюдити поганий код та самосхвалити себе.

Потім ви можете підключити ці засоби захисту до середовищ. Наприклад, a production середовище може приймати розгортання лише з main гілка, а також, можливо, вимагатимуть ручного схвалення від невеликої групи рецензентів (з увімкненою опцією «запобігання самостійному рецензуванню»). Таким чином, один скомпрометований обліковий запис учасника не може відправити довільний код у продакшн без явної участі когось іншого.

Будьте обережні з правилами середовища, які залежать від самих розгортань (наприклад, «вимагати успішного розгортання перед дозволами на оновлення тегів»). Якщо структуровано неправильно, можна створити циклічні залежності або псевдо-елементи керування, які співавтор може обійти, редагуючи робочі процеси. Найбезпечнішим шаблоном залишається: сильний захист гілок → вузько обмежені середовища → явне використання цих середовищ лише в мінімальних завданнях, які їх дійсно потребують.

Керування запусками: розміщення на GitHub проти самостійного розміщення

Бігуни – це машини, які фактично виконують ваші робочі процесиРозміщені на GitHub раннери — це тимчасові віртуальні машини, якими керує GitHub; самостійно розміщені раннери — це машини або контейнери, якими ви займаєтесь та керуєте.

Раннери, розміщені на GitHub, зазвичай набагато безпечніші за замовчуванням:

• Вони тимчасові та скидаються для кожного завдання, тому немає постійного компромісу між запусками.
• GitHub публікує SBOM для стандартних образів (Ubuntu, Windows, macOS), що дозволяє аналізувати попередньо встановлене програмне забезпечення на наявність вразливостей.
• Деякі шкідливі хости блокуються "з коробки". (наприклад, відомі пули криптомайнінгу) через /etc/hosts configuration.

Бігуни, яких самостійно розміщують, потужні, але небезпечні якщо ви не ставитеся до них як до виробничих серверів:

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

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

• Публічні та приватні проекти ніколи не використовують один і той самий пул учасників.
• Високочутливі репозиторії (наприклад, виробнича інфраструктура) мають власні жорстко контрольовані виконавці.
• Тільки певні репозиторії або організації можуть надсилати завдання до певної групи.

Ви можете ще більше зменшити ризик за допомогою JIT-виконавців, що надаються через REST API.Ці програми-виконавці реєструються динамічно, запускають максимум одне завдання, а потім автоматично видаляються. Вам все одно потрібно переконатися, що базовий хост очищено або знищено, але це звужує вікно, протягом якого скомпрометоване завдання може вплинути на наступні.

Ставтеся до самостійно розміщених раннерів як до будь-якої іншої виробничої системи: моніторити активність процесів, блокувати вихідні мережеві шляхи, оновлювати ОС та інструменти, а також припускати, що будь-який користувач з дозволом на запуск робочих процесів фактично виконує код на цьому комп'ютері.

Вбудовані функції безпеки: сканування коду, картки показників та Dependabot

GitHub пропонує низку першокласних функцій, спеціально спрямованих на виявлення ризиків, пов'язаних з робочим процесом та залежностями., і вони варті невеликої вартості встановлення.

Сканування коду (наприклад, за допомогою CodeQL) тепер може аналізувати самі робочі процеси GitHub Actions., а не лише джерело вашої програми. Такі правила, як «Надмірне розкриття секретів», можуть виявляти закономірності, коли GitHub не може визначити, які секрети є обов’язковими (наприклад, динамічні secrets[myKey] використання в матричних збірках), що призводить до завантаження в пам'ять завдань більшої кількості секретів, ніж необхідно.

Картки показників OpenSSF та дія «Картки показників» додають ще один рівень, оцінюючи рівень безпеки ваших залежностей.Для дій на ринку, Системи показників можуть позначати небезпечні практики ланцюга поставок, такі як:

• Не закріплення залежностей.
• Відсутні захист гілок або вимоги до перевірки коду.
• Відсутність політики безпеки або процесів реагування на вразливості.

Dependabot грає тут дві ролі:

• Сповіщення Dependabot попереджати вас, коли залежність ваших дій або робочих процесів має відому вразливість, на основі бази даних GitHub Advisory Database.
• Версія Dependabot та оновлення безпеки може автоматично відкривати PR-запитів для посилення версій та виправлень вразливих релізів.

Граф залежностей для робочих процесів – ще одна недооцінена функціяGitHub обробляє ваші файли робочого процесу як маніфести та може показати вам:

• Від яких дій та робочих процесів повторного використання ви залежите.
• Яким обліковим записам або організаціям вони належать.
• До яких версій або SHA ви прикріпили дані.

Це полегшує відповіді на запитання на кшталт «Де ми використовуємо цю скомпрометовану дію?» коли з’являються нові рекомендації, а також планувати масові виправлення.

Моніторинг, аудит та управління

Безпека не обмежується налаштуванням; вам також потрібна видимість того, що відбувається з часомGitHub надає журнали аудиту та журнали безпеки як на рівні користувачів, так і на рівні організації.

З точки зору дій, є кілька речей, які варто відстежувати:

• Події, пов'язані з таємницями, Такі, як org.update_actions_secret або зміни секрету репозиторію. Вони вказують на створення, оновлення або видалення конфіденційних облікових даних.
• Зміни в робочому процесі та наборі правилхто змінював правила захисту, хто редагував робочі процеси розгортання, хто змінював захист середовища.
• Нові або змінені дії на ринку та програми GitHub встановлені в організації, особливо ті, яким надано широкі репозиторні або організаційні області дії.

Ви можете доповнити власні елементи керування GitHub за допомогою програм для забезпечення дотримання політик, таких як Allstar від OpenSSF., який постійно перевіряє відповідність репозиторіїв базовим стандартам безпеки вашої організації (захист гілок, увімкнене сканування коду, необхідні перевірки тощо).

Щодо «виконання робочих процесів», слідкуйте за закономірностями, які можуть свідчити про зловживання.: незвичайні сплески часу виконання завдань, неочікуваний вихідний трафік від виконавців або часті збої завдань навколо кроків, що обробляють секрети або токени OIDC. Це не завжди зловмисні дії, але саме з них варто почати розслідування.

Поєднання всього цього означає, що дії GitHub є частиною вашої основної робочої поверхні., а не просто «склейувальні скрипти». Завдяки ретельно визначеним секретам і токенам, суворому захисту гілок і середовищ, консервативному використанню дій сторонніх розробників, захищеним запускачам і постійному моніторингу за допомогою таких інструментів, як CodeQL, Scorecards і Dependabot, ви даєте своїй організації шанс протистояти зростаючому класу атак CI/CD і ланцюгів поставок, які явно спрямовані на самі робочі процеси GitHub.