Containers have been with us for a while and are ubiquitous in the Secure Software Development Life Cycle (SSDLC). According to some reports, 

 use containers for most or all of their production applications. It’s no surprise really, as containers provide consistency and standardization across the lifecycle while speeding up delivery pipelines. They revolutionized how we develop and deploy apps in the cloud and there is no sign of this changing anytime soon.

Like any part of the SSDLC, containers have security risks and can be breached. This can be due to misconfiguration of the containers, inherent vulnerabilities in the contained software, like missed OS patches, or vulnerabilities in the runtime code. These can manifest in various ways, but some common ones are vulnerabilities that provide root access to the OS, turn off security features, execute malicious code at run time, or run phantom processes silently in the background. And these breaches do happen. The most famous container breach is still the 2018 Tesla breach, where it was reported that hackers read AWS credentials from the breached containers and therefore gained further infrastructure access, allegedly launching cryptojacking operations using that infrastructure. So, with nearly 60% of organizations using containers in production, it's great to hear about Docker’s Hardened Images being announced last week.

 and records 11 billion pull actions on these images each month. Previously, they released Docker Official Images to provide confidence in the provenance of the images, SBOM support to give transparency on contents and Docker Scout for real-time insights. This focus on security has evolved again into Docker Hardened Images.

A hardened image is a container image prepared to reduce Common Vulnerabilities and Exposures (CVEs).

Ensuring they provide the core functions required

Reducing the target area for attacks by removing up to 95% of the contents

Providing a curation and governance process for images

The provenance and curation of these images should give organizations and developers confidence. Knowing that images will be checked and kept up to date by a reputable source like Docker can only be reassuring. However, the security of containers and images doesn’t stop here. At Cloudsmith, we are delighted to partner with Docker on this launch, as we know we can add more to securing container usage together.

The above image shows a typical example of how this works in practice. An organization’s CI/CD pipeline is configured to use Cloudsmith as a private registry for its artifacts, including container images. When a build is triggered during development, the CI/CD tooling requests the container image(s) it needs.

With an upstream proxy for container images configured, Cloudsmith will fetch the image(s) from Docker Hub. It is at this stage where a verifiable, trusted Docker Hardened Image can be fetched. There is no extra configuration required in Cloudsmith, so users can benefit from using these images right away. Pulling a Docker Hardened Image is the same as fetching any other image from Docker Hub. Maximum security and trust is built into the raw image. For customers that have specific compliance or security requirements, Cloudsmith will also enforce policies around licensing and vulnerabilities. 

See: link to enterprise policy management blog

. This ensures that organizations have the right blend of security at source and the flexibility to map to their own requirements.

How do organizations ensure developers use these images during code creation and the deployment lifecycle? Cloudsmith is already used by organizations worldwide for their Docker registries, and our advanced features provide tools built for global teams.

Our cloud native, global availability means an organization’s registries are available wherever its teams are. Policy creation and enforcement provide granular access to private and public images, ensuring a source of truth for the organization’s images and providing visibility to its security teams. We also support CI/CD workflows, meaning the organization can confidently see what is being promoted to production.

With seamless integration and zero tradeoffs between speed and compliance, combining the peace of mind provided by Docker Hardened Images with Cloudsmith’s Docker registry support and functions can produce even greater governance and confidence.

That's why we are delighted to collaborate with Docker for this launch, securing the software supply chain further than ever before.

Want to learn how to secure your software supply chain end-to-end?

Watch our webinar next week for an in-depth discussion on container security, hardened images, SBOMs, and how to build a zero-trust artifact lifecycle. 

 and get actionable insights from Docker and Cloudsmith experts.

Jack Gibson

Senior Software Engineer

Securing Containers at Scale: Docker Hardened Images + 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

User management is the backbone of secure and efficient software operations. As businesses grow and evolve, the tools they use must keep pace. Enter OKTA and Cloudsmith. OKTA, a titan in identity and access management, combined with Cloudsmith, the powerhouse of software artifact management, offers a solution that's both robust and user-friendly. This guide looks at how these platforms can be integrated to elevate your user management game.

User management is about controlling access to a system or application. It's a delicate balance: ensuring security while facilitating collaboration. Effective user management optimizes resource use, prevents unauthorized access, and tailors user experiences based on roles and needs.

