At Cloudsmith, we are excited to announce our support for the 

as an upstream source. By consolidating all your artifacts, packages, and now Chainguard Images into Cloudsmith, your organization can:

 with no/low vulnerability base images provided by Chainguard.

 your packages and third-party dependencies using Cloudsmith's global content delivery network for optimal performance.

 by establishing and enforcing rules on dependencies with Cloudsmith’s policy manager.

 from disruptions caused by the removal of dependencies or outages in public repositories.

Integrating the Chainguard Registry as an upstream resource in your Cloudsmith account not only enhances security but also boosts efficiency in your artifact management workflow.

Chainguard, a Docker Verified Publisher, offers Chainguard Images which are a collection of minimal, hardened container images with impressive features:

, containing only the application and its runtime dependencies

Using these images as your base images will drastically reduce vulnerabilities and image attack surface, saving your organization time spent triaging CVEs.

 (cgr.dev/chainguard) containing developer images and a 

 (cgr.dev/chainguard-private) which includes all versioned tags of an image and special images not available in the public registry (including FIPS images and other custom builds).

Organizations using Cloudsmith with Chainguard will immediately realize developer efficiencies, unparalleled performance, and reduced risk by having Chainguard images managed directly in Cloudsmith.

Cloudsmith's upstream proxying and caching capabilities offer a powerful solution for managing dependencies and enhancing security in your software development process.

With upstream proxying, package managers (e.g., Docker, npm, pip) recognize packages and images stored on remote repositories (e.g., Chainguard Image Registry, Docker Hub, npm, or PyPI) as part of the Cloudsmith repository. This consolidation transforms Cloudsmith into your single contact for all third-party dependencies, simplifying your organization's build systems and eliminating the need for multiple integrations.

Cloudsmith excels at locating, downloading, and securely storing dependencies within its environment, ensuring optimal performance and control for your organization. Caching your upstream dependencies in Cloudsmith offers several benefits:

 of your packages, including third-party dependencies, through Cloudsmith's global content delivery network.

 if dependencies are removed from external repositories.

 by providing access only to dependencies with acceptable vulnerability levels and license types through fine-grained rules enforced by the Cloudsmith policy manager.

Cloudsmith's upstream proxying and caching can streamline your organization’s development processes, enhance performance, and maintain control over your dependency management workflows.

Check out our documentation on getting started with proxying and caching with Cloudsmith.

Here's how you can integrate the Chainguard Registry into your 

: If you haven't already, create a repository in Cloudsmith where you'll publish your package. Note down the Docker registry URL, which should resemble: https://docker.cloudsmith.io/v2/ORGANIZATION/REGISTRY/

In your Cloudsmith repository, go to the Upstream Proxying settings.

Click the green "Create Upstream" button and select the Docker format.

Provide a descriptive name for the upstream, e.g., Chainguard Public, and specify the URL for the Chainguard Registry.

For Chainguard’s public images: https://cgr.dev

For Chainguard’s Private/Dedicated Registry: https://cgr.dev/chainguard-private

Choose Proxy or Cache and Proxy: Decide whether you want to just proxy requests through to Chainguard or also cache resolved assets in Cloudsmith for future use.

: Ensure SSL certificates are verified for added security, especially for public sources.

: If you are using the private URL, Chainguard requires authentication or additional headers; provide them in the respective fields.

Pull a Chainguard Image with Docker Native Tooling

Here’s an example of how you would pull the nginx Chainguard Docker image into Cloudsmith after you’ve configured your Cloudsmith upstream for Chainguard:

 for Chainguard using the instructions above.

 with your Cloudsmith username and token, with the command: docker login docker.cloudsmith.io

 by running: docker pull docker.cloudsmith.io/ORGANIZATION/REPOSITORY/chainguard/nginx:latest
Note: Replace ORGANIZATION and REPOSITORY with your Cloudsmith organization and repository, respectively.

 to find the newly added Chainguard nginx image.

