By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

Pulling Docker images from private registries for containerised applications presents a security challenge. It requires authentication management, network access, and trust across distributed systems. Credentials must be securely handled and rotated, and image pulls can break due to network restrictions or expired tokens. All of this makes deployment and security harder.

To address this, you can use OpenID Connect (OIDC) when pulling Docker images from Cloudsmith into Kubernetes. OIDC adds a layer to OAuth 2.0 that identifies who is making the request. Cloudsmith can then verify that the requests come from a trusted source and can grant short-lived access tokens. So you no longer have to rely on long-lived credentials, enhancing security and simplifying credential management.

Kubernetes clusters often need to pull Docker images from private registries like Cloudsmith. Traditionally, this meant storing long-lived credentials in the cluster, which has some security risks:

Credentials could be compromised if the cluster is breached.

Regular rotation of credentials becomes a manual, error-prone process.

It's hard to apply the principle of least privilege effectively.

Before we dive into the solution, let's review what an Image Pull Secret is in Kubernetes.

An Image Pull Secret is a way to pass credentials to the kubelet to authenticate with a private container registry. Typically, the secret contains:

While Image Pull Secrets solves the immediate authentication problem, using them with long-lived credentials still exposes us to the security risks mentioned earlier. The credentials don’t automatically expire, leaving them vulnerable to misuse if leaked or unrotated.

OpenID Connect (OIDC) allows us to use short-lived tokens instead of long-lived credentials, reducing risk exposure. Here's how it works in the context of Kubernetes and Cloudsmith:

Kubernetes has its own identity in the form of a service account. The service account has an associated JWT (JSON Web Token). During runtime, the following steps are taken:

Kubernetes issues the signed OIDC token (a JWT).

Cloudsmith receives and verifies the JWT and exchanges it for a short-lived Cloudsmith token.

Kubernetes uses the short-lived Cloudsmith token to create or update an Image Pull Secret.

At runtime, the pod requests to pull an image.

Kubernetes pulls an image from Cloudsmith using the Image Pull Secret for authentication.

To automate the process, we use a Kubernetes CronJob. This job runs at regular intervals and performs the following tasks:

Retrieves the Kubernetes service account token.

Exchange service account token for a Cloudsmith token via OIDC.

Create or update an Image Pull Secret with the new Cloudsmith token.

Here's an example of what this CronJob might look like:

2. Gets the Kubernetes service account token.

4. Creates or updates an Image Pull Secret named cloudsmith-pull-secret.

Implementing this OIDC-based solution offers significant benefits:

: The CronJob ensures the token is regularly refreshed, maintaining a good security posture without manual intervention.

: There's no need to manually update credentials, reducing operational overhead.

: The token only has the permissions it needs for a limited time, aligning with security best practices.

Once the Image Pull Secret is created or updated by the CronJob, you can use it in your pod specifications like this:

This pod will use the cloudsmith-pull-secret to authenticate with Cloudsmith and pull the specified image.

Using OIDC to pull Docker images from Cloudsmith into Kubernetes eliminates the need for long-lived credentials. It reduces the risk of leaked credentials, removes the need for manual credential rotation, and aligns with current security best practices.

Authentication in Kubernetes is evolving with significant recent enhancements. Kubernetes v1.20 saw the introduction of 

. These allow the kubelet to dynamically request credentials for a container registry instead of storing static credentials on disk. This was enhanced in v1.33 to support automatic use of the service account token for image pulls. This enables short-lived authentication without needing to manage Image Pull Secrets and reduces complexity. Cloudsmith remains vigilant, and these updates help with our goal of increasing automation in supply chain security.

Ian Taylor

Tech Content Director

Ian Duffy

Site Reliability Engineer

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

The root cause of many vulnerabilities is memory corruption from software written in memory-unsafe languages like C and C++.

The responsibility to stop memory corruption errors is left to the developer in C and C++ and they are often hard to catch. You fix up one memory vulnerability and another one appears.

We can eliminate these vulnerabilities by moving software away from C and C++.

 advise and encourage organizations to move away from memory unsafe languages.

