By submitting this form, you agree to our 

Answer ten questions about your artifact and supply chain practices. Get a maturity score from 0 to 5, with a breakdown of where your controls hold and where they don't..

Artifact Security Maturity Assessment

 is a modern CI/CD platform designed for Kubernetes and microservices applications. It provides developers with fast, powerful pipelines and deep integration with Kubernetes. The platform’s features, such as enhanced caching, parallelization, and flexible triggers, allow teams to optimize their continuous integration workflows.

 to offer a comprehensive GitOps platform for Kubernetes. GitOps helps teams automate their infrastructure and application management, using Git as the single source of truth for deployments. By leveraging Argo within Codefresh, developers can employ advanced deployment strategies such as canary releases and blue-green deployments, improving release quality and reducing risks.

Benefits of Using Codefresh and Cloudsmith Together

, a cloud-native artifact management platform, with 

 enhances your CI/CD workflows in several significant ways. This powerful combination automates artifact handling, simplifies deployments, and enables the adoption of GitOps practices for Kubernetes deployments.

By automating artifact publishing within Codefresh pipelines, developers can significantly reduce manual steps, minimizing errors and ensuring artifacts are securely available for deployment. Cloudsmith’s support for multiformat repositories ensures that microservices using different package formats—such as Docker, npm, Helm, and Maven—can be managed and retrieved consistently.

Integrating Cloudsmith with Codefresh streamlines deployment processes by allowing developers to pull artifacts directly into their Codefresh pipelines. Whether deploying Docker images or Helm charts, this integration ensures consistency across all environments, from development to production, reducing deployment discrepancies.

, developers can ensure that only approved and secure components are used in their pipelines. Features like quarantine and upstream proxying add further control over unapproved or vulnerable dependencies. This guarantees a secure, compliant software supply chain.

Adopting GitOps for Kubernetes Deployments

Combining Cloudsmith and Codefresh enables teams to fully adopt GitOps practices for Kubernetes deployments. GitOps ensures that deployments are automated and aligned with the desired state defined in Git repositories. With Argo built into Codefresh, continuous reconciliation of your Kubernetes clusters keeps your infrastructure consistent with what’s declared in your codebase.

By integrating these platforms, you automate artifact handling, simplify deployments, and enhance security—all while adopting GitOps practices for Kubernetes deployments. This empowers your team to focus on delivering value—writing code, innovating features, and improving products—while the integration handles the complexities of artifact management and deployment.

How to Set Up a Pipeline with Codefresh and Cloudsmith

Setting up a CI/CD pipeline that integrates Codefresh and Cloudsmith is straightforward. Below is a guide to configure your pipeline for seamless artifact management and deployment using either 

 and create repositories for your artifacts.

: Ensure you have access to a Kubernetes cluster connected to Codefresh for deployments.

Open your Codefresh pipeline and go to the 

Name the variable (e.g., CLOUDSMITH_API_KEY), input your API key, and toggle 

Reference the API key in your pipeline YAML using ${{CLOUDSMITH_API_KEY}}.

 in Cloudsmith (required for OIDC to work with Cloudsmith).

Claims: For example add your Codefresh account ID to restrict access. For more information on claims consult the 

Assign the service account you created earlier.

In Codefresh, set up OIDC authentication by configuring your pipeline to request OIDC tokens during execution.

Add steps in your pipeline YAML to obtain and use the OIDC token for authenticating with Cloudsmith.

Modify your pipeline YAML to include steps that push build artifacts to Cloudsmith after successful builds.

To publish Helm charts, you need to use the Cloudsmith CLI. Ensure that the CLI is installed in your pipeline environment. For more details, refer to the Cloudsmith Helm documentation.

Deploying Artifacts from Cloudsmith Using Codefresh

Codefresh offers several ways to deploy your Docker images and Helm charts to your Kubernetes cluster using artifacts stored in Cloudsmith:

Using the Codefresh GUI to Deploy on Demand