Integrating the Chainguard Registry as an upstream in your Cloudsmith account not only enhances security but also boosts efficiency in your artifact management workflow. Embrace this integration today to unlock a new level of reliability and control in your development process.

Ciara Carey

Solutions Engineer

Enhance Security with Chainguard and Cloudsmith

Before GitHub, everyone struggled to manage SVN (the “cool kid” at the time, pre-git), CVS, VSS, or, for the genuinely arcane, RCS. As a developer, there was trepidation with every check-in, hoping that nothing went wrong. Back then, source code management was held within a proverbial black box on some server you had to maintain, probably stuck under a colleague's desk in the corner.

Then, in 2008, GitHub emerged with a fully managed SaaS offering that gave developers and their teams visibility, control, and management.

Even before Cloudsmith was formed, Lee and I adopted GitHub in 2012. This was our first opportunity to move away from this insane black box, on-prem legacy so we could concentrate on the things that mattered. We never looked back.

Today, GitHub stores most of the world’s source code, both private and open source. Over the years, it has expanded its core functionality to include GitHub Actions and a limited Package Registry, among other enhancements.

Cloudsmith was built to solve the same challenges of visibility, control, and management but for the software supply chain and secure delivery, including binaries, artifacts, packages, and containers. In much the same way, it brings a fully managed SaaS offering to store most of the world’s packaged code, both private and open source.

Our primary goal was to help developers and operations remove the need for an artifact registry on a legacy black box on a server you had to maintain or even think about deeply. Instead, we provided the single source of the truth for all artifacts in a fully managed cloud-native platform leveraging all of the cloud’s positive attributes, including reduced infrastructure costs and the best scalability and performance, all at the click of a button, just like GitHub.

Today, Cloudsmith proudly sits beside GitHub in our customers' tech stacks, showcasing our commitment to “works well with others” and ensuring our customers have what they need to build secure and performant pipelines, distributing source and packaged code when and where it is required, whether internally consumed, or delivered across the world.

Our integration with GitHub gives development and DevOps teams an easy and secure way to manage source code and the resulting packages through:




Use GitHub as your IdP to sign into Cloudsmith.




Use our GitHub Action to publish packages to Cloudsmith across all popular formats.




Use GitHub as an OIDC provider for integrated authentication and more robust security.




We scan and tag your packages using scanning data sourced from GitHub's advisory databases for Hex, Java, .NET, Node.js, PHP, Python, Ruby, and Swift.




We work alongside GitHub and GitHub Advanced Security to protect software's ingress and egress risks.

With the advent of popularized Gen AI, there is now more than ever a wealth of data, with new ways to consume and query it. It’s an obvious next step to share that knowledge created by deep developer-interactive tooling like GitHub and lean into the knowledge Cloudsmith is capturing about the security and provenance of both open-source and closed-source software.

That’s why we launched Cloudsmith Navigator last year, to surface curated provenance information about open-source packages, powered in part by GitHub’s history of the source code. Navigator offers a glimpse into the nature of the holistic knowledge we have access to, and it’s this knowledge that forms the foundations of additional risk-based policies and controls.

A wise wizard once told me (okay, it was last weekend), “[it’s important] to bring more of the developer tools in the place where they already work.” In other words, you want to build a bridge towards existing tooling and make it easy for others to integrate rather than being isolationist and building all-in-one platforms that are anti-competitive. It makes sense to achieve genuinely “works well with others” and fits into our strategic thinking and positioning for Cloudsmith.

We believe it will take a village of partnerships, with at least two cathedrals (GitHub and Cloudsmith 🙂), to put the best guardrails in place to minimize the risks of open-source and closed-source software. That means continuing to partner with companies that share our cooperative mission to secure software delivery, like our friends at Docker, CircleCI, Stacklok, Chainguard, and GitHub.