OpenSSL, a crucial C software library found in Linux that implements the TLS protocol, is a good case study in memory vulnerabilities. It has suffered from a number of vulnerabilities due to memory corruption, including:

, found in 2014, allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL.

The NSA recommends C#, Rust, Go, Java, Ruby and Swift as possible alternatives to C and C++.

An important feature of all the memory-safe languages that the NSA recommends is that they have a package manager. Cloudsmith's cloud-native artifact repository supports over 28 different types of languages including 

 to help you with the transition to a memory-safe language.

Memory-safe languages- who is the obvious successor to C and C++?

How do we transition Legacy systems from C and C++?

In C and C++ the memory is allocated to all the variables of a program automatically during compile time. The stack is used for static memory allocation like local variables. Dynamic memory is allocated during runtime on the heap when the size of the memory is not known e.g reading in data. C and C++ developers need to manage their dynamic memory by allocating, deallocating memory and checking for potential memory issues.

Managing your memory and assigning data is where memory vulnerabilities can occur.

Buffer overflows are the most common type of memory corruption in C and C++ and are one of the top vulnerabilities used by attackers.

A buffer overflow occurs when you allocate memory of a certain size but the data you put into it is larger than the buffer has room for. This causes the program to write past the end of the buffer or array and corrupt the extra memory. This vulnerability can be triggered under certain circumstances e.g. unexpected user input.

A buffer overflow attack exploits the buffer overflow vulnerability. This attack can lead to the following:

unauthorized memory being accessed in an information leak attack e.g. Heartbleed in OpenSSL,

modify program code in a code corruption or control-flow hijack attack or

Protections in C/C++ without moving to another language

There are a number of things that can reduce the risk of memory corruption in C and C++, including:

Checking that the allocation of memory succeeded.

Dynamically allocate memory rather than statically when you don't know the size needed.

Defensive programming where you always assume the worst by checking any input including return values from functions.

Using managed buffers and strings rather than raw arrays and pointers in C++.

Using safe functions that include buffer overflow protection e.g use 

The C++ Core Guidelines advise against using 

 directly for creating dynamic objects in favor of smart pointers through 

 for reference-counted multiple ownership.

Heap scanning technologies to improve memory safety of C++.

Operating system kernel settings like ASLR and stack canaries.

Why mitigations against memory vulnerabilities aren't enough

Most of the responsibility to stop memory corruption errors is left to the developer in C and C++ and defenses in the compiler/kernel e.g. ASLR, stack canaries, can be circumvented by attackers. If you are lucky, the program will crash during testing, exposing the memory issue, but these bugs can go under the radar only to be found by attackers when they are running.

 that prevent it from improving its memory safety including tech debt and its commitment to backward compatibility.

Memory corruption in C or C++ has gone on for more than 30 years and continues to be one of the top vulnerabilities in real-world exploits. This is what has driven the NSA to encourage organizations to shift to using memory-safe languages.

Languages such as C#, Go, Java, Ruby, Rust and Swift use built-in safety mechanisms that minimize the likelihood of memory corruption vulnerabilities like buffer overflows.

It doesn't mean that there are no security vulnerabilities in programs developed in these languages but it eliminates a whole class of vulnerabilities.

Languages, like Java, C#, Python and Ruby are interpreted languages. The source code is not directly translated by the target machine. Instead, first, the source code is compiled into a virtual language and then it is interpreted by a VM.

Well-written C and C++ code will generally run faster than well-written code in interpreted languages mostly because they are statically-typed languages compiled to machine code.

Go and Rust are both performant open-sourced, compiled languages that are memory-safe alternatives to C/C++.