: Choose Docker images from your connected Cloudsmith Docker registry.

: Select Helm charts from your added Cloudsmith Helm repository.

: Use Docker images stored in Cloudsmith within your pipeline steps.

: Utilize the Helm step in your pipeline to deploy charts from your Cloudsmith Helm repository.

Kubernetes Templating (cf-deploy-kubernetes)

: Employ templated deployments for consistent configurations.

: Execute custom kubectl commands within your pipeline, referencing artifacts from Cloudsmith.

: Directly deploy Helm charts to your Kubernetes clusters.

: For advanced GitOps deployments, integrate 

 with Codefresh. This allows automated deployment of applications to Kubernetes clusters using Cloudsmith as your artifact source.

Example of Pulling a Docker Image Using OIDC

Below is an example pipeline demonstrating how to authenticate with Cloudsmith using OIDC and deploy a Docker image:

: Retrieves an OIDC token required for authentication.

: Uses the OIDC token to obtain a Cloudsmith-specific token.

: Logs into the Cloudsmith Docker registry using the obtained OIDC token and pulls the desired Docker image.

: Verifies the successful pull by checking the Docker image's history.

: Ensure that the Cloudsmith CLI is installed in your pipeline environment if you plan to publish Helm charts or perform other CLI-based operations. Refer to the Cloudsmith Helm documentation for more details.

: Prefer OIDC over API keys for enhanced security and simplified credential management.

 when deploying artifacts from Cloudsmith. This ensures that deployment pipelines only have the necessary access to pull artifacts without the risk of modifying or deleting them, thus improving the security of your deployment process.

: Store sensitive information like API keys or OIDC tokens securely using Codefresh's encrypted variables or secret management features.

: Leverage Codefresh pipelines and GitOps practices to automate deployment steps, reducing manual intervention and potential errors.

: Utilize Codefresh's dashboards and integrations to monitor deployment status and health, ensuring quick identification and resolution of issues.

: Maintain your deployment manifests in Git repositories for version control, traceability, and easier collaboration.

Integrating Cloudsmith with Codefresh optimizes your CI/CD pipelines by providing secure, automated artifact management and simplifying deployments. With Cloudsmith’s support for multiple package formats and Codefresh’s robust CI/CD capabilities tailored for Kubernetes and microservices, this integration is ideal for modern, distributed applications.

Ciara Carey

Solutions Engineer

GitOps Pipelines with Codefresh and Cloudsmith

products lies in their architecture, design philosophy, and how they leverage cloud infrastructure. Let’s break down the key distinctions:

A Cloud Native product is specifically built for the cloud from the ground up. It is designed to fully utilize cloud computing capabilities such as scalability, elasticity, and high availability.

Microservices / Distributed Architecture:

 The application is often broken down into microservices and/or leverages Cloud-Provider managed services, with each service independently deployable, scalable, and manageable.

: They can automatically scale up or down based on demand, making them more efficient in handling fluctuating workloads. Also, the scaling can be more fine-grained, to specific parts of the service/platform

: Cloud-native applications are built to use cloud-specific databases (e.g., AWS Aurora Postgres, DynamoDB or Google Cloud Spanner etc) and services designed to take full advantage of cloud features. They are “Infrastructure Aware”.

: Cloud-native appliications typically support rapid development cycles, using CI/CD pipelines to automate deployments seamlessly with zero downtime. This means faster updates, releases, improvements and fixes.

Example: A cloud-native SaaS product like Netflix or Slack is architected specifically for dynamic cloud environments, offering high availability, multi-region support, and easy scaling.

A Cloud Hosted product is typically a legacy or traditional software application that was originally built for on-premise environments but has since been moved to the cloud. Instead of being designed with cloud-native principles, it's hosted on virtual machines or cloud infrastructure and usually does not fully leverage cloud-native features.

: These products are often built as large, single applications that run as an instance rather than being divided into smaller, scalable services.