How to Integrate Cloudsmith with GitHub Actions

Using GitHub Actions to Push Packages to Cloudsmith

Alan Carson

Co-founder and Chief Strategy Officer

Two Cathedrals: Cloudsmith + GitHub

Among the 30+ package formats that Cloudsmith supports, Helm Charts are particularly popular. Cloudsmith serves millions of Helm charts annually, with the number of customers using Cloudsmith as a Helm repository growing every month. These users leverage our support of Helm alongside our container registry to deploy and manage their Kubernetes clusters.

Given Cloudsmith’s universal package support, a common question we encounter is whether our container registries can host Helm Charts. This is an insightful question and one we wanted to provide some background on along with our answer.

The short answer is, you can use Cloudsmith to store your Helm charts alongside your Docker images thanks to Cloudsmith’s support for multi-format repositories. This gives you a unified platform for all your K8s needs, ensuring all your dependencies are stored, managed, and delivered from a single, secure source.

With the release of Helm v3.8.0, storing Helm Charts in OCI registries became the default (before v3.8.0, it was experimental). Kubernetes clusters rely on a container registry to source images, so it made sense that developers would be interested in a single place to store Helm Charts alongside container images. The 

Open Container Initiative Distribution Specification

 defines an API protocol to facilitate and standardize the distribution of content, and it’s designed to be agnostic of content types.

. Now, if you were a Kubernetes user, you needed to set up a container registry and a Chart Repository to manage your clusters fully. Two things to manage and maintain, and of course - less is always more!

 in 2019, and we have built on and enriched that support over the years. Cloudsmith offers Chart Repositories for both public and private repositories. Some of the key features of Cloudsmith’s support for Helm include:

 Cloudsmith fully supports both the verification and generation of Helm provenance files.

Proxying and caching from upstream repositories

: You can configure upstream Helm repositories that you wish to use for charts that are not available in your Cloudsmith repository. In addition, you can also choose to cache any requested charts for future use.

For public Helm charts, Cloudsmith will scan for licenses, and then lets you build policies on what licenses are allowed for use within your organization.

 to learn more about Cloudsmith’s support of Helm. And because Cloudsmith’s repositories are fully multi-format, you can store your Helm charts and container images in the same Cloudsmith repository. One location to rule them all (so to speak).

So what does it mean for users that Cloudsmith is a Chart Repository for Helm charts? The great news is, nothing! Cloudsmith is a fully featured Helm repository, we simply don’t use OCI as the storage mechanism under the hood.

To migrate Helm Charts to Cloudsmith from an OCI registry, it’s as simple as using helm pull, and then pushing the chart to a Cloudsmith repository!

Suppose we have a Helm Chart in an OCI registry (we can use Nginx as an example here). We can pull this chart with helm pull as follows:

Ok, great. we have pulled this chart successfully. Now it really is as simple as pushing this Chart to Cloudsmith using the Cloudsmith CLI and the cloudsmith push command:


We can then see the Helm Chart in our Cloudsmith repository, and of course any other artifacts we have there (Multi-Format goodness, yay!):

How Cloudsmith helps you streamline K8s workflows

Because Cloudsmith is a universal artifact management solution with multi-format repository support, you can use Cloudsmith to store your container images and Helm Charts alongside each other in one repository, streamlining your K8s workflow with a single source to secure, host and distribute the workflow dependencies.

So what are you waiting for? Join the growing number of customers who use Cloudsmith to make their Kubernetes lives easier :-)

Dan McKinney

Streamline Kubernetes Workflows with Cloudsmith

Today, we're addressing the challenge of moving away from risky long-lived credentials, such as username/password combinations or tokens, and embracing OpenID Connect (OIDC) for enhanced security and manageability.

OIDC is key to building zero-trust pipelines, enhancing the security of CI/CD workflows.

Outline the security risks with using long-lived credentials.