The road to effective user management is often dotted with hurdles. These can range from setting up appropriate permissions, managing inactive users, to staying compliant with industry regulations.

Since its inception in 2009, OKTA has carved a niche for itself in the identity and access management sector. Its cloud-based platform, equipped with tools for user authentication, caters to businesses of all sizes, ensuring secure and seamless user experiences.

Okta offers a suite of features such as Provisioning, Single Sign-On (SSO), integration with Active Directory (AD) and LDAP, centralized user deprovisioning, multifactor authentication (MFA), and mobile identity management. These are complemented by adaptable policies tailored for organizational security. These capabilities are seamlessly integrated through the Okta Integration Network (OIN), a collection of pre-integrated applications. The OIN ensures that users can enjoy SSO login across all essential apps they interact with daily.

OKTA's strengths lie in its single sign-on capabilities, multi-factor authentication, and comprehensive lifecycle management. For those looking to streamline user management, OKTA's intuitive interface and extensive API integrations make it an indispensable tool.

Cloudsmith stands out as a leading software artifact management platform. It offers teams a centralized hub to store, manage, and distribute software artifacts, ensuring that software components are consistently available and secure.

Users can upload data, software, and dependencies into Cloudsmith or pull it from third-party sources. We then control distribution to their developers, servers, or external customers. Our primary mission is to contain 100% of the software and related data for users within Cloudsmith, keeping everyone safe.

But of course, we understand that different users have different needs. While some may be uploading artifacts, others might be in roles that require only viewing or downloading capabilities. Effective user management in Cloudsmith ensures that each user has the right permissions, enhancing security and operational efficiency.

Pairing OKTA with Cloudsmith is like merging the best of both worlds. Cloudsmith's prowess in artifact management is complemented by OKTA's user management capabilities. This integration not only simplifies access but also amplifies security measures, ensuring that the right people access the right artifacts at the right time.

Setting up the OKTA integration is quite straightforward, and to help you through the process we have put together a 

 in our Help Center. The integration includes SCIM provisioning, making it easier to manage users in your organization with minimal impact to your workflows.

Cloudsmith’s OKTA integration not only allows for user management, but also group management. This allows your organization to define clear user roles and groups based on job responsibilities and access levels.

Automated Provisioning and Deprovisioning

One of the standout features of Cloudsmith's OKTA integration is the ability to automate user provisioning and deprovisioning. This automation is crucial for organizations that prioritize security and efficiency.

When a new team member joins, the onboarding process often involves granting access to multiple tools and platforms. With automated provisioning, as soon as a user is added to OKTA, they're automatically granted access to Cloudsmith, eliminating manual steps and potential oversights. Conversely, when an employee leaves or changes roles, their access can be automatically adjusted or revoked, ensuring that only current team members have access to your critical systems.

Cloudsmith's OKTA integration can be seamlessly connected with HR systems. This means that any changes in the HR system, such as a new hire or a departure, can trigger the appropriate provisioning or deprovisioning actions in Cloudsmith. This integration further streamlines the user lifecycle management, reducing administrative overhead and potential errors.

It is not uncommon for user data to be scattered across multiple systems, and we all know how difficult that can be to manage! This fragmentation can lead to inconsistencies, security vulnerabilities, and administrative headaches. Cloudsmith's OKTA integration addresses this challenge head-on by ensuring that OKTA serves as the single, central source of truth for user information.

When OKTA is the authoritative source, any changes made there—like updating an email address or changing a department—will automatically sync to Cloudsmith. This ensures that user data remains consistent across platforms. By centralizing user information, organizations can reduce the risk of data discrepancies, improve auditability, and simplify user management.

Learn more about getting started with creating and managing teams in in Cloudsmith in the short video below:

Teams and Access Controls

As organizations increasingly rely on platforms like Cloudsmith for their operations, ensuring the protection of user data and maintaining a secure user management system becomes paramount. Let's delve into the security considerations you should be aware of when managing users with Cloudsmith and OKTA.

