GitHub expands OIDC for Dependabot and code scanning: fewer static secrets in the software supply chain

GitHub extends OIDC support for Dependabot and code scanning to Cloudsmith and Google Artifact Registry. What changes for DevOps, security and dependency governance.

What changed: OIDC also for Cloudsmith and Google Artifact Registry

GitHub announced in its Changelog an expansion of OpenID Connect, OIDC, support for Dependabot and code scanning when they need to authenticate against private registries configured at organization level. According to the note, Cloudsmith and Google Artifact Registry have been added to the registries already supported, alongside AWS CodeArtifact, Azure DevOps Artifacts and JFrog Artifactory.

In practice, GitHub organization administrators can configure OIDC-based credentials to let automated tools such as Dependabot and code scanning access private registries without necessarily relying on static tokens stored as secrets. The mechanism is similar to the one already used by many GitHub Actions workflows: GitHub issues an OIDC token, the identity or cloud provider verifies it, and temporary credentials are released with defined permissions.

According to GitHub, the feature is generally available on github.com and will be included in GitHub Enterprise Server 3.22. The value is not only the addition of two specific registries, but the consolidation of a broader model: DevSecOps automations accessing artifacts through federated identities, limited permissions and short-lived credentials.

Operational impact for DevOps and security teams

For many organizations, Dependabot and code scanning tools are now part of the standard delivery pipeline: they update dependencies, analyze vulnerabilities, open pull requests, check internal libraries and validate packages. When these tools need to read from private registries, an authentication mechanism is required. Historically, the simplest solution has often been to create service tokens or passwords, store them in organization secrets and rotate them periodically.

OIDC changes the model. Instead of distributing long-lived credentials, the organization defines a trust relationship between GitHub and the provider that manages the registry. Credentials are issued on demand, have a short lifetime and can be constrained by precise conditions: repository, organization, environment, branch, workflow type or specific token claims.

Operationally, this can reduce recurring risks: forgotten secrets, tokens reused across different environments, overly broad credentials, manual rotations that do not happen, and limited auditability. It does not remove the risk of poor configuration. A trust policy that is too broad can become a new weak point: if it allows too many repositories or processes to obtain credentials, the organization has only replaced a static secret with a poorly governed federated identity.

For teams using Google Artifact Registry or Cloudsmith, the update makes it possible to align authentication across CI/CD, dependency updates and security analysis. The goal should be to avoid exceptions: not having a modern model for main workflows while keeping a legacy model for automated security tools.

Adoption criteria: policies, permissions and audit before configuration

Before enabling OIDC for Dependabot and code scanning, the configuration should be treated as an architecture decision, not as a simple platform switch.

The first criterion is scope. Which repositories need access to which registries? A monorepo with critical internal packages requires different rules from an experimental project. Policies should be defined by organization, team, repository and, where possible, registry namespace.

The second criterion is least privilege. Dependabot may need to read packages to resolve dependencies, but not necessarily to publish artifacts. Code scanning may require even more limited access. Separating read, write and administration roles reduces the impact of abuse or misconfiguration.

The third criterion is audit. OIDC adoption is valuable only if temporary accesses are traceable: which repository requested credentials, when, for which registry and with which role. Without readable logs and review processes, the security benefit remains partial.

The fourth criterion is exception management. Some registries, legacy tools or on-premise environments may not yet support OIDC properly. In these cases, it is useful to keep an inventory of remaining secrets, with owner, expiry, rotation and rationale. An effective migration does not require eliminating everything immediately, but it does require knowing exactly where static credentials remain and why.

In Dedaloop cloud and DevOps projects, this type of change is usually integrated into a broader review of pipelines, identity management, environments and operational responsibilities. The connection with Cloud managed services & DevOps is direct: automation is useful only if it is also observable, governed and maintainable.

Mistakes to avoid and impact on supply chain governance

The first mistake is treating OIDC as an automatic security guarantee. It is an enabler: it reduces dependence on static secrets, but still requires correct policies, coherent roles and periodic controls. A permissive configuration can expose internal artifacts or allow unintended reads.

The second mistake is failing to involve the team responsible for cloud security. GitHub, registries and identity providers should be managed as one system. If the application team configures OIDC without coordination with those who manage IAM, logging and incident response, grey areas can emerge: nobody knows who approves roles, who reviews access or who intervenes when anomalies occur.

The third mistake is overlooking enterprise environments. GitHub indicates future availability in GitHub Enterprise Server 3.22: organizations using self-hosted installations should plan the upgrade, verify registry compatibility and test the configuration in non-production environments. Organizations with internal compliance requirements should also update documentation, audit procedures and change management controls.

The direction is clear: the software supply chain is moving from persistent, distributed credentials to temporary, verifiable and governed machine-to-machine identities. For companies and public bodies, this is not only a technical choice. It can reduce attack surfaces, make dependency update processes more robust and better connect DevOps, cybersecurity and IT governance.

For organizations reviewing their security posture, GitHub’s update can be a useful starting point for a broader question: how many critical automations still access internal systems through static tokens? The answer often opens valuable work on zero trust, permission segregation and continuous control, which are central themes in Cybersecurity and cloud infrastructure and Strategic IT advisory and governance.

Approfondimenti Dedaloop

Fonti