Provide a step-by-step GitHub Actions workflow that builds and pushes a package to Cloudsmith using OIDC for authentication.

Security Risks with Long-Lived Credentials:

Traditionally, CI/CD pipelines have relied on tokens or username/password combinations for accessing cloud services, managing resources, and deploying software. However, these long-lived credentials pose significant risks to security and manageability.

: Any credential can leak, and it might remain unchanged for months or even years before detection.

: Setting static credentials to expire is good practice, but managing their renewal across various workflows can be error-prone, leading to potential breakages.

: Reusing credentials across multiple environments or workflows is a common practice, further exacerbating security risks.

webinar with Rob Godfrey, Senior Technical Architect at Financial Times 

where he shared insights from a critical incident in Jan 2023. Following a breach, Rob's team had to spend weeks rotating and revoking thousands of long-lived credentials, highlighting the monumental task and risks associated with static credentials.

After that incident, Rob and his team at the Financial Times used OIDC authentication where possible to make their CI/CD pipelines more secure and more manageable.

OIDC, or Open ID Connect, provides a better approach to authentication and authorization, enabling short-lived authentication tokens. OIDC allows trusted systems, like GitHub Actions, to authenticate into other systems, such as Cloudsmith, using short-lived JWT tokens.

How does OIDC work with Github Actions and Cloudsmith?

The following diagram gives an overview of how GitHub's OIDC provider integrates with your workflows and Cloudsmith:

Cloudsmith creates an OIDC trust relationship between your service account and your GitHub workflows that need access to Cloudsmith.

Github Actions Worker initiates the workflow by requesting a token from the GitHub OIDC service to authenticate with Cloudsmith.

GitHub OIDC service receives the token request. After verification and validation, it generates a JWT token. The GitHub OIDC service and the GitHub Actions Worker have implicit trust, allowing for this token exchange.

GitHub Actions Worker presents a JWT token to Cloudsmith for access to resources.

Cloudsmith verifies the JWT token with the GithHub OIDC service to ensure its authenticity and validity. This step includes verifying claims.

Upon successful validation, Cloudsmith issues a short-lived access token to the GitHub Actions Worker, granting access to Cloudsmith's resources for around 90 mins to cover the duration of the job.

How OIDC Addresses the Security Risks Associated With Long-Lived Credentials

 OIDC tokens are short-lived and requested on demand, meaning that even if a token is leaked it will expire quickly (e.g., within 90 minutes), minimizing the risk of unauthorized access.

: Since OIDC tokens are automatically generated and expire after a short period, there is no need to manage the renewal of static credentials across various workflows. This reduces the likelihood of workflow breakages due to expired credentials.

: OIDC tokens are single-use, ensuring that the same token cannot be reused across different environments or workflows. This significantly lowers the risk of credential misuse.

Workflow Enhancement with OIDC, Cloudsmith, and GitHub Actions

Our workflow using GitHub Actions and Cloudsmith with OIDC will push a package to Cloudsmith from Github Actions using OIDC to authenticate.

Follow the steps below for the Cloudsmith and Github Actions OIDC Setup:

 to allow the Service Account to push packages to Cloudsmith.

Navigate to the OIDC Provider Settings at: 

https://cloudsmith.io/orgs/{ACCOUNT}/settings/openid-connect/

Click "Create" to open the Edit Provider Settings form.

 is unique to each provider, for Github Actions it is: 

https://token.actions.githubusercontent.com

 as a claim. Other supported claims can be found 

 that the user wants to be able to authenticate as with the configured provider & claims combination

Open your GitHub Actions YAML file which sets up your Github Actions workflow.

Add the permissions setting to request the JWT:



Permissions: id-token: write # This is required for requesting the JWT contents: read # This is required for actions/checkout

Generate the OIDC Token in GitHub Actions.

 you can use getIDToken() or you can use the curl command below to request the JWT.



curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange"

Make a POST request in GitHub Actions to the Cloudsmith.