User data is a valuable asset, and its protection is non-negotiable. Cloudsmith is committed to safeguarding this data, implementing stringent security measures that align with industry best practices. When integrated with OKTA, the data protection capabilities are further enhanced. OKTA employs robust encryption methods, both in transit and at rest, ensuring that user data remains confidential and tamper-proof. Regular security audits, penetration testing, and compliance certifications further attest to the platform's commitment to data protection.

Role of OKTA in Enhancing Cloudsmith's Security

OKTA doesn't just streamline user management—it amplifies security. By integrating with Cloudsmith, OKTA brings its advanced security features, such as multifactor authentication (MFA), to the table. MFA requires users to provide multiple forms of identification before gaining access, significantly reducing the risk of unauthorized access. Additionally, OKTA's adaptive authentication measures assess various risk factors, like location and device, adjusting authentication requirements based on the perceived risk level. This dynamic approach ensures that security doesn't come at the expense of user experience.

Tips for Maintaining a Secure User Management System

: Periodically audit user roles and permissions. Ensure that employees only have access to the resources necessary for their roles.

: Ensure that all systems are regularly updated. Security patches and updates address vulnerabilities and enhance overall system security.

: A secure system is only as strong as its weakest link. Regularly train your team on security best practices, emphasizing the importance of strong, unique passwords and recognizing phishing attempts.

 Set up monitoring to detect any unusual activities. Immediate alerts for suspicious actions can help in quickly identifying and mitigating potential security threats.

: While not strictly a security measure, regular backups ensure that you can quickly recover user data in the event of any unforeseen circumstances, be it a technical glitch or a cyberattack.

The integration of OKTA with Cloudsmith is a testament to the evolution of user management in the digital age. By combining the strengths of two industry leaders, organizations can ensure a seamless, secure, and efficient user management experience. As the digital landscape continues to evolve, so do the challenges associated with user management. However, with tools like OKTA and Cloudsmith, businesses are well-equipped to navigate these challenges, ensuring that their operations remain secure, streamlined, and scalable. Whether you're just starting out or looking to enhance your existing setup, the OKTA-Cloudsmith integration offers a robust solution that caters to the diverse needs of modern organizations.

Lee Skillen

Chief Technology Officer

Managing Users and User Groups: A Guide to OKTA and Cloudsmith Integration

Large Language Models (LLMs) are now at the cutting edge of mainstream AI systems. Their impact has been seismic, sparking a new gold rush as application developers transform the user experience away from clicks and commands into natural language and advanced automation

However, application developers have a barrier to overcome. AI models need data to reason and respond to a particular application domain. Say, for example, the user of an artifact management platform needs to pose a simple question, ‘What packages are trending upward in usage?’ To answer this question, the AI needs to be trained on package data, including usage data.

In general, an AI model's capabilities depend on the information, or context, on which it is trained. And here is the problem - AI models tend to be isolated from data. Getting data into the AI model is not trivial. The data is often behind information silos and legacy systems. Integrating models usually involves a custom implementation with bespoke connectors.

It’s as if each time you plugged a device into a computer’s USB port, you had to configure the connection on a per-device basis. And so it is with AI models. The implementation has to be done on a per-data source, per-AI model basis, each time needing its own connector, protocol, and security checks. This multiplies the work involved in integration and tethers the LLM to a particular source, making it difficult to scale.

This multiplicity of connectors between each model and each source has been termed the MxN problem. Every model (M) needs a custom integration for every source or service (N), creating a multitude of one-off adapters that create a build and maintenance headache. As more models and tools enter the ecosystem, the integration load grows exponentially.

Luckily, Anthropic devised a solution to solve the mess of custom integrations that results from the MxN approach. The Model Context Protocol (MCP) is an open standard that provides a universal way of connecting AI models to external data sources and systems.

MCP provides a common interface, regardless of data source, eliminating the need for custom integrations for models and sources. The use of MCP as a middle layer reduces the MxN problem to a much more scalable M+N, as each model and source only has to integrate with MCP.


The USB-C port analogy is often used for MCP, as it, too, uses a single connectivity standard to provide a universal way to connect different devices. In fact, any common protocol has the same kind of utility. HTTP created a universal language for web browsers and servers to interact. MCP enables interoperability across platforms like OpenAI, Anthropic, Google DeepMind, and Microsoft, giving AI assistants access to tools and repositories in a secure and standardized way.