: Rather than using containers or orchestration, these apps may be hosted on traditional virtual machines or cloud servers (e.g., AWS EC2 or Azure VMs).

: Cloud Hosted products may not scale as efficiently or dynamically as cloud-native products, requiring the entire instance to be scaled up or additional whole instances spun up and clustered/replicated, making them less responsive to real-time demand compared to cloud-native apps.

: These products often still rely on traditional infrastructure or databases (Like MySQL or Oracle), with those databases hosted in the cloud on a virtual machine.

An example could be older CRM systems like SAP or older ERP software moved to the cloud but without restructuring/re-architecting the core software to fully utilize cloud-native principles.

In essence, "Cloud Native" means that an application is inherently designed to take full advantage of cloud computing, whereas "Cloud Hosted" applications are more of a legacy or traditional application that's been minimally adapted to run on cloud provider infrastructure. Cloudsmith is a true Cloud Native Artifact Management product.

It’s just not easy to take a traditional application and make it Cloud Native, it’s much less development effort just to host that application on a cloud provider’s infrastructure. To be truly Cloud Native requires Cloud technologies and services to have been considered when an application was architected. To do this with a traditional application that can be installed on a server on-prem or a VM in the Cloud is essentially a rewrite of the application, and that is a monumental effort for a vendor, especially when they have an installed base of users. Ultimately, it would be an entirely new product.

Dan McKinney

"Cloud Native" - Why it matters?

It’s a fairly common perception that a package repository is basically a file share or file storage, and perhaps for some of the most simple implementations, this is a reasonable analogy.

However, when thinking of Cloudsmith, this analogy misses a lot of important details that make Cloudsmith package repositories rather unique.

If you have used Cloudsmith, you may have noticed that when you publish/upload a package to Cloudsmith or fetch a package from a public package repository (Like Maven Central or PyPi) into Cloudsmith, the first thing that happens is that the package enters a “Synchronizing” state. What exactly is synchronizing?Put simply, synchronization is where Cloudsmith processes the uploaded/ingested package. But that still belies a lot of the detail. What possible processing could a package need? Well, quite a lot actually!

Some of the steps that synchronization/package processing involves are:

 - Setting up the initial state, tools and environment for synchronization.

 - Getting the package files from the upload storage location.

 - Extracting the package files and package assembly (layers and configs for Docker images, for example)

 - Once we have the complete package file set, we scan the files for trojans, malicious content etc.

 - Verify and generate package checksums and signatures, as well as parse and verify package metadata and licenses.

 - Local and Distributed Storage synchronization.

These processes are automatic, require no user interaction and run asynchronously on Cloudsmith's global infrastructure. They are a large part of what empowers Cloudsmith users to implement effective package controls. As they say, knowledge is power - and it’s by the process of synchronization that we gain the knowledge of packages.

Once a package has been synchronized, we can then use the metadata generated to apply things like Vulnerability, Licence and Package Deny policies, create a scoped access token, add tags to the package, or fire a webhook for specific packages/versions. The data generated from synchronization drives a lot of the subsequent actions and workflows that you can perform.

Also, you may encounter occasions where a package fails synchronization:

This is typically a good thing (contrary to initial impressions!) because it can alert you to a problem with the package itself such as invalid/missing/incorrect metadata (the package not meeting the specification for the package type, for example), the presence of Malware in the package, or that you are attempting to upload/publish a package that already exists in the repository (as above). Package synchronization is an essential step in verifying the “correctness” of a package and It’s always better to catch things earlier in your processes than later, as the cost of remediation rises dramatically the later issues are identified.

Cloudsmith Package Repositories do far more than just store your packages, and they have a lot more functionality than just storing your packages in an AWS S3 bucket or Azure Blob Storage, or spinning up a simplistic instance of a package repository. Packages in Cloudsmith repository are so much more than just “bits on disk”, and treating them as such is really doing them a disservice!

What happens when you upload a Package?