Make a POST request in your GitHub Actions YAML file to the Cloudsmith OpenID endpoint to receive the JWT token:



curl -X POST -H "Content-Type: application/json" -d "{"oidc_token":$value, "service_slug":"SERVICE_ACCOUNT_SLUG"}" https://api.cloudsmith.io/openid/{ACCOUNT}/

Use the JWT token in GitHub Actions like an API key with Cloudsmith:

The JWT token generated by the OIDC endpoint can be used like an API key: X-Api-Key header: "X-Api-Key:Bearer OIDC_TOKEN"

This token will also, work with the Command-Line Interface when specified as 

Trigger a build in GitHub Actions, and OIDC will authenticate into Cloudsmith.

For a more detailed set of instructions, 

In this blog, we outlined how to enhance your GitHub Actions workflow's security by eliminating the need to store Cloudsmith credentials in your repository and leveraging OIDC for authentication.

If this was useful, don’t miss our next webinar on 

enhancing your infrastructure as code workflows with Spacelift

Zero Trust Pipelines with OIDC, Cloudsmith, and GitHub Actions

In case you missed it, the PlatformCon 2024 agenda is now live! Hosted by the Platform Engineering community and Humanetec, each year the week-long virtual event draws thousands of engineers to their browsers to connect with their peers, learn from some of the industry’s leading specialists, engage one-on-one with them on Slack, and even win some goodies from sponsors. Last year over 22K professionals attended—impressive for an event that started as a modest meetup in 2021!

This year they’re going hybrid for the first time—introducing one singular IRL day of hands-on workshops to the mix in London on June 12th, called LDN Live. I’ll be running on securely consuming OSS and take home some practical strategies for mitigating common security risks.

Although this year’s new LND Live workshops come with a fee to attend, all of PlatformCon’s online talks and workshops are completely FREE as usual. With over 130 to choose from in this year’s lineup, it’d be easy to get overwhelmed by the sheer quantity. So to give you a head start, here are the six I’ll be setting reminders for in my calendar:

How platform engineering teams can augment DevOps with AI

Green DevOps: Building sustainable software

Meta dogfooding: How Cloudsmith uses Cloudsmith to build Cloudsmith

Securing CI/CD pipelines with Docker Scout: A DevSecOps approach to software supply chain security

Why women should choose platform engineering

I’ve focused on the DevOps topics because here at Cloudsmith we don’t just simplify and secure 

 for our DevOps clients. We’re also fiercely committed to sharing best practice and thought leadership with the entire DevOps community.

Given the ever-changing nature of software development, it's crucial to stay ahead of the curve, so Ricardo Castro's talk immediately piqued my interest. I’m interested in his perspective on the current state and future prospects of DevOps given the rise of platform engineering and its growing characterization (by some) as an alternative to DevOps practices. I’m curious to hear how he sees the two playing together and how he thinks DevOps needs to evolve in order to do so.

I’m also hoping he’ll share his thoughts on the emerging trends and technologies that he believes will shape the future of DevOps.

If I don’t get my fill of emerging DevOps trends in the talk above, this session by Gartner’s VP of Research should do the trick. The potential of AI to improve working practices and outputs across industries is fascinating, and it’s exciting to see that experts are beginning to consider its practical applications for software operations. I’m super curious to hear what his recommendations are for applying AI tools, tech, and methods to improve DevEx, software delivery efficiency, and delivery infrastructure.

Now here’s a topic we don’t hear enough about! Integrating sustainable practices into the software development lifecycle is crucial for reducing the environmental impact of our work, so I’m keen to hear Neel’s advice on how teams can reduce their carbon footprint and minimize waste without compromising software quality. The session promises valuable insights on how we can contribute to a greener future through our development practices.