The garbage collector manages the allocation and release of memory for an application. In garbage-collected languages (e.g. C#, Go, Java, Ruby and Swift) developers don't have to write code to perform memory management tasks.

C and C++ don't use garbage collection for memory management which improves performance at the expense of security and usability.

The Rust language does not perform garbage collection and instead uses a 

. This allows it to be more efficient and performant than other memory-safe languages but at the expense of usability.

Who is C/C++'s successor? Is it all about speed?

Speed isn't the be-all and end-all in programming.

Optimizations in interpreted languages, powerful chips, cheap infrastructure and the development of performant languages have reduced the need for the speed that C and C++ can achieve. Security, usability, team experience and development time are often more important considerations.

Let's hear about some of the contenders for the C/C++ throne:

Java and C# are pretty fast and have made significant speed increases in the last few years. On top of that Java and C# have comprehensive tooling which leads to a 

really impressive developer workflow at 15hrs/16hr

 to merge a PR compared to the average 40hr. The same study showed that C++ programs took on average 140 hrs to merge a PR.

Go is a good all-rounder with speed and ease of use. Go compiles to machine code, has more modern features, simpler syntax, and is easier to write than C/C++.

But if we talking about applications where speed is the priority- Rust is a memory safe language that is 

 but it comes with a steep learning curve.

How do we transition legacy code from C and C++

There are lots of alternatives for developing new software in memory-safe languages but migrating billions of lines of legacy C/C++ code is a huge task.

Google launched a new programming language called 

. It’s an experimental successor to C++. Carbon is not fully memory safe but it has a path toward achieving robust memory safety.

The primary purpose of the Carbon language is to have performance similar to C++, bi-directional interoperability with C++ and migration from existing C++ code.

 using Rust if it is possible to do so. Many large C++ codebases use features incompatible with Rust making the migration process difficult. This is where Carbon makes sense.

A likely path off memory unsafe programs is to find the most problematic and popular C/C++ programs and replace them 1 at a time.

Rust is now in the Linux kernel- this opens up a lot of possibilities for moving off C and C++ code. One possibility is to replace the use of OpenSSL, a C program that implements TLS and SSL protocols, that has suffered from a number of memory vulnerabilities with 

C and C++ lack guardrails around memory which have led to too many exploitable memory vulnerabilities over the last 30 years. These bugs can be completely eliminated by moving to memory safe languages, like the NSA recommendations of, C#, Rust, Go, Java, Ruby and Swift.

Migrating billions of lines of legacy C/C++ code will be a huge task but pathways exist to make this happen. Who knows, maybe the new Carbon language will develop some nice tools for migrating some of this code without much intervention.

The march has already begun- worries about security, less skilled C/C++ engineers, performant alternatives and trends in software development mean there will be less and less C and C++ code in the world over the next decade.

Cloudsmith supports memory-safe languages

Ciara Carey

Solutions Engineer

Could 2023 be the year of memory safety?

You know you need to secure your software supply chain. Everyone’s telling you that these days - your executives, your vendors, even 

. Your organization has an initiative to do so, or maybe they’ve brought in an expert to help you achieve this goal. But hold on a minute - do we have a shared understanding of what a software supply chain is, and what exactly makes it secure?

Hopefully, you were able to join the Linux Foundation webinar Cloudsmith hosted last week with 

. The focus was getting back to the basics of what a software supply chain is, and why it needs to be secure. If you weren’t able to attend, or if you want reference material to share with others, here’s our recap.

The webinar addressed the following topics:

What does a secure software supply chain look like?

What are Cloudsmith and Chainguard doing to help solve this problem?

In the most basic terms, what is a software supply chain?

Simply put, a software supply chain includes 

 everything that contributes to making your product - the source code, dependencies, systems, tooling, environments, processes, and even the users who contribute along the way.

, Developer Relations at Cloudsmith, said that a good analogy for understanding the software supply chain is to look at another industry that also deals with supply chains - manufacturing. The manufacturing industry has a standardized way - a Bill of Materials - to detail all of the inputs into their final product. They need that because they need to ensure they have the materials required to build the physical product and that they have met safety and security standards along the way.

The software industry doesn’t have the same regulatory controls as manufacturing, though. There is no centralized authority ensuring provenance and traceability are enforced (though we may see this in the future). This gap has made space for the rise of many interesting projects designed to help make safety and security so easy, it becomes the default. Projects like Sigstore, The Update Framework, in-toto, and SLSA are just a few examples. We’ll touch more on these projects later in this post.


Why are we securing our supply chains now?

As Dan Lorenc said in the webinar, there have been voices advocating for securing software supply chains for years now. But a handful of events in the last 24 months have caused organizations to wonder why they’ve waited so long to get started.


In the spring of 2020, SolarWinds unknowingly started to send out software updates that contained hacked code. This is the event that really got everyone talking about “software supply chains”.

SolarWinds is an IT management tools company that helps businesses manage their networks, systems, and infrastructure. In early 2020, threat actors found a way into the build system at SolarWinds and managed to add malicious code into one of its products, a performance monitoring platform called Orion. Subsequently, when Orion customers updated their installations, the malicious code was included in the update, giving the threat actors a backdoor they could use to install additional malicious software, exfiltrate sensitive data, or spy on the companies themselves.

Big organizations found themselves impacted - Microsoft and Intel for example. Overnight, everyone was talking about software supply chains and what needed to be done to secure them.


In February 2021, security researcher Alex Birsan 

 were found to be vulnerable to the injection of malicious packages, via public sources, into their software supply chains.

, and it relies on package management software to download the malicious version of a package being used as a dependency. The key is to create an external library with the same name as a private internal library that a particular company uses in its development pipeline. There are then several ways that a package manager can end up accessing the malicious external version of the library.

This incident shows why it is so important to make security so easy, it happens by default. It only takes one developer with a poorly configured system for the malicious library to gain entry to the organization.

Executive Order on Improving the Nation’s Cybersecurity

On May 12, 2021, President Joe Biden issued an executive order to begin creating federal standards for security of the software supply chain. 

The Executive Order on Improving the Nation’s Cybersecurity

 orders the Department of Commerce and the National Telecommunications and Information Administration to publish minimum requirements for a 

 (SBOM). The SBOM is a record of the components and packages used in building software, whether open-source or commercial, intended to help software end-users to analyze vulnerabilities or issues with the licenses.


In February 2022, The National Institute of Standards and Technology released Special Publication (SP) 800-218, 

Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities

. At the start of 2022, the White House brought together government employees, private sector stakeholders, and members of the open-source community to discuss how to improve the security of open-source software and software supply chains. This publication is the result of those discussions, and it recommends a core set of high-level secure software development practices called the SSDF that can be integrated into each SDLC implementation.

Why is this a hard problem for organizations to solve?

One challenge is that open-source software is foundational to software development, and so for an organization to secure their supply chain, they will need all open-source software they use to also be secure. Realistically, open-source code is in every supply chain. Now, it’s important to note that the way to solve this problem 

 to remove open-source software from your supply chain. In fact, open-source software can often be more secure than proprietary software as its widespread use means it’s usually well tested. The challenge is in how to make adhering to security best practices so easy, they are not burdensome for the open-source community to adopt.

Along the same lines, for one organization’s software supply chain to be secure, the supply chain of any vendor they use also needs to be secure. You need provenance from top to bottom. To quote Paddy Carey, Senior Staff Engineer, Cloudsmith, “

.” And if no one is requiring you to adopt secure software development practices, and it’s overly burdensome to do so, what’s your motivation? So again, designing standards, tools, and solutions that make it easy to be secure will be key to the widespread adoption of secure software development practices.

As Dan Lorenc said, it will be slow until the first person adopts these practices, but then we’ll see it ripple across the industry.


First, it’s important to acknowledge that there is no one thing you can do to secure your supply chain. There are many best practices that come together to create a secure software supply chain. But it’s also important not to let that overwhelm you.

One project that is designed to help organizations understand what makes a supply chain secure and provide guidance on how to get started is 

. It’s a security framework, a checklist of standards and controls to secure packages and infrastructure in your organization. And there are SLSA levels - Level 1 is designed to be easy to achieve to help motivate folks to start the process of securing their supply chain.

NIST organizes the Secure Software Development Framework practices into four groups:

: Ensure that the organization’s people, processes, and technology are prepared to perform secure software development.

: Protect all components of the software from tampering and unauthorized access.

: Produce well-secured software with minimal security vulnerabilities in its releases.

: Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Both the SLSA framework and NIST’s SSDF are good starting points for organizations on the journey to a secure software supply chain. And if you want the tl;dr on NIST’s SSDF, 

Dan Lorenc read NIST 800-218 so you don’t have to

Chainguard was founded in 2021 with the mission to 

make the software supply chains secure by default

. The team is working on this goal with a strong commitment to open-source projects and communities, and a willingness to take on large-scale industry-wide changes. Some key projects they are involved in:

As mentioned earlier, SLSA is a checklist of standards and controls to secure packages and infrastructure within an organization. SLSA levels are a common language to talk about how secure software, supply chains, and their components really are. From source to system, the levels blend together best practices to create four compliance levels of increasing assurance.

A new standard for signing, verifying, and protecting software, sigstore automates how you digitally sign and check components, for a safer chain of custody tracing software back to the source, removing the effort, time, and risk of error this usually comes with this.

As Dan McKinney said, Cloudsmith is excited that securing the software supply chain is now at the forefront of people’s minds, as it’s been close to our hearts for a while now. We believe that 

 - the strategy of ensuring all packages produced or consumed are scanned, verified and isolated from untrusted sources - improves security through isolation, automation, and universal hosting. Our platform enables organizations to add continuous packaging to their modern software development workflow.

Provide a single source of truth of software assets

 with support for over 28 formats, allowing organizations to manage packages across languages and formats in one place. This centralized source of truth provides visibility, control and management consistently for all packages produced or consumed by the build process, and gives organizations a single checkpoint that all packages pass through.

The goal of provenance is an unbroken chain of traceability, all the way back to the host machine that built the package. And we want to meet our users where they are when it comes to provenance. We will implement support for the signatures and attestations that our customers are adopting across all the formats we support, including but not limited to sigstore, cosign, in-toto, The Update Framework and more.

users can cache their open-source packages

 away from public upstreams. By caching packages from public upstream repositories and other external sources, you can protect yourself from issues with package availability, license changes, and emerging vulnerabilities.

First and foremost, we must acknowledge that we are a chain in our customers’ software supply chains. We are taking steps to ensure that we employ high-level secure software development practices, and exposing that information to our customers to prove to them that we are secure. Customers need to be able to trust, and verify, that their providers are securing their software supply chains, too.

Hopefully, that helps demystify software supply chains and why securing them is paramount to the software industry as a whole, and why the time to do so is now.

We’d also like to thank Dan Lorenc, the founder and CEO of Chainguard for joining us for the webinar.

Benchmark your supply chain security in 5 minutes with our 

Dan McKinney

Everything You Wanted To Know About Securing The Software Supply Chain

Video games are not just computer programs, they are audio-visual artistic works. It’s a collaborative effort between software engineers, animators, scriptwriters, graphic designers, photographers and sound engineers.

Working with these collaborators and assets leads to a different software pipeline than the average software project. They also have the added complication of making cross-platform games - custom optimizations for a particular platform can have the unwelcome side effect of increasing build times and complicating the build process. But when it comes down to it, it’s still a software pipeline that needs a package repository to store its artifacts.

On top of storing their artifacts, gaming developers need a package management tool that helps secure their software supply chain. Protecting and understanding the threats from the software supply chain aren’t new concepts in gaming development by any means. For years, Anti-cheat game developers have been developing ways to protect their supply chain with signed firmware to combat mods, anti-debugging software to defer piracy and hackers, and runtime integrity checks to combat cheaters.

A somewhat new avenue of attack from the supply chain is 3rd party dependencies. Gaming developers should be able to assess and manage their dependencies easily. Like other software pipelines, trust in dependencies is integral to the security of their software. Some gaming software, such as anti-cheat software, can often run at a very high privilege level - the consequences of adding a dependency with a vulnerability could be catastrophic.


Gaming developers need their package management solution to:

Store all their artifacts and have native support for the formats that are popular in gaming development such as Unity, NuGet, Lua, Maven, raw files for binaries, Docker, Helm and packages for mobile platforms like Cocoapods and Kotlin.

Be easy to automate against with APIs, CLIs, Webhooks, Integrations with other DevOps tools and good documentation

Support hosting large files like 3D models, visual or audio assets.

Help them manage the licenses of the dependencies they use.

Help them visualize, control and secure their supply chain including their 3rd party dependancies.

Allow them to work with distributed teams.

A gaming development pipeline builds a video game from concept to completion. These pipelines have to cope with cross-platform builds, audiovisual assets, licensing, different revisions, and creative changes. They also need to contend with a distributed workforce and the security of their software supply chain. Needless to say, Gaming development has quite a complex and time-consuming software pipeline.

Cross-Platform game development allows you to code once and release to all platforms, whether mobile, console, PC, AR, or cloud gaming platforms. The big gaming platforms include Steam, PlayStation, Xbox, Nintendo, PC, Mac, iOS, and Android.

Cross-platform game development can be made more accessible with gaming engines and SDKs. The big gaming engines are Unreal and Unity (see the table below for more examples and information).

Although gaming engines reduce the amount of code that needs to be reimplemented, games often need to add custom changes for things like input control, or they may want to improve the performance on specific platforms. Custom changes to optimize the game’s performance tend to have a negative impact on the build time. For example, two hours of lead time for building a game is normal in game development.

What Gaming Developers Need from their Package Management Tool

The gaming engine and the platform it is running on are the main determinants of what package format your package manager needs to support.

 to host the packages they produce and consume as dependencies. Their package repository needs to support package formats such as NuGet, Unity, Lua, Maven, Conan, raw files for binaries, Docker, Helm and packages for mobile platforms like Cocoapods and Kotlin.

With support for 28 different package formats and counting, Cloudsmith strives to support all package formats for gaming and beyond.

One thing that differentiates game development from other types of software development is the interaction with 3D models, visual assets and audio assets - these tend to be big hefty files.

GIT limits the size of files you can track in regular Git repositories and encourages you to use Git-lfs and replace the binary files with a text-based pointer to where the actual file is hosted. Plastic SCM is another way to version and store large raw assets.

Cloudsmith suggests another solution, you host your files on Cloudsmith as a raw file format, and you can refer to it in your codebase. Bring all your assets into Cloudsmith, where you can visualize, manage and control the access to the assets.

Licensing is insanely important in gaming. One case from 2014 between Epic Games and Silicon Knights resulted in a $9.2million award to Epic Games and an order to destroy all unsold copies of Silicon Knight’s games using Unreal Engine 3. It inevitably led to the dismantling of Silicon Knights.

Gaming publishers use middleware software and gaming engines to build their games. They use these dependencies to model textures, create characters, physics engines, or anything to make building a game faster and more reliable. These dependencies are then distributed with licenses that describe how you can use the software.

It’s essential for Gaming developers and publishers to know and review your license agreements and abide by the terms. But your package management solution can help you with this.

Cloudsmith’s License Compliance provides you with an overall view of the state of licenses for the repository as a whole. It gives you at-a-glance statistics on what licenses you are currently using and allows you to edit/change the license associated with a package held within the platform.

Gaming publishers also usually have a EULA (end-user license agreement) that they make you sign before playing the game. Cloudsmith provides the ability for all Raw format files, if enabled, to require an End-User License Agreement (EULA) when a user attempts to download it. You can also add a custom EULA license agreement to your Cloudsmith packages.

Multiformat Repositories and Universal Tagging

Talking to people in gaming, the thing that comes up as a real point of contention in gaming is that every platform is packaged differently- Sony, Nintendo, Microsoft, Steam, Epic- all different. Cross-platform game development means teams need to track and manage binaries for each platform.

Your package management tool needs to help you organize your repositories and track your packages to suit the needs of cross-platform game development.

Cloudsmith Blog

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

Could 2023 be the year of memory safety?

Everything You Wanted To Know About Securing The Software Supply Chain

Package Management for Gaming Software Development

Private Package Repositories Part 2: The Influencers

Getting Started with Helm and Cloudsmith

Private Package Repositories Part 1: What’s a package again?

Getting Started with Go and Cloudsmith

Getting Started with Docker and Cloudsmith

DockerHub vs Cloudsmith Private Docker Registry

Infinity Welcomes Careful Versioning

Getting Started with LuaRocks and Cloudsmith