GitHub OIDC for private registries: remove long-lived secrets from Dependabot and code scanning

Hook

GitHub expanded OIDC for org-level private registries: Dependabot and code scanning can now work with Cloudsmith and Google Artifact Registry without long-lived registry secrets.

This is not just another security toggle. If automation cannot see private dependencies, Dependabot updates less reliably, and code scanning default setup can miss parts of data flow and produce a false negative.

Problem / Context

In many teams, private packages live away from the source code: npm packages in Cloudsmith, Docker images in Google Artifact Registry, Maven or NuGet artifacts in an internal registry. Developers know this, CI knows this, but security automation often finds out last.

A common setup looks like this:

• Dependabot can access public dependencies, but private packages fail or are skipped;
• code scanning default setup analyzes the repository, but does not see part of the dependency context;
• the team adds a token or username/password to GitHub secrets;
• a few months later nobody knows who owns the token, when it should rotate, or which repositories use it.

OIDC changes that model. Instead of storing a long-lived secret in GitHub, you configure a trust relationship between the registry provider and GitHub. Then a GitHub security feature receives a short-lived credential only for the task it is running.

On May 19, 2026, GitHub added Cloudsmith and Google Artifact Registry to this org-level flow. Together with existing support for AWS CodeArtifact, Azure DevOps Artifacts, and JFrog Artifactory, this makes OIDC practical for more supply-chain setups.

Why It Matters

A long-lived secret is convenient until it becomes debt. It can be copied, granted to too many repositories, left in an organization secret, or forgotten after the owning team changes.

For Dependabot, the impact is practical: without access to a private registry, it does not see the full dependency picture. You may get fewer updates or confusing failures in update jobs.

For code scanning, the risk is subtler. GitHub docs explain that when default setup cannot access private dependencies, the analysis may miss some data-flow paths. The report may look calm, while part of the code was analyzed without complete context.

So the real question is not “would it be nice to remove secrets?” The better question is: do your security tools see the same dependency environment that your product actually runs with?

How To Do It

1. Start with inventory

Do not open GitHub settings first. Create a small table:

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

Example:

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

This step is boring, but it saves time. If you do not know who uses a registry, it is easy to grant access to the whole organization instead of two repositories.

2. Separate Dependabot from code scanning

GitHub has two related but different scenarios here.

Dependabot can access private registries through dependency configuration and organization-level registry configuration. Its validation is straightforward: the update job should pass, the dependency PR should open, and the logs should not contain authentication errors.

Code scanning default setup works differently. It needs access for better analysis, especially when important code or dependencies are stored in private registries. GitHub docs specifically call out that default setup needs registry access when a repository uses code stored in a private registry.

Practically, this means: do not treat a green Dependabot PR as proof that code scanning has the full context too. After a registry change, check whether default setup actually has the access it needs, and review the configuration for repositories whose analysis depends on private packages.

3. Prepare three fields for Cloudsmith

Cloudsmith OIDC needs:

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

In the GitHub REST API, this maps to auth type oidc_cloudsmith. The key fields are namespace, service_slug, and audience. api_host can be provided when your feed uses a non-default endpoint.

Do not drop in a personal token “for a minute.” If the trust relationship is not ready, document the blocker and finish the provider-side setup. Half-OIDC with a fallback long-lived token quickly becomes the old problem with a new label.

4. Check Workload Identity for Google Artifact Registry

For Google Artifact Registry, the minimum shape is:

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

In the REST API, this is oidc_gcp. The required field is workload_identity_provider. service_account and audience depend on your Google Cloud setup.

The most common failure is not in GitHub; it is in IAM. The provider exists, but the service account does not have minimal read access to the required Artifact Registry repository. Validate the real question: can this specific GitHub consumer read this specific registry?

5. Limit visibility

Organization-level configuration does not mean “everyone gets everything.” The GitHub REST API supports visibility all, private, or selected. For rollout, choose selected unless there is a strong reason to go wider.

A reasonable rollout:

1. choose one registry and 1-2 repositories;
2. add the OIDC registry configuration;
3. run a Dependabot job or wait for the scheduled run;
4. check code scanning default setup where relevant;
5. remove the old secret only after validation;
6. expand visibility gradually.

Until validation passes, avoid deleting the old secret. But do not leave it forever either: after a successful cutover, schedule removal and rotation so GitHub secrets do not become a museum of historical tokens.

6. Remember that auth type is not mutable

The GitHub REST API has an important detail: the auth type for a private registry configuration cannot be changed after creation. If you need to move from token to oidc_gcp or oidc_cloudsmith, expect to delete and recreate the configuration.

That is another reason to roll out in small steps. Validate one configuration, name, URL, visibility setting, and provider fields first. Then scale.

Anti-Patterns

• granting org-level registry access to every repository without inventory;
• leaving the old long-lived secret after a successful OIDC rollout;
• treating a green Dependabot PR as proof that code scanning has full context;
• creating OIDC configuration before the provider-side trust relationship is ready;
• confusing OIDC for GitHub Actions workflows with OIDC for GitHub security features;
• ignoring GitHub Enterprise Server version when the team is not on github.com;
• changing every registry configuration at once without rollback.

Conclusion / Action Plan

OIDC for private registries is worth attention not because it is a trendy way to remove secrets. It helps Dependabot and code scanning see the real dependency graph of your product.

30-minute plan:

1. list private registries and consumers;
2. find where token or username/password authentication is still used;
3. pick one Cloudsmith or Google Artifact Registry candidate;
4. configure the provider-side trust relationship;
5. create GitHub registry configuration with OIDC and visibility selected;
6. check Dependabot, code scanning default setup, and logs;
7. remove the old secret only after green validation.

If you already have private registries, do not wait for a token incident. Start with the smallest registry where security automation is currently the most blind.

Official sources:

• https://github.blog/changelog/2026-05-19-expanded-oidc-support-for-dependabot-and-code-scanning/
• https://docs.github.com/en/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries
• https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot
• https://docs.github.com/en/rest/private-registries/organization-configurations
• https://docs.github.com/en/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-default-setup-for-code-scanning-at-scale