I was lucky enough to see an early iteration of this talk a while back, so I’m confident the final version for PlatformCon is going to be great. My colleague Jack will be taking everyone inside our engineering operations and architecture to show how we use our own artifact management and distribution platform, Cloudsmith, to build our platform. He’ll also be sharing the ways this practice has allowed us to improve operational efficiency and security. It should provide useful insights to any of you in platform engineering considering dogfooding, yourselves. And if you’re in DevOps, as an added benefit, it’s a chance to see, up close, how Cloudsmith works in production to streamline and control the software supply chain.

Securing CI/CD pipeline with Docker Scout: A DevSecOps approach to software supply chain security

Given the proliferation of containerization across the industry, Docker’s widespread adoption, and SBOM generation as the latest in software supply chain best practice, this DevSecOps how-to talk on Docker Scout got my attention. I’m interested to hear how well Docker’s native SBOM generator has been working for Prabesh’s team at Capsule. It’ll also be useful to see exactly how they’ve integrated the tool into their pipeline and how they’re leveraging automations with Docker Scout to improve both speed and security.

Ok, so this last one on my list isn’t strictly DevOps related, but I’m passionate about diversity and inclusion in tech, so this talk is particularly exciting to me. I can’t wait to hear Swarna’s take on the unique perspectives and innovations women bring to the field as well as her practical tips on overcoming the professional fear and uncertainty that so often comes with underrepresentation in the workplace.

6 Must-See DevOps Talks at PlatformCon 2024

After past breaches to similar CI/CD platforms, such as 

, those vendors also recommended users rotate their keys.

CI/CD platforms play a vital role in modern development and cloud-native pipelines. Breaches in these platforms' secrets are serious risks because these platforms often have access to long-lived credentials. If these tokens are compromised, the result can be data leaks, account hijacking, or unauthorized access to multiple cloud accounts.

 recommended minimizing the use of long-term credentials by using ephemeral tokens, like 

, where possible. Additionally, the NSA advised organizations to secure their CI/CD pipelines with strong access controls, up-to-date tools, log auditing, security scans, and proper secret management.

 featuring Rob Godfrey, Senior Technical Architect at the Financial Times (FT), we gained invaluable insights into how they navigated the aftermath of the CircleCI breach. The strategies implemented by Rob and his team at FT closely align with NSA's recommendations. Rob shared firsthand experiences, detailing:

The monumental task of rotating thousands of long-lived secrets.

The critical role OIDC authentication played in securing their pipelines.

The importance of selecting tooling in the build pipeline that supports OIDC, like Cloudsmith, to ensure robust security measures.

Implementing alternative processes where OIDC isn’t supported to mitigate risks effectively.

Why do we have long-lived secrets in our CI/CD?

Long-lived keys and credentials are often found at the heart of CI/CD pipelines, because they facilitate access to cloud services for publishing artifacts, software deployment, and cloud resource management.

The following is a classic use case of adding long-lived secrets to your CI/CD pipelines:

A user is created within a cloud service that integrates with CI/CD, such as AWS or Cloudsmith, with permissions to perform specific actions.

A secret access key is generated for this user, serving as the long-lived credentials.

These credentials are then integrated into the CI/CD pipeline in a secret store and used to execute various tasks, like infrastructure provisioning or artifact publishing.

These long-lived credentials often have very extensive permissions, since they need to create, delete, and update resources and cloud services. This increases the blast radius if the long-lived credentials are leaked. It’s hard to detect a leak, and rotating keys takes time and effort.

When Rob returned to work at FT after New Year's 2023, his plans for January took an unexpected turn. In his inbox was an advisory from CircleCI, urging the rotation of all secrets stored in their pipelines.

With over a thousand pipelines running in CircleCI and numerous environment variables to inspect, Rob faced a daunting task.

