Migrate one Dependabot private registry credential to OIDC

Dependabot private registry OIDC removes the static credential reference and configuration from dependabot.yml, and you may revoke then delete the underlying Dependabot secret only after the positive and negative validation sequence. It is not an improvement if the replacement trust accepts ordinary GitHub Actions workflow subjects, reaches more than one feed, changes registry resolution, or gives manifest-time external code another credential path. This migration covers one static credential, one JFrog npm feed, and one named registry.

This article was source-reviewed on 2026-07-26. No provider registry, Dependabot update run, OIDC token exchange, or authorization probe was executed for this publication. OIDC changes credential lifetime; the provider trust and authorization still decide which repository identity may exchange a token and what the resulting credential may read. GitHub's private-registry guide describes Dependabot obtaining short-lived credentials for supported registries.

Inventory the current access before editing YAML

Record the current top-level registry key and the single updates block that names it. Record the registry host, npm ecosystem, feed path, current scope and replaces-base values, the credential owner, the read operations it performs, packages it must reach, and feeds or packages it must not reach. Also record whether insecure-external-code-execution is absent, left at its default denial, or explicitly set to allow.

Identify the provider identity, audience, role, service account, or identity mapping that will issue the short-lived credential. Do not change routing during an authentication-only migration: do not add, remove, or flip scope or replaces-base unless a separate review intentionally changes registry routing. For npm, scope makes Dependabot generate .npmrc configuration from registry credentials, overriding committed .npmrc configuration or lockfile inference; replaces-base: true directs resolution to the configured URL rather than the ecosystem base URL. Dependabot options reference

Migrate one JFrog npm registry credential

Configuration template, not executed for this publication. This static configuration uses a deliberately synthetic username and a Dependabot secret reference.

version: 2
registries:
  my-jfrog-feed:
    type: npm-registry
    url: https://example.jfrog.io/artifactory/api/npm/example-npm-feed/
    username: DEPENDABOT_STATIC_USERNAME_PLACEHOLDER
    password: ${{secrets.EXAMPLE_JFROG_NPM_PASSWORD}}
    scope: "@example-scope"
    replaces-base: true
updates:
  - package-ecosystem: "npm"
    directory: "/"
    registries:
      - my-jfrog-feed
    schedule:
      interval: "weekly"

Configuration template, not executed for this publication. The replacement preserves the registry name, URL, scope, routing value, directory, and schedule. Authentication is the only intended change.

version: 2
registries:
  my-jfrog-feed:
    type: npm-registry
    url: https://example.jfrog.io/artifactory/api/npm/example-npm-feed/
    jfrog-oidc-provider-name: EXAMPLE_JFROG_OIDC_PROVIDER
    scope: "@example-scope"
    replaces-base: true
updates:
  - package-ecosystem: "npm"
    directory: "/"
    registries:
      - my-jfrog-feed
    schedule:
      interval: "weekly"

JFrog requires jfrog-oidc-provider-name in place of username and password; audience and identity-mapping-name are optional and provider-dependent, so add either only when the provider integration requires it. GitHub's private-registry guide

The top-level registries section defines available access details. The updates[].registries list selects the entries that this package-manager update may use. Dependabot options reference A one-item named list is narrower and easier to review than registries: "*".

For GitHub Packages or Container registry, do not create a third-party OIDC registry entry. Grant the Dependabot repository Read access to each package, then use automatic GITHUB_TOKEN access. GitHub's private-registry guide GitHub Packages access-control guide

Provider fields and boundaries to verify

The feature-specific guide limits this feature to registry types that otherwise use username and password; it does not establish OIDC support for every Dependabot registry type or provider. GitHub's private-registry guide

On 2026-07-26, that guide lists AWS, Azure, Cloudsmith, Google Cloud, and JFrog. The broader OIDC concept page lists only AWS, Azure, and JFrog. This article follows the feature-specific configuration guide for feature support and does not conceal that mismatch.

These are operator verification requirements, not configured or tested controls. The required and optional field sets come from the feature-specific private-registry guide.

Keep Actions trust policy out of the migration

An Actions job requests an OIDC token with id-token: write. Branch subjects, environment subjects, and reusable-workflow subjects are part of that Actions workflow model. GitHub Actions OIDC reference Dependabot obtains its registry credential through its own supported private-registry configuration, not through a workflow permission in this migration. GitHub's private-registry guide

The reviewed GitHub sources do not publish a Dependabot private-registry subject format. Do not infer a sub, branch, environment, workflow path, or job_workflow_ref, and do not copy an Actions trust condition into a provider policy. The feature guide says the credential is short-lived like Actions federation; that does not establish an identical subject policy. GitHub's private-registry guide GitHub Actions OIDC reference

Use the provider-supported Dependabot integration contract and verify the accepted issuer, audience, and claims before production. If that contract is unavailable, stop instead of widening a wildcard subject condition.

Preserve registry routing and external-code isolation

Keep my-jfrog-feed attached only to its npm update. replaces-base: true changes resolution to the configured URL, while npm scope controls the generated .npmrc configuration; neither field is an authentication field. Dependabot options reference

When private registries are configured, Dependabot disables external code execution by default. If an existing update already sets insecure-external-code-execution: allow, review every registry associated with that update separately. Manifest-time code can access only registries associated with its enclosing update, not unrelated entries in the top-level registries section. GitHub's private-registry guide

OIDC does not protect against compromised manifest code. A short-lived credential can still be stolen and used during its validity window if that code receives access to it.

Pre-production authorization checklist

These are checks to execute before revoking the old credential. They are not evidence from this publication.

Positive checks:

• The intended Dependabot repository identity can exchange a credential for the configured provider integration.
• The short-lived credential can read metadata and download only the required package from the intended feed.
• The intended update configuration resolves through the same registry path as before the authentication change.
• A Dependabot update run can complete the intended dependency lookup without the old secret.
• Token lifetime, issuer, audience, and provider audit record match the approved design.

Negative checks:

• A different repository identity cannot exchange the credential.
• An ordinary Actions workflow subject copied from the same repository is not sufficient unless the provider contract explicitly and intentionally authorizes that separate identity.
• The credential cannot read another feed, repository, namespace, domain, or package outside the declared scope.
• The credential cannot publish, overwrite, delete, administer, or grant access.
• A wrong audience, provider name, role, service account, or identity mapping is rejected.
• Removing the registry from updates[].registries removes that update's access path.
• Manifest-time external code remains disabled. If separately allowed, it cannot access an unrelated top-level registry.
• Revoke the old static credential only after the positive and negative checks pass, then confirm that the revoked credential is rejected.

OIDC completes the credential migration only when the new trust is narrower than the old secret and the update keeps the same registry and external-code boundaries.