Optimized for distributed teams working at any scale, Cloudsmith is your single source of truth for software assets. Proxy and cache to public upstreams, and use our Zero Trust model to control access to your most valuable IP. We’ve spent years creating the industry’s only true cloud-native solution to global software distribution at any scale. Let’s get you shipping without friction!

Booking a meeting with the Cloudsmith Team

You can find the Cloudsmith team in the sponsor showcase at booth K6 across from meal break seating, Wednesday - Friday. Stop by and see us to:

Speak with our experts about fully managed, scalable artifact management

Learn how your team can cut costs, speed up production, safeguard your code, and boost productivity

Catch a demo from an expert anytime, just stop by!

Take home some epic swag! We're bringing limited edition stainless mugs and beanie caps for your next mountain adventure!

Grab a limited edition "SLC 2024" Lego brick

We've partnered with Chainguard, Docker, Github, Sysdig + Tailscale to give away some epic prizes! Grab a "lift ticket" from any partner booth and collect your stamps before the end of KubeCon for your chance to win:

Kick-off KubeCon on Tuesday with us at the House of Kube!

Cloudsmith is proud to sponsor the (un)official opening party everyone talks about, House of Kube! Reach out to events@cloudsmith.com to request a ticket if the event is sold out. 

Cloudsmith is proud to partner with Chainguard, Docker, GitHub, Sysdig and Tailscale to bring you THE party after-KubeCon, AprésKube! Hang out and connect with DevOps, DevSecOps, Cloud, and Open Source professionals from communities around the world at Gracie's in Salt Lake City. Reach out to events@cloudsmith.com to request a ticket if the event is sold out. 

Lee Skillen

Chief Technology Officer

Cloudsmith is headed to Salt Lake City for KubeCon North America 2024

Package promotion workflows are a great way to isolate and protect production repositories, allowing progressive levels of security and permissiveness for development, staging, and production environments.

Once a binary is uploaded to Cloudsmith, it can move from development -> staging -> production, maintaining the integrity of the asset and its provenance trail. This migration takes place entirely within Cloudsmith; there’s no package delivery cost.

The differences between Dev, Staging and Production environments.

Cloudsmith's package promotion instructions- package copy/move actions

Complementary features that play nicely with package promotion, including webhooks, quarantining, policy management and upstreaming. These can be used together to create workflows and drive actions.

A Potential workflow for package promotion

Policy management that lets you set up policies that serve as prerequisites to package promotion.

Differences between Dev, Staging, and production environments

Typical software development organizations maintain three types of environments: development, stage, and production.

environment is used for developers early in the software process to see how new features will work, to try out improvements and pull in new dependencies or update existing dependencies.

 environment is used for testing integration and is a production-

environment that allows user creation without impacting production data. Only whitelisted IPs typically have access to Staging.

 environment is what end users are using on a live system.

Cloudsmith's package promotion workflows are powered by features to copy and move packages between repositories, usually for promoting immutable versions of packages between separate build, test, staging and production pipelines. The package that was verified in build is the same package in production when it gets promoted to there. Cloudsmith facilitates the automation of copying and moving packages using our command line interface (CLI).

 for vulnerabilities and license issues. This ensures that only secure and compliant artifacts are promoted through the pipeline, with policies applied to block or quarantine packages that fail these checks.

Let's see an example of moving a package in action:

 package was moved (or "promoted") from the source repository to the destination repository. Copying packages works the same, except it duplicates the package rather than moving it from the source to the destination.

In addition to moving and copying packages, you can also resync packages via the CLI, whereby the CLI will retry packages that have failed (for whatever reason) up to a configurable amount of attempts.

To see the full list of help for actions, run the following commands:

Package promotion on its own is great, and you can couple it with other features to create workflows and drive actions. Let's talk about tagging, webhooks, multiformat repos, vulnerability scanning, and setting up upstream.

 feature allows you to label your packages with tags like "dev", "staging", or "prod" as they move through your pipeline. These tags help in tracking packages across different environments, and enable targeted searches, filtering, and control over what artifacts are accessible. By using 