To address the issue, the team at FT took a series of actions:

 Leveraging the CircleCI-Env-Inspector tool, they enumerated all tokens stored in their pipelines, resulting in identifying over 14,000 environment variables to manage. These were narrowed down to 5,000 that represented long-lived secrets.

 Secrets were then categorized based on potential impact, with a plan to rotate critical and high-severity secrets first. Manual rotation proved laborious, requiring weeks of effort from a team of 30 to 40 engineers, but they eventually got through all of their secrets.

After evaluating lessons learned, FT embarked on a set of long-term initiatives to fortify pipeline security:

The best way to avoid the risks of long-lived secrets is to not use them at all. FT adopted OpenID Connect (OIDC) wherever possible, since OIDC enables use of short-lived authentication tokens.

 Where OIDC was not supported, FT implemented automated key rotation using Doppler.

FT enhanced their internal inventory system to track secrets and their responsible owners, ensuring better visibility and management.

FT made changes to their build tools, opting for tools that are built with security as the simple or default mode for developers. It was at this time that Cloudsmith was selected for artifact management, based in part on our support for OIDC.

 FT built training and awareness programs to educate employees about security best practices and response procedures.

After the initial shock of the CircleCI breach, Rob and the team at FT realized that a similar breach could happen to any of their vendors.

In response, they proactively fortified their CI/CD pipelines against future breaches. Embracing OIDC authentication and selecting secure tooling like Cloudsmith, which supports OIDC, became cornerstones of their long-term security strategy.

Through these decisive measures, Rob and his team transformed adversity into an opportunity, ensuring their pipelines are robust and resilient against evolving threats.

 with Rob about how the Financial Times recovered and thrived after the CircleCI breach.

"My CI/CD Platform was Breached!" Now What?

Cloudsmith loves open-source software (OSS). There, I said it.

Our co-founders, Alan Carson and Lee Skillen, recognized from the beginning that smart reuse is a core value of the software community. Companies that make developer tools have a special obligation to support OSS, which in the case of Cloudsmith means 

 (OpenSSF). It also means giving back to the community by hosting OSS repositories, and providing distribution capabilities.

 is one of our earliest and most popular features. Any Cloudsmith user - even those on our free Core plan - can create OSS repositories, which we track separately from your public or private repos. OSS repos get 50GB of storage and 200GB of monthly bandwidth for free, as long as you attribute Cloudsmith in your readme. (There are a 

 - specifically, client logging and geo/IP controls - to every OSS repo hosted by Cloudsmith. We recognized that OSS maintainers need these controls, especially as their libraries gain popularity.

 is a wake-up call for software companies. Most commercial software products are built on top of mountains of OSS; and by some estimates, up to 90% of all deployed production code is sourced from an OSS library. There are legitimate questions being asked today about whether commercial entities are doing enough to support the development and maintenance of the OSS that we all rely upon, and ultimately need to trust.

Cloudsmith is a foundational tool in protecting and securing the software supply chain. Organizations large and small use Cloudsmith to ensure they can have a single source of truth, and control the flow of every software ingredient that ultimately lands on their production servers and client devices. The explosion in OSS has demonstrated the need for security-oriented tools like Cloudsmith. While we help customers protect against vulnerabilities that can sneak into OSS, we also believe it’s part of our mission to support healthy development and distribution of OSS.

Like the headline on this blog says - Cloudsmith ♥ OSS.

Cloudsmith blog

Enhance Security with Chainguard and Cloudsmith

Two Cathedrals: Cloudsmith + GitHub

Streamline Kubernetes Workflows with Cloudsmith

Zero Trust Pipelines with OIDC, Cloudsmith, and GitHub Actions

6 Must-See DevOps Talks at PlatformCon 2024

"My CI/CD Platform was Breached!" Now What?

Cloudsmith ♥ OSS

That's a Wrap on KubeCon 2024!

Cloudsmith Shines Bright at Digital DNA Awards

Caching and Upstream Proxying For CRAN's R Packages

Cloudsmith Achieves ISO 27001:2013 Recertification

Cloudsmith is headed to Paris for KubeCon Europe 2024