By submitting this form, you agree to our 

OpenID Connect (OIDC) provides ephemeral tokens, reducing the risk of long-lived credentials being exposed. For many organizations, artifact management tokens are among the most widely used credentials, making them a significant target for security breaches.

Shifting to OIDC is an excellent way to strengthen security posture, offering substantial benefits with minimal implementation effort. While direct 

Dependabot integration with OIDC in GitHub Actions isn’t available

, API-based token rotation offers a reliable workaround.

This guide will walk you through configuring GitHub Dependabot to authenticate with Cloudsmith using OIDC. It includes steps for setting up a Cloudsmith service account, configuring OIDC in Cloudsmith, setting up GitHub permissions, and creating a GitHub Actions workflow to dynamically update the Dependabot API key.

Step 1: Create a Service Account in Cloudsmith

 that the service account should be associated with for broader permissions.

Step 2: Configure OIDC Authentication for GitHub Actions in Cloudsmith

: Enter a descriptive name (e.g., GitHub Actions).

: Enter https://token.actions.githubusercontent.com.

 as the required claim for GitHub OIDC tokens to restrict access to your specific GitHub organization.

, select the service account created in Step 1 (Dependabot Service Account).

OIDC setup with GitHub Actions in Cloudsmith

Step 3: Set Up Access Controls in Cloudsmith

 for the repository where you want Dependabot to manage dependencies.

Step 4: Add a Fine-Grained Personal Access Token (PAT) in GitHub for Dependabot

 to the specific repository where you want to use Dependabot.

Add a new secret with the name FINE_GRAINED_PAT and paste the PAT as the value.

Step 5: Create DEP_CLOUDSMITH_API_KEY Secret for Dependabot

, enter a placeholder value (e.g., INITIAL_VALUE or a temporary token from Cloudsmith).

This sets up DEP_CLOUDSMITH_API_KEY as a Dependabot-compatible secret so that the GitHub Action can later overwrite it with an ephemeral OIDC token each time it runs.

The initial value doesn’t need to be valid long-term, as it will be regularly replaced by the OIDC-generated token.

After this initial setup, the GitHub Actions workflow you configured will take over, updating DEP_CLOUDSMITH_API_KEY with each run.

Step 6: Configure the dependabot.yml File

In your GitHub repository, create or update .github/dependabot.yml. The example below uses a Maven repository configuration, but this works with other package ecosystems, including npm, pip, and more (see the Dependabot configuration guide for details).:

Replace YOUR-ORG and YOUR-REPO with your actual Cloudsmith organization and repository details. This configuration will enable Dependabot to connect to Cloudsmith for dependency updates.

Step 7: Set Up a GitHub Action Workflow to Overwrite the Dependabot API Key with an Ephemeral OIDC Token

This workflow will authenticate with Cloudsmith via OIDC, generate a short-lived token, and overwrite the DEP_CLOUDSMITH_API_KEY used by Dependabot. Given that Cloudsmith’s OIDC tokens expire every 2 hours, this example schedules token rotation every 11 hours to align with Dependabot’s run schedule. If your setup requires more frequent rotations or encounters token expiration issues, adjust the schedule accordingly.

In your repository, create a file at .github/workflows/update-cloudsmith-key.yml.

Replace YOUR-ORG with your Cloudsmith organization slug.

Replace YOUR-SERVICE-SLUG with the slug of the Cloudsmith service account created earlier.

This workflow uses OIDC to obtain a JWT from Cloudsmith, overwriting the DEP_CLOUDSMITH_API_KEY Dependabot secret with an ephemeral, short-lived token.

 in your GitHub repository and manually run the workflow.

Ensure Dependabot is fetching updates from Cloudsmith and creating pull requests as expected.

This setup allows Dependabot to use a short-lived Cloudsmith OIDC token, enhancing security by overwriting the DEP_CLOUDSMITH_API_KEY secret with each token request.

Next: Learn how to leverage Cloudsmith with Dependabot to streamline your dependency management 

Ciara Carey

Solutions Engineer

Integrating Dependabot with Cloudsmith Using OIDC

We just released the Cloudsmith CLI GitHub Action. This new GitHub Action simplifies the process of installing and pre-authenticating the Cloudsmith CLI using OpenID Connect (OIDC) or an API Key. Whether managing packages, pushing artifacts, or automating your CI/CD workflows, this action is designed to streamline your experience and enhance your productivity.

1. Easy Installation of Cloudsmith CLI 📦

With this GitHub Action, you can effortlessly install the Cloudsmith CLI in your workflows. No more manual installations or complex setup processes. Simply add the action to your workflow, and the CLI will be ready to use.

One of the standout features of this action is its ability to pre-authenticate the Cloudsmith CLI using OIDC. By leveraging OIDC, you can securely authenticate without the need to manage API keys. This is particularly useful for organizations that prioritize security and want to minimize the exposure of sensitive credentials.

3. Support for API Key Authentication 🔑

In addition to OIDC, the action also supports authentication using an API Key. This provides flexibility for users who prefer or require API Key-based authentication. You can easily switch between authentication methods based on your needs.