MCP is built using a client-server architecture, and works as follows:

The AI model (host) uses connectors (clients) to send requests for information or actions using MCP to an MCP server.

The server receives the requests, acting as an abstraction layer in front of the data source, exposing a controlled set of functions.

The server then translates the model’s requests into safe, scoped operations. This means data is accessed securely and consistently, and the model doesn’t need to know server implementation details for each data source.

The server capabilities are exposed via JSON-ROC methods, which are mapped to one or more internal database queries or functions. These could include file lookups, data queries, transformation functions, or any other tool-like operation.

The AI model can introspect the available methods and call them with specific parameters. The server authenticates the request and calls the appropriate backend query using its own connection to the database. A structured response is then returned to the model. This completely decouples the database logic from the AI model.

MCP provides powerful capabilities through code execution and data access. To address this, MPC includes a series of recommendations for best practices for securing data within your infrastructure.

These best practices are shaped around four key principles:

- Users must explicitly consent to and understand what data is accessed and what actions are performed. Implementations should offer clear UI elements to authorize and review activities.

- Resource data must not be transmitted or exposed without user approval. All access must be explicitly granted and protected through proper controls.

 - Since tools may trigger arbitrary code execution, hosts must treat them with caution and verify trust. Descriptions alone should not be trusted unless verified, and execution must be explicitly authorized.

 - Any use of LLM sampling must be user-approved. Users should be able to control whether sampling occurs, what prompt is sent, and what response visibility the server has.

MCP is unable to enforce these security principles; that is the responsibility of developers. And as a rule, they should follow these guidelines as outlined in the MCP spec:

The application should use robust flows for consent and authorization

All security implications must clearly be outlined in documentation

Appropriate access controls and data protection must be in place

Follow all security best practices when building integrations

When designing features, always consider privacy implications

Some diligence is required to ensure appropriate security controls are in place.

Expose tooling and capabilities to AI systems

Build modular integrations, composed of task-specific capabilities (such as retrieving metadata, or querying an audit log) that can be chained into larger, reusable workflows

Approach data security within your infrastructure

These attributes and Anthropic’s credentials have seen it quickly gain traction. Despite its release in 2024, MCP is becoming an industry standard and is now 

Cloudsmith has built a prototype MCP server as a step towards LLM and AI agent interaction with the artifacts and data in your Cloudsmith workspace. This could radically transform how you can control your software supply chain. It would replace potentially time-consuming command-line or UI workflows and provide fast and intuitive control with natural language prompts.

For example, ask questions like “List all versions of a particular library in Cloudsmith.”, “Tell me how many packages I have in Cloudsmith with a high CVE or that would violate a certain policy.”, or “If I reduce retention from 90 to 30 days, what will be deleted? How will that impact my allowances?”.

The image below shows an example from our proof-of-concept MCP server Claude integration. We asked, “What repository contains the Ubuntu 14.04 Docker image?”

Cloudsmith is in the early stages of this research, but our initial prototype is showing huge promise. For more information and examples, see 

MCP clearly represents an exciting opportunity for application developers to plug into AI in a scalable and economical way. Cloudsmith has started this journey with our MCP server. DevOps and developer teams will soon be able to use intelligent agents to automate, assist, or enhance their artifact management and software supply chain workflows. This is potentially transformative and may well become the future of artifact management.

If you'd like to register for early access to the Cloudsmith MCP server, 

Ian Taylor

Tech Content Director

Adding AI to applications using the Model Context Protocol

This blog contains the takeaways from our webinar "State of the Union: Modern security approaches for the Software Supply Chain." Watch the full discussion 

. Key topics include how to secure your CI/CD pipeline and software artifacts using SBOMs, Docker Hardened Images, and artifact lifecycle best practices.

Software supply chain attacks are on the rise, prompting a critical shift in how we secure modern software. Recent incidents like SolarWinds, XZ Utils, and Log4Shell underscore the urgent need for stronger security measures beyond just protecting production systems. Attackers are now targeting earlier stages of the supply chain, particularly build pipelines, impacting software integrity before it even reaches deployment.

