GitHub OIDC для private registries: як прибрати довгоживучі secrets у Dependabot і code scanning

Зачіпка

GitHub розширив OIDC для org-level private registries: тепер Dependabot і code scanning можуть працювати з Cloudsmith та Google Artifact Registry без довгоживучих registry secrets.

Це не косметичний security toggle. Якщо automation не бачить приватні залежності, Dependabot гірше оновлює пакети, а code scanning default setup може пропустити частину data flow і дати false negative.

Проблема / Контекст

У багатьох командах приватні пакети живуть окремо від коду: npm-пакети в Cloudsmith, Docker-образи в Google Artifact Registry, Maven або NuGet артефакти у внутрішньому registry. Розробники це знають, CI це знає, але security automation часто дізнається останньою.

Типова історія така:

Dependabot має доступ до публічних залежностей, але не може нормально пройти приватні пакети;
code scanning default setup аналізує репозиторій, але не бачить частину залежностей;
команда додає token або username/password у GitHub secrets;
через кілька місяців уже ніхто не пам’ятає, хто власник токена, коли його міняти і які репозиторії ним користуються.

OIDC міняє модель. Замість того щоб зберігати довгоживучий secret у GitHub, ви налаштовуєте trust relationship між провайдером registry і GitHub. Потім GitHub security feature отримує short-lived credential тільки для конкретної задачі.

19 травня 2026 GitHub додав у цю схему Cloudsmith і Google Artifact Registry на org-level. Поруч із уже підтриманими AWS CodeArtifact, Azure DevOps Artifacts і JFrog Artifactory це робить OIDC реальним варіантом для більшої частини сучасного supply-chain.

Чому це важливо

Довгоживучий secret - це зручність, яка з часом стає боргом. Його можна скопіювати, випадково розширити на зайві репозиторії, забути в org secret або не відкликати після зміни команди.

Для Dependabot проблема практична: без доступу до private registry він не бачить повну картину залежностей. Ви можете отримувати менше оновлень або дивні помилки в update jobs.

Для code scanning ризик тонший. GitHub docs прямо пояснюють: якщо default setup не має доступу до приватних dependencies, аналіз може не побачити частину шляхів data flow. У звіті все виглядатиме спокійно, але частина коду фактично не була проаналізована з повним контекстом.

Тому питання не “чи гарно було б прибрати secrets”. Питання таке: чи ваші security tools бачать те саме dependency-середовище, в якому реально живе продукт.

Як це зробити

1. Почніть з інвентаризації

Не відкривайте GitHub settings одразу. Спершу складіть маленьку таблицю:

registry | provider | ecosystem | consumers | current auth | repositories

Приклад:

frontend-npm | Cloudsmith | npm | Dependabot | org secret | web, admin
backend-images | Google Artifact Registry | docker | Dependabot | token | api
java-libs | private Maven | code scanning default setup | token | billing

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

2. Розділіть Dependabot і code scanning

У GitHub тут два близькі, але не однакові сценарії.

Dependabot може брати доступ до private registries через конфіг залежностей і через organization-level registry configuration. Його перевірка проста: update job має пройти, dependency PR має відкритися, а в логах не має бути auth-помилок.

Code scanning default setup працює інакше. Йому доступ потрібен для кращого аналізу, особливо коли частина важливого коду або залежностей лежить у приватних registry. У GitHub docs для default setup окремо вказано, що registry access потрібен для ефективної роботи, якщо repository uses code stored in a private registry.

Практично це означає: не міряйте успіх тільки зеленим Dependabot PR. Після registry change перевірте, чи default setup справді має потрібний доступ, і за потреби перепідніміть або переоцініть configuration для репозиторіїв, де аналіз залежить від приватних пакетів.

3. Для Cloudsmith підготуйте три поля

Для Cloudsmith OIDC потрібні:

registries:
  cloudsmith-npm:
    type: npm-registry
    url: https://dl.cloudsmith.io/MY-NAMESPACE/MY-REPOSITORY/npm/
    namespace: MY-NAMESPACE
    service-slug: MY-SERVICE-SLUG
    audience: https://github.com/GITHUB-ORG

На стороні GitHub REST API це відповідає auth type oidc_cloudsmith. Ключові поля: namespace, service_slug, audience. api_host можна вказати окремо, якщо у вас нестандартний endpoint.

Не підставляйте сюди особистий токен “на хвилинку”. Якщо trust relationship ще не готовий, зафіксуйте blocker і доробіть provider-side частину. Напів-OIDC із запасним довгоживучим token швидко перетворюється на стару проблему з новою назвою.

4. Для Google Artifact Registry перевірте Workload Identity

Для Google Artifact Registry мінімум такий:

