GitHub OIDC for Dependabot: What It Secures, What It Doesn't

On May 19, GitHub expanded OIDC support so that Dependabot and code scanning can authenticate to private registries with short-lived tokens instead of static secrets. Two new registries, Cloudsmith and Google Artifact Registry, join the existing set of AWS CodeArtifact, Azure DevOps Artifacts, and JFrog Artifactory. The feature is GA on github.com and shipping in GHES 3.22.

This is a genuine security improvement. Long-lived registry credentials sitting in repository secrets have been one of the easiest targets in supply chain attacks, and replacing them with OIDC federation removes that entire class of exposure. But there's a common misread of what OIDC actually does here, and it's worth being precise about the boundary.

OIDC secures the credential exchange. It does not evaluate the code change.

What the May 19 expansion actually changes

Before this update, Dependabot needed a static token or password stored in organization secrets to pull packages from private registries during version update and security update jobs. Those credentials had broad scope, long lifespans, and no built-in rotation. If a secret leaked through a log, a misconfigured action, or a compromised runner, the attacker got durable access to your artifact registry.

GitHub first added OIDC for Dependabot in February 2026, supporting AWS CodeArtifact, Azure DevOps Artifacts, and JFrog Artifactory. The May 19 update extends that to Cloudsmith and Google Artifact Registry, and also brings the same OIDC capability to code scanning workflows.

The mechanism is the same one that GitHub Actions workflows have used for OIDC federation with cloud providers: GitHub's OIDC provider issues a signed JWT for the workflow run, your cloud identity provider validates it against a trust policy, and hands back a short-lived credential scoped to exactly what that job needs. No stored secrets, no rotation schedules, no blast radius if a token escapes a log line.

Configuration happens at the organization level. You update your registry entries in dependabot.yml to use the OIDC authentication type, configure a trust policy on the registry side, and every Dependabot job across the org picks up short-lived tokens automatically. The five supported registries now cover the most common private artifact hosts in enterprise GitHub environments.

What OIDC doesn't change

OIDC answers one question: "Is this job allowed to talk to that registry?" It does not answer: "Is the dependency change this job produced actually safe to merge?"

That distinction matters more than it sounds. When Dependabot opens a PR to bump a package from v2.3.1 to v2.4.0, the OIDC flow handled the credential exchange with your private registry so the update job could resolve and fetch that new version. Good. But the PR itself might introduce:

• Breaking API changes that compile fine but change behavior at runtime. A minor version bump in a transitive dependency can rename a method, alter return types, or drop a default.
• Transitive vulnerabilities pulled in by the new version. Updating package A to fix CVE-X might bring in package B@3.0 which has CVE-Y.
• License changes in the updated package or its new dependencies that violate your org's compliance policy.
• Lock file inconsistencies where the regenerated lock file resolves differently in CI than it did when Dependabot created the PR.

OIDC has zero visibility into any of this. It's an authentication layer, not an analysis layer. The PR content is completely outside its scope.

Why Dependabot PRs still need a review gate

Teams that manage dozens or hundreds of repositories know the pattern: Dependabot opens 30 PRs on a Monday morning, each bumping a single dependency. CI passes on most of them. The temptation is to auto-merge everything that's green.

CI passing means the tests you wrote still pass. It doesn't mean the update is safe to ship. Your test suite might not cover the specific behavior that changed. It almost certainly doesn't check whether the new dependency tree introduced a known vulnerability in a transitive package that wasn't there before.

With OIDC now handling the credential side cleanly, the remaining risk concentrates entirely on the PR content. The question shifts from "did Dependabot authenticate securely?" (yes, solved) to "did Dependabot produce a merge-safe change?" (still unanswered by any GitHub-native mechanism).

A review gate fills that gap. Not a manual review for every Dependabot PR (nobody has time for that at scale), but an automated review layer that reads the diff, evaluates the dependency change in context, and flags the PRs that actually need human attention.

Wiring a review layer into Dependabot workflows

The goal is straightforward: every Dependabot PR should get the same review signal as a human-authored PR. The dependency update happened automatically, but the merge decision shouldn't be automatic just because the credential exchange was clean.

Tenki's code reviewer runs on every PR that triggers it, including Dependabot PRs. It reads the diff, understands the dependency graph context, and posts review comments the same way it would on a feature branch from a human developer. For Dependabot specifically, that means it can catch things like a major version bump disguised as a patch, a new transitive dependency with known issues, or a lock file change that doesn't match the declared update.

The setup is a GitHub Actions workflow that fires on pull_request events. Dependabot PRs trigger the same workflow path as any other PR, so there's no special configuration needed. The review runs, posts its findings, and the merge decision is informed by actual analysis of the change rather than just CI status.

For teams that do want auto-merge on low-risk Dependabot PRs, the review layer becomes the gate: if the review finds nothing concerning, auto-merge proceeds. If it flags something, the PR waits for a human. That's a much better signal than "CI passed."

OIDC for code scanning: what changes in your pipeline

The May 19 update doesn't just cover Dependabot. Code scanning workflows, including CodeQL and third-party SARIF uploaders, can now use OIDC to authenticate with private registries at the organization level too.

This matters for a specific scenario: code scanning jobs that need to resolve private dependencies to do accurate analysis. If your CodeQL workflow has to pull internal packages from a private registry to build the project before scanning, it previously needed stored credentials for that registry. Now it can use an ephemeral OIDC token, scoped to the scanning job, that expires when the job finishes.

The practical benefit is cleaner runner hygiene. Ephemeral tokens mean the runner's environment doesn't hold registry credentials that could persist between jobs or leak through caching. If you're running scanning jobs on Tenki runners (which already provide ephemeral, isolated environments for each job), the OIDC token lifecycle aligns naturally: the runner spins up, gets a short-lived token, runs the scan, and tears down. No credential residue.

The trust model after OIDC

With this expansion, the trust model for Dependabot workflows now has two distinct layers:

1. Credential trust (now handled by OIDC): Is the job authorized to access the registry? Is the token scoped correctly? Does it expire? This layer is solved.
2. Content trust (still unaddressed by OIDC): Is the resulting dependency change safe? Does it introduce regressions, vulnerabilities, or incompatibilities? This layer requires a review gate.

Most teams will benefit from enabling OIDC for Dependabot immediately. It's a strict improvement over static secrets, the migration is well-documented, and the five supported registries cover the majority of enterprise private artifact setups. But enabling OIDC and calling the Dependabot pipeline "secure" misses half the picture. The credential is secure. The change still needs eyes on it, whether human or automated.

If you're already using OIDC for your human-authored workflows and treating Dependabot PRs differently, this is the moment to close that gap.