State of the Union: Modern security approaches for the Software Supply Chain

 we brought together industry experts to tackle these challenges head-on. Michael Donovan, VP of Product at Docker, Ralph McTeggart, Principal Engineer at Cloudsmith, and Jack Gibson, Senior Software Engineer at Cloudsmith, shared their insights on how leading teams can defend themselves. During the session, they explored the evolving threat landscape, outlined a secure artifact lifecycle, and discussed strategies such as SBOMs to inject visibility, provenance, and trust into workflows without creating developer friction. While the focus was on container images, the principles discussed were equally applicable to other formats.

Rethinking Software Supply Chain Security

Software supply chain attacks have grown dramatically in both frequency and impact, prompting a fundamental shift in how software is secured. Incidents like SolarWinds, the XZ Utils backdoor attempt, and Log4Shell illustrate a sobering truth: attackers are now aiming upstream. Rather than targeting production systems directly, modern threats exploit vulnerabilities during the software build and integration phases, where visibility and control are often weakest.

As this attack surface expands, it’s no longer enough to harden runtime environments or secure production endpoints. The entire artifact lifecycle - from development to deployment - must be secured. This shift has led organizations to reassess their tooling, processes, and practices around software composition, packaging, and distribution.

The Shift in Emphasis on Software Supply Chain Security

The strategic focus of software security has moved upstream. Major breaches have shown how attackers exploit weaknesses in CI/CD pipelines, source code repositories, and registry infrastructure, areas traditionally outside the purview of security teams.

Events like the SolarWinds compromise in 2020, which leveraged a poisoned build system, or the 2024 XZ Utils incident, where malicious code was inserted by a fake maintainer, underscore how early-stage compromises can lead to widespread downstream impacts. Similarly, Log4Shell revealed the global exposure caused by a single vulnerable dependency, forcing organizations to redirect substantial resources just to locate and patch affected systems.

In response, governments and regulatory bodies have escalated their focus on software supply chain security (SSCS). Executive directives, such as the U.S. Cybersecurity Executive Order, FedRAMP requirements, the EU’s NIS2 directive, and the forthcoming Cyber Resilience Act, demand secure development practices, transparent artifact composition, and provable software provenance.

As attacks increasingly originate at the source, securing the artifact lifecycle is now a foundational requirement - not a future goal.

Modern software development is built around composability and speed. Applications today rely heavily on third-party libraries and frameworks, with open-source components making up as much as 75% or more of a typical codebase. The prevalence of transitive dependencies - indirect libraries brought in through direct ones - adds complexity and opacity to risk assessment.

At the same time, the efficiency of CI/CD pipelines can leave little room for traditional gatekeeping. Code is integrated, tested, and deployed rapidly, often using packages pulled directly from public registries with minimal verification. Unsigned artifacts, missing provenance data, and outdated registry configurations persist across many organizations.

This environment creates ideal conditions for silent, hard-to-detect supply chain threats. In response, software teams must move toward practices that ensure transparency, verification, and control at every phase of the build and release cycle.

Using SBOMs and Establishing Provenance

A foundational step in securing the software supply chain is understanding exactly what is being built and shipped. This is where three elements play a critical role:

SBOMs (Software Bills of Materials): These list all components within a software artifact - names, versions, authors, licenses, and dependency relationships. Tools such as Syft and Trivy support SBOM generation in SPDX and CycloneDX formats. Docker supports SBOMs natively through the docker sbom command. Cloudsmith accepts external SBOM uploads or can auto-generate CycloneDX SBOMs for container images, exposing them via API for automation and policy enforcement.

Digital Signatures: A signature confirms that an artifact originated from a known and trusted source. Tools like Cosign allow developers to sign and verify containers. Signed images enable downstream consumers to confirm authenticity before deployment.

Provenance: Provenance data describes the origin of a build, including input sources, build parameters, and environments. Docker Buildx supports automated provenance generation using the --provenance flag, capturing crucial metadata such as build arguments and platforms.

Together, these elements create an auditable trail of software origin and composition. In regulatory contexts, SBOMs are now a standard requirement. But beyond compliance, they provide security teams with the ability to trace vulnerabilities to specific packages, drastically reducing remediation time and effort. Cloudsmith’s Enterprise Policy Management (EPM) leverages SBOM metadata for automated policy actions, such as quarantining risky images or enforcing license compliance based on live dependency data

