Dependabot OIDC for private registries: reducing supply-chain risk without static secrets

Executive summary

On February 3, 2026, GitHub announced OIDC authentication support for Dependabot when accessing private registries. Instead of storing long-lived credentials in repository secrets, Dependabot jobs can request short-lived credentials from an identity provider.

This is a meaningful shift for teams that operate many repositories and internal packages: supply-chain security moves from "secret distribution" to "identity federation + policy". The operational model changes, not just the auth method.

What changed in practice

According to GitHub's changelog and documentation, Dependabot OIDC support now covers private registries hosted on:

• AWS CodeArtifact
• Azure DevOps Artifacts
• JFrog Artifactory

The security posture improvement is direct:

• No static registry passwords duplicated across repositories.
• Credentials become short-lived and tied to job identity.
• Registry access can be constrained by cloud-side trust policies.

For organizations with hundreds of services, this reduces one of the most common failure modes in dependency automation: stale or over-privileged tokens left in secrets stores.

Why static Dependabot secrets become expensive at scale

Static credentials usually start as a convenience and become governance debt.

The hidden cost is not only incident risk. It is also coordination overhead: platform teams repeatedly rotate credentials, patch broken updates, and reconcile undocumented token scopes.

OIDC flow for Dependabot in one mental model

textDependabot update job
  -> requests OIDC token from GitHub
  -> presents token to cloud identity provider
  -> receives short-lived registry credential
  -> pulls private dependency metadata/artifacts
  -> token expires automatically

This model aligns with how many teams already run GitHub Actions OIDC for cloud deployments. The difference is that dependency updates now follow the same trust chain.

Constraints you should plan for

OIDC support is a strong upgrade, but it does not remove all operational constraints.

• Not every private registry/provider combination is covered by this new mode.
• Trust policies can fail closed if subject/audience conditions are too strict or mismatched.
• If registries are reachable only on private networks, Dependabot may still require self-hosted runner strategies.
• Security teams must treat identity policy reviews as production controls, not one-time setup.

In other words: you remove secret sprawl, but you must mature identity governance.

Migration playbook for engineering teams

1. Inventory all Dependabot private registry integrations by ecosystem and owner.
2. Classify integrations into OIDC-ready and still static-secret paths.
3. Configure cloud-side trust policies with least-privilege scopes per org/repo/environment.
4. Roll out OIDC by canarying critical repos first, then broadening gradually.
5. Keep static credentials as temporary fallback with explicit expiration dates.
6. Add observability for token exchange failures, registry 401/403 spikes, and update latency.

A practical anti-pattern is migrating everything in one batch without policy-level tests. Teams usually discover naming/claim mismatches only after update windows fail.

Signals that the migration is really working

• Percentage of Dependabot jobs using OIDC vs static credentials.
• Time-to-recover when a registry auth policy changes.
• Number of long-lived registry secrets remaining in GitHub.
• Dependency update success rate for private packages after migration.

If these metrics do not improve, the issue is often not Dependabot itself; it is weak ownership of identity policy lifecycle.

Conclusion

Dependabot OIDC is not just a feature release. It is an architectural opportunity to treat dependency updates as first-class workload identity traffic.

For teams shipping business-critical systems, the key question is less "Can we enable OIDC?" and more "Do we have operating discipline to keep identity policies correct as repos, teams, and environments change?"

Sources

• Dependabot now supports OIDC with private registry providers in beta (GitHub Changelog, February 3, 2026)
• Configuring access to private registries for Dependabot (GitHub Docs)
• OpenID Connect security hardening with GitHub (GitHub Docs)