registries:
  gcp-artifact-registry:
    type: docker-registry
    url: https://REGION-docker.pkg.dev
    workload-identity-provider: projects/PROJECT-NUMBER/locations/global/workloadIdentityPools/POOL/providers/PROVIDER
    service-account: github-registry-reader@PROJECT-ID.iam.gserviceaccount.com

У REST API це oidc_gcp. Обов’язкове поле - workload_identity_provider. service_account і audience залежать від вашої Google Cloud схеми.

Найчастіша помилка тут не в GitHub, а в IAM: provider існує, але service account не має мінімального read-доступу до потрібного Artifact Registry repository. Перевіряйте не “чи OIDC налаштований”, а “чи конкретний GitHub consumer може прочитати конкретний registry”.

5. Обмежте visibility

Organization-level configuration не означає “дати всім усе”. GitHub REST API підтримує visibility all, private або selected. Для rollout беріть selected, якщо немає сильної причини робити ширше.

Нормальний rollout:

вибрати один registry і 1-2 репозиторії;
додати OIDC registry configuration;
запустити Dependabot job або дочекатися планового run;
перевірити code scanning default setup там, де це релевантно;
тільки після цього прибирати старий secret;
розширювати visibility поступово.

Поки перевірка не пройшла, старий secret краще не видаляти. Але й залишати його назавжди не можна: після успішного cutover заплануйте removal і rotation, щоб GitHub secrets не стали архівом історичних токенів.

6. Пам’ятайте про незмінний auth type

У GitHub REST API є важлива деталь: auth type для private registry configuration не змінюється після створення. Якщо треба перейти з token на oidc_gcp або oidc_cloudsmith, зазвичай доведеться видалити й створити configuration заново.

Це ще один аргумент за маленький rollout. Спочатку перевірте одну конфігурацію, назву, URL, visibility і provider fields. Потім масштабуйте.

Антипатерни

видавати org-level registry access усім репозиторіям без інвентаризації;
залишати старий long-lived secret після успішного OIDC rollout;
вважати зелений Dependabot PR доказом, що code scanning теж має повний контекст;
створювати OIDC configuration до того, як provider-side trust relationship реально готовий;
плутати OIDC для GitHub Actions workflows із OIDC для GitHub security features;
ігнорувати GitHub Enterprise Server версію, якщо команда не на github.com;
змінювати одразу всі registry configurations без rollback-плану.

Висновок / План дій

OIDC для private registries вартий уваги не тому, що це модний спосіб прибрати secrets. Він робить Dependabot і code scanning ближчими до реального dependency graph вашого продукту.

План на 30 хвилин:

складіть список private registries і consumers;
знайдіть, де зараз використовуються token або username/password;
виберіть один Cloudsmith або Google Artifact Registry candidate;
налаштуйте trust relationship у провайдера;
створіть GitHub registry configuration з OIDC і visibility selected;
перевірте Dependabot, code scanning default setup і логи;
тільки після зелених перевірок приберіть старий secret.

Якщо у вас private registries уже є, не чекайте інциденту з токеном. Почніть із найменшого registry, де security automation сьогодні найбільше сліпне.

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

Короткий чеклист

Скласти список private registries і репозиторіїв, які ними користуються.
Окремо позначити registry, потрібні Dependabot і code scanning default setup.
Перевірити, чи підтримує провайдер OIDC для GitHub security features.
Для Cloudsmith підготувати namespace, service-slug і audience.
Для Google Artifact Registry підготувати workload-identity-provider і, за потреби, service-account.
Обмежити visibility registry configuration до потрібних репозиторіїв.
Після зміни перевірити Dependabot job logs і повторно оцінити code scanning default setup.

Prompt Pack: audit OIDC для private registries у GitHub

Допоможи перевірити, чи можемо ми замінити довгоживучі registry secrets на OIDC для GitHub security automation. Вхідні дані: - список приватних registry в організації; - які з них використовують Dependabot, code scanning default setup або CodeQL; - провайдер registry: Cloudsmith, Google Artifact Registry, AWS CodeArtifact, Azure DevOps Artifacts, JFrog Artifactory або інший; - поточний спосіб автентифікації: token, username/password, org secret, repo secret, OIDC; - які репозиторії мають доступ до кожного registry; - чи є GitHub Code Security / GitHub Advanced Security і default setup; - чи налаштований trust relationship на стороні cloud/provider. Поверни: 1. короткий висновок: де OIDC доречний уже зараз, а де краще залишити поточну схему; 2. таблицю registry -> споживачі -> поточний auth -> рекомендований auth; 3. мінімальні поля для Cloudsmith і Google Artifact Registry; 4. rollout-план на 30 хвилин із rollback; 5. чеклист перевірки Dependabot PR, code scanning default setup і false-negative ризику; 6. список secrets, які можна прибрати тільки після успішної перевірки. Формат відповіді: діагноз, план змін, команди/API-поля, перевірки, rollback, що не чіпати.