Tightening Security with Docker Hardened Images

As organizations grapple with securing sprawling software pipelines, Docker Hardened Images (DHIs) offer a straightforward way to integrate trusted, verifiable container artifacts into modern workflows, without slowing down development.

Available on Docker Hub, DHIs are a curated set of container images designed to minimize vulnerabilities out of the box. They are built with a smaller attack surface, and include a full suite of embedded security metadata by default. This makes them ideal for teams looking to adopt zero-trust practices without adding complexity or friction.

VEX (Vulnerability Exploitability eXchange) metadata

These attestations provide comprehensive visibility into the contents and origin of each image. Because they are packaged directly with the artifact, they integrate seamlessly into downstream platforms like Cloudsmith or any private registry. This removes the burden of generating and attaching this metadata later in the pipeline.

The impact is significant: DHIs can reduce vulnerabilities in base images by as much as 95%, offering a hardened starting point for secure application builds. Just as importantly, they help teams meet compliance and audit requirements from day one, with verifiable transparency and traceability.

By building security directly into the image and surfacing critical metadata in machine-readable formats, Docker Hardened Images simplify the process of building secure containers—and make modern supply chain security accessible by default.

Building a Secure Artifact Lifecycle

A secure software supply chain requires continuous validation from development through delivery. This is where centralized artifact management platforms like Cloudsmith become essential.

By configuring repositories to proxy public registries (e.g., Docker Hub, NPM, PyPI), Cloudsmith performs key security checks automatically:

Artifacts are cached and versioned, offering security and development teams full visibility and control over dependencies. When an image is pulled, verification steps - including signature checks and attestation validation - ensure that only known, trusted, and reproducible software is admitted into builds or deployments.

However, the ecosystem still faces gaps. Many widely used packages, particularly in NPM and PyPI, lack signatures or attestations. As of late 2024, only 5% of the top 360 packages on PyPI had provenance data published through the trusted publisher workflow. This makes it difficult to assert origin or integrity for many upstream dependencies.

To address this, teams should introduce a secure intermediary - like Cloudsmith - between developers and public sources. This provides enforcement points for policy, visibility into dependencies, and the opportunity to filter and block unverified packages before they can compromise the build.

Once builds are finalized, signing them and recording those signatures in transparency logs (e.g., Sigstore’s Rekor) ensures traceability and trust. This final step solidifies confidence that artifacts were not tampered with before reaching production.

Security features must be accessible, automated, and non-disruptive to gain widespread adoption. Teams are more likely to maintain best practices when secure workflows mirror familiar development patterns.

 come pre-equipped with SBOMs, digital signatures, and SLSA-compliant provenance. These attributes allow teams to build secure pipelines without requiring additional tooling or custom scripting.

When paired with Cloudsmith, this enables organizations to:

Centrally manage and enforce policies on all artifacts

Control access and visibility across engineering teams

Integrate security checks without altering development velocity

The result is a zero-trust pipeline where software integrity is maintained automatically, and security is treated as a first-class concern throughout the SDLC.

The shift towards modern security approaches is undeniable. SBOMs, signatures, and attestations are becoming fundamental elements in software development. The impending legislation, particularly in the EU with the Cyber Resilience Act, will further mandate these practices.

For a deeper dive into securing your container workflows, check out our companion blog post, "

Securing Containers at Scale: Docker Hardened Images and Cloudsmith

Maia Livingstone

Campaign Manager

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

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.

Cloudsmith Blog

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Two Cathedrals: Cloudsmith + GitHub

Managing Users and User Groups: A Guide to OKTA and Cloudsmith Integration

Adding AI to applications using the Model Context Protocol

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

Kubernetes 1.33 – What you need to know

Integrating Dependabot with Cloudsmith Using OIDC

GitOps Pipelines with Codefresh and Cloudsmith

Announcing the Release of Cloudsmith CLI GitHub Action 🚀

Fortify Dependency Management With Cloudsmith + Dependabot

Zero Trust Pipelines with OIDC, Cloudsmith, and GitHub Actions