, you can automate package promotions based on tag transitions, such as promoting a "staging" package to "prod" once it passes certain tests). This enhances visibility and governance within your pipeline and simplifies the overall package management process.

Webhooks let apps send automated messages or information to other apps. 

 are great for integrating Cloudsmith with other systems in your build pipeline, by sending data or notifications to other tools in your stack and helping to enable automation across your workflows.

Cloudsmith has webhooks for vulnerability scanning. Anytime a scan is completed, Cloudsmith can dispatch a corresponding vulnerability webhook to trigger some action, like creating a Jira ticket.

Cloudsmith's vulnerability scanning is particularly effective when combined with upstreams. Upstream proxying and caching allow you to upload and use the packages you author in-house directly, while Cloudsmith fetches and caches your dependencies from public repositories like Maven Central or NuGet.org.

This enables you to use Cloudsmith as a first-class cache and a central source of truth for packages, to protect you from issues related to use of external services, such as downtime, rate limiting, or non-availability of a previously available package.

Packages fetched from a caching-enabled upstream will be automatically scanned for vulnerabilities for Ultra customers.

Multi-format repositories allow you to store artifacts of different formats in the same place. Organize your packages by environment, project, package type, or whatever way you see fit.

Package vulnerability scanning is a key step in securing your software delivery pipeline and reducing the risk of releasing insecure software into production.

Cloudsmith automatically scans every supported package format pushed to a Cloudsmith repository or fetched from a caching-enabled upstream.

Cloudsmith's vulnerability scanning feature is available for the following package formats:

Cloudsmith's Security Scanning page shows a breakdown of the number of packages scanned/not scanned, the age of scans, the pass/fail count overall and the maximum severity of those found.

Setup your Dev repository with upstreams and your Staging repos with no upstream

Push your package to Dev repository and tag the package with ‘dev’.

Automatically tag the package with ‘staging’ and move the package to the Staging repository when the results return with no vulnerabilities.NOTE: you may want to run more manual tests against this package before promoting it.

 for the examples below. The CLI interfaces with Cloudsmith's API and allows users, machines and other services to access and integrate smoothly with Cloudsmith without requiring explicit plugins or tools.

Setup your Dev repository with upstreams and your Staging repository with no upstreams

Create 2 repositories Dev and Staging by following the instructions 

.

Set up an upstream for the Dev repo by following the instructions 

A vulnerability scan is automatically triggered for supported packages every time they are pushed into a Cloudsmith repository. If you set up an upstream, your 3rd party dependencies are also scanned for vulnerabilities.

Cloudsmith supports over 30 different types of packages. 

Upload via the package-specific native CLI / tools e.g. using Maven's 

Upload via the API using tools/integrations (such as the official Cloudsmith CLI).

To upload a package via the Cloudsmith CLI, use the cloudsmith push command:

Setting up webhooks so Cloudsmith can send automated messages to alert another system when a package had been scanned is great for setting up vulnerability workflows.

 in your repository and then create a new webhook. Then:

 with the tool you want to receive your webhook like 

You can test out the Webhook by selecting to 

The webhook is triggered when the scan is finished and will have a payload in the HTTP req with information about the package and any vulnerabilities, including:

This information can drive actions such as tagging and promoting a package based on the maximum severity reported.

, use the command cloudsmith tag as follows:

cloudsmith tag add OWNER/REPOSITORY/PACKAGE TAG1, TAG2

 promote a package use the Cloudsmith CLI command cloudsmith cp or mv as follows:

For example, using the data from the snippet above where 

 is the package identifier or the package 

cloudsmith cp demo/examples-repo/IB6FYhIvaoAy

Enhance your Workflows with Policy Management

To further secure and streamline your package promotion workflows, Cloudsmith’s 

 features can be used to automate and enforce critical security measures. With 