The action comes with several customizable inputs, allowing you to tailor the setup to your specific requirements. You can specify the CLI version, provide the OIDC namespace and service slug, set the API Key, and more. This level of customization ensures that the action fits seamlessly into your existing workflows.

5. Seamless Integration with GitHub Actions 🤝

Designed to work seamlessly with GitHub Actions, this action integrates smoothly into your CI/CD pipelines. Whether you are building, testing, or deploying, the Cloudsmith CLI GitHub Action enhances your workflow automation and efficiency.

Ready to enhance your GitHub Actions workflows with the Cloudsmith CLI? Check out the 

 for more details and start integrating the action into your projects today.

For more information on Cloudsmith and its features, visit the 

For any questions or feedback, feel free to open an issue on the 

 or reach out to the maintainers. Thank you for your support!

Bartosz Blizniak

Senior Support Engineer

Announcing the Release of Cloudsmith CLI GitHub Action 🚀

Are your CI/CD pipelines at risk? They might be if you use long-lived, static credentials and tokens. Long-lived, static credentials and tokens are one of the most common causes of 

CI/CD tools need access to cloud services to publish artifacts, deploy software, and access resources on their cloud provider. So, they need credentials. It's tempting to hard-code them.

 left lots of organizations scrambling to rotate and disable API keys they were using to run their builds.

What's the solution? OpenID Connect! OIDC tokens are a more secure way to handle authentication than long-lived credentials, and they remove the need to store your credentials in your CI/CD platform.

 natively. You can use OIDC tokens to authenticate against our API, CLI and our users can even authenticate using OIDC with format-specific endpoints like Ruby, NuGet, Terraform, or Docker.

A classic but flawed workflow using long-lived tokens.

Workflow with Cloudsmith, GitHub Actions using OICD.

CI/CD platforms like CircleCI and Github actions usually require access to resources on external services, like your artifacts hosted on Cloudsmith’s artifact repository.

Hard-coded credentials stored on your CI/CD tool are often used to authenticate into these external services to allow for a fully automated build. Unfortunately, these hard-coded credentials could allow an attacker to authenticate into your system.

A classic but flawed workflow with GitHub Actions and Cloudsmith could flow like the following:

In Cloudsmith you create a user or service account

 named CLOUDSMITH_API_KEY, with the value of your API key.

In GitHub Actions write some code to build a package and use the 

As part of the build, Github Actions publishes to Cloudsmith using the long-lived token in Github secrets to authenticate into Cloudsmith.

The issue with the workflow above is that if this API token is stolen or leaked there is a risk of unauthorized access.

The workflow above can be made more secure by rotating your keys but this is an extra overhead on development, because you have to do it manually, and it might not actually get done. For this reason, Cloudsmith has introduced authentication policies to enforce 

 without having to manually rotate their keys.

Until recently, storing hard-coded credentials in your CI/CD for external cloud services was necessary if you wanted a fully automated build but there is a better way.

 is a better approach to authentication between CI/CD tools than using hard-coded credentials or long-lived API tokens.

OICD extends the OAuth 2.0 protocol for secure single sign-on (SSO) to authenticate API access control. OIDC uses 

 to allow third-party applications to verify identities and obtain basic user profile information.

Using OIDC tokens your CI/CD platform can securely authenticate into Cloudsmith without long-lived credentials being stored in your CI/CD.

By updating your workflows to use OIDC tokens, you can adopt the following good security practices:

No need to store your long-lived secrets in your CI/CD.

You have more granular control over how workflows can use credentials.

No need to rotate your API tokens. With OIDC, your provider issues a short-lived access token that automatically expires.

Security Assertion Markup Language (SAML) is another authentication protocol for SSO that enables secure authentication between different services.

SAML, unlike OIDC, works only on XML and is more difficult to use in use cases involving services authenticating over APIs.

OIDC is not intrinsically more secure than SAML but is easier to implement especially when working with APIs.

Workflow with Cloudsmith, GitHub Actions using OICD

Our updated workflow using Github Actions and Cloudsmith with OIDC looks like the following:

 as a provider for your Organization. Cloudsmith recommends adding claims here to restrict the context of any requests from the provider.

Update your Github Actions from above to use OIDC.

Add a new job to generate an OIDC JWT token in GitHub Actions. The JWT token generated by the OIDC endpoint can be used as an API key.

Save the JWT token to an environment variable called CLOUDSMITH_API_KEY and do not include the API key in the .yaml push action, the API key will be taken from the environment variable instead.

Trigger a build in GitHub Actions and OIDC will be used to authenticate into Cloudsmith.

This token works with all Cloudsmith API endpoints to manage resources, 

as well as format-specific endpoints, e.g. the Ruby endpoint to get all available Ruby packages.

Cloudsmith’s support for OIDC authentication brings a new level of security and convenience to software engineering workflows.

Hard-coded credentials leave you vulnerable in an attack, and manual key rotation can get missed. Give OIDC a try in your Cloudsmith org by consulting our 

If you don’t have a Cloudsmith org, or you want your own development sandbox separate from your company’s production org, 

Cloudsmith Blog

Integrating Dependabot with Cloudsmith Using OIDC

Announcing the Release of Cloudsmith CLI GitHub Action 🚀

Securely Connect Cloudsmith to your CI/CD using OIDC Authentication