, you can automatically block or quarantine packages that violate license rules, while 

 scan for potential risks, quarantining packages based on severity. 

 enforce API-key rotation to ensure secure access.

These policies make your workflows more secure, compliant, and automated—minimizing manual intervention and reducing risk across your software supply chain. To explore these features in more detail, check out our blog on 

Looking ahead, Cloudsmith’s Enterprise Policy Manager will further enhance promotion workflows with advanced controls.

 It will allow policies to be applied at any decision point, ensuring real-time enforcement of security and compliance rules like “should we allow this action?”
Key features include:

: Create custom policies tailored to your specific needs, from access control to package promotion.

: Manage and trace policies at scale for better compliance.

: Integrate data like Cloudsmith Navigator and security scanners for more informed decisions.

: Speed up implementation with best-practice policy templates.

: Leverage your existing security tools within Cloudsmith.

How to Manage Your Package Promotion Workflows with Cloudsmith

Managing modules/packages, whether hosted privately or sourced from public registries, presents challenges such as security vulnerabilities, lack of visibility into package usage, and dependency on the availability of public registries.

 directly addresses these issues, offering secure, controlled, and efficient package management for both private in-house modules and public npm packages.

How to use Deno and Cloudsmith for 2 different use cases:

Modules sourced from npm but proxied and cached in Cloudsmith.

 is a complete, “batteries included”, JavaScript and TypeScript toolchain, which includes a runtime, 

, and more. Deno addresses the shortcomings and 

 of Node by making it more simple and secure. It includes 

Integrating Cloudsmith with Deno offers a powerful solution for managing npm packages, whether they are private or sourced from public registries. Here's why Cloudsmith is the ideal partner for your Deno projects:

Deno’s security-first architecture pairs perfectly with Cloudsmith’s private npm registries, ensuring only authorized users can access your npm packages.

: Deno’s modern runtime makes it easy to manage dependencies, but visibility into them is crucial. Cloudsmith provides full transparency into all packages used in your Deno projects, whether stored privately or proxied from npm. This visibility lets you easily track, audit, and manage all dependencies, helping you maintain a secure and reliable codebase.

: Cloudsmith will verify every npm package in your Deno project by automatically scanning it for security and compliance threats.

: Leverage Cloudsmith’s caching to speed up builds and ensure that your Deno projects are not dependent on the availability of public registries.

By leveraging these benefits, Cloudsmith enhances your ability to manage and secure your software supply chain, leading to faster development cycles, more reliable deployments, and greater peace of mind.

Use Case 1: Managing a Private In-House Module with Cloudsmith

When working on sensitive projects or proprietary software, ensuring that your npm modules are private and secure is crucial. Here’s how to manage these private modules using Cloudsmith with Deno.

Let’s start by showing you how to use a private npm module stored on Cloudsmith in a Deno project.

Step 1: Set Up Your Cloudsmith Repository

creating a private repository in Cloudsmith

 to store your npm modules. Cloudsmith’s repositories are 

, meaning you can store packages of different formats (e.g., npm, Docker, Maven) in the same repository.

Step 2: Create and Publish Your npm Module

. For example, if you have a module called my-fave-npm-package, you would publish it using npm:

Cloudsmith Blog

GitOps Pipelines with Codefresh and Cloudsmith

"Cloud Native" - Why it matters?

What happens when you upload a Package?

Cloudsmith is headed to Salt Lake City for KubeCon North America 2024

How to Manage Your Package Promotion Workflows with Cloudsmith

Level up your private npm registries in Deno with Cloudsmith

Reflecting on ShipItCon 2024: High-performing teams need flow

Announcing the Release of Cloudsmith CLI GitHub Action 🚀

What Makes Cloudsmith Special: Reflections on 1 Year as CEO

Using Cloudsmith as a Dependency Firewall

5 Lessons on the Evolution From DevOps to Platform Engineering

Fortify Dependency Management With Cloudsmith + Dependabot