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

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

Solutions Engineer

"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?

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

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

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

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

Open Container Initiative Distribution Specification

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

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

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

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

Proxying and caching from upstream repositories

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

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

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

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

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

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

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


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

How Cloudsmith helps you streamline K8s workflows

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

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

Streamline Kubernetes Workflows with Cloudsmith

At Cloudsmith, our mission is to be the universal package management solution for teams and enterprises. As a result, we continually expand and improve the package formats we support. We are delighted to be able to introduce support for 

public and private Conda package repositories

In this article, we will help you to understand:

The difference between Anaconda and Conda

Conda is a multi-platform open-source package management system. It was initially created to solve package management problems for Python data scientists and is now a popular package manager for Python and R packages, but you can also use it to manage packages for any language. Like all package management systems, Conda helps you create, find, and install packages you need.

Conda is also an environment manager. Suppose you need to use a package that requires a different version of Python. In that case, you can easily set up and switch to a development environment using that specific version of Python without needing to change the version of Python you use in your usual environment.

Conda started as part of the Anaconda Python Distribution but gained popularity on its own for things other than just Python and R package management and was then spun out as a separate project under a BSD licence.

A Conda package is typically a compressed tarball file (.tar.bz2) or, from Conda version 4.7 onwards, it can also be a .conda file. The .conda file format was introduced in conda 4.7 as a smaller and more performant alternative to a tarball. The tarball or .conda file usually contains:

Executable programs and other components.

A collection of files that are installed directly into an install prefix.


The structure of a Conda package looks like this:

 contains relevant binaries for the package.

 contains the relevant library files (e.g. the .py files).

In common with other package managers, collections of conda packages are available. For other package formats and types, terms like “repository”, “feed”, or “registry” are often used, but for Conda, packages are stored in “channels”.

A channel is a location where Conda packages are stored and are URLs to directories containing Conda packages.

The default channel for Conda is https://repo.anaconda.com/pkgs/, which contains thousands of Conda packages, including those maintained by Anaconda. You can also modify the channels you wish to search for packages, and add alternatives such as Conda-Forge (a community that provides Conda packages for a wide range of software) or even your own private or internal Conda channels, such as a private Cloudsmith repository.

For more information on configuring and managing Conda channels, please see the Conda channel documentation.

The most common users of Conda are those people developing and working with large scale data science, analysis and machine learning applications.

Why? Well, these users often face unique problems with package management that general-purpose package managers do not solve. For example, using multiple different versions of a package.

A core difference between Conda and the standard package manager for Python, pip, is in how any package dependencies are managed. Because Conda is also an environment manager, it can install different versions of any requested packages and their dependencies without conflicting with any existing installed packages.

To put this another way, pip is the general-purpose package manager for Python packages, and it installs packages within any environment. Conda installs packages within Conda environments.

While you can also achieve this isolation of environments via other solutions (such as Python virtualenv), it is standard and built-in when using Conda. So that means less to set up.

The first thing to do is install Conda, and the easiest way to do this is to install either Anaconda or Miniconda, which both include Conda itself.

Once you have Conda installed, you can verify that your installation is working correctly with a command such as 

 displays all the details of your current Conda installation.

Next, you can create a new Conda environment with the 

You can then activate this environment with the Conda activate command:


Activating an environment is vital to ensure that any installed Conda packages work correctly and are isolated from other package versions that you may have on your system or in other projects. If environments are not active, specific libraries and packages may not be found and is a common source of errors.

When your environment is active, you can now install Conda packages with the Conda install command. For example:

This command will install the numpy package and its associated dependencies into the environment. You are now ready to go and use the functionality provided by the package, and the specific version of this package you are using is isolated from other packages outside of this environment.

Several distinct communities utilize the Conda package format. Each of these communities has its own unique use case and tooling, and we've listed some of our favorites below:

PyData is an international community of users and developers of data analysis tools.

Anaconda is the home of the Anaconda Python distribution.

The Anaconda repository is the default channel for conda packages

Conda-Forge is a community-led collection of recipes, build infrastructure and distributions for the conda package manager.

Conda is a versatile package manager, suitable for a wide variety of uses but particularly suited to data analysis, data science and machine learning applications in Python or R. Conda is widely supported and has an active community of users and contributors.

The combination of package management and environment management reduces package version conflicts and enables effective isolation when working on multiple projects or tasks.

If you’re curious about Conda package management, start a free trial with Cloudsmith today. You can open your first repository within a matter of minutes.

Securely host your Conda packages alongside other package formats (in the same single repository! Read more about our multi-format repositories) and don't forget take a look at our detailed Conda documentation.

If you're intrigued to learn more about specific package formats, delve into our series below:

No - it’s a package format and the name of the associated command-line tool for interacting with conda repositories.

What is the difference between Anaconda and Conda?

Anaconda is a distribution of the Python and R languages with a specific focus on scientific computing applications like data science and machine learning. A software distribution is a pre-configured collection of packages you can use on a system.
Anaconda is a full distribution of the primary software in the PyData ecosystem, and it includes Python and packages for hundreds of the most popular open-source projects. It is developed and maintained by Anaconda, Inc. It is available in both free editions for personal use and Team and Enterprise editions for commercial use.

Conda is a distinct entity. It is the tool you use to interact with Conda repositories, build, push, install packages, and manage your local conda environments.

Miniconda is a bare-bones version of the Anaconda Python Distribution. The Anaconda Python Distribution consists of conda, Python, over 250 conda packages and the Anaconda Navigator (a GUI alternative to the command line tooling); Miniconda just contains conda, Python (and their dependencies) and a small number of additional packages.


What is Conda?

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 

Everything You Wanted To Know About Securing The Software Supply Chain

Getting Started with Terraform Modules and Cloudsmith

A quick walkthrough of getting set up with a private repository for Terraform Modules on Cloudsmith, including uploading and downloading modules.

Continuous Packaging (CP) is a term that we have coined here at Cloudsmith, and it is one that we think will become a cornerstone in a secure software development process.

Cloudsmith's Ciara Carey and Dan McKinney have partnered with O'Reilly to introduce the world to Continuous Packaging (CP), and how teams can implement CP into their software supply chains.

Explore the current state of software supply chains.

How developers can identify risks in their own supply chain.

Why CP is critical to secure CI/CD pipelines.

Otherwise, continue reading below to discover the fundamentals of Continuous Packaging!

When you think of modern software development workflows, you typically think of DevOps – and that involves continuous integration (CI) processes and continuous deployment or continuous delivery processes (CD).

These processes evolved to accelerate and improve the task of developing and delivering software at scale. They provide increased velocity, reliability and security through automation, controls and closing the gap between development and operations. Software isn’t “thrown over the fence” anymore when it goes into production. The process is end-to-end, from development right through to deployment or delivery.

As an industry, the adoption of modern DevOps processes like this has brought with it great rewards. Companies can grow faster, ship quicker, delivery of updates can be streamlined, and any issues, bugs or problems can be addressed with less delay.

Not quite! Let’s roll back a bit to the beginning.

Typically, you start with your source codebase. Your CI processes take this and build it into a set of artifacts, images or packages that your CD processes can then deploy to infrastructure or deliver to your customers.

So, there is something that CI and CD have in common, and that is software artifacts, images, or packages. These are the output of CI processes and the input for CD processes.

And this is where continuous packaging comes in. We see CP as a glue layer that sits between and overlaps CI and CD. To build secure software development pipelines using a DevOps methodology, you need the ability to universally store and deliver packages securely and efficiently across all package formats and languages.

It’s unlikely that you would use multiple source control tools or multiple CI or CD tools. You settle on the best-in-class tool for the task, and package management needs to be the same. CP should be a checkpoint - a layer that all packages, images, and artifacts used in and produced from your build processes and your deployments need to pass through. That layer is what empowers you and provides you with the control and visibility that you need.

And that is what it comes down to - At its core:

Continuous Packaging gives your teams security, control, visibility and management over incoming and built assets.

There is an ever-increasing focus on software supply chain security, and rightly so. Recent events have shown that attacks on the software supply chain are fast becoming the number one method that threat actors are employing to breach organizations and users’ security.

And why is this? Well, it’s because it’s a highly effective way to get malicious software distributed to many targets. These targets are increasingly aware of traditional attacks and have been educated to defend against them. What better way to gain entry to a target than through a legitimate update mechanism from a vendor or through a compromised software package that gets used in a build?

Software supply chain attacks manipulate the trust that users and companies place in vendors and the trust that developers place in code that they import or use from public registries and repositories.

So how exactly does CP provide you with that security, control, visibility and management? Well, to break things down a bit further, some of the key benefits of CP are:

Isolation – which gives you control and visibility

Provenance – Which provides you with security via a chain of trust

Acceleration – Which gives you low latency performance for your teams

Provenance is the ability to verifiably prove, using things like package checksums and cryptographic signatures, that software assets are what they say they are and are from who they say they are.

Continuous packaging is about providing a verifiable “Single Source of Truth” for all packages, images, or artifacts consumed or produced during your CI processes. It helps you protect your users and customers by building and shipping clean software only.

Up until now, at Deploy time, there are additional steps when pulling in other dependencies – there is a hole in the provenance chain, a gap to be filled, and having that single source of truth closes that gap.

It’s generally accepted that a lot of the software you run is built by someone else; it’s open-source or built on open source.

It’s a widespread practice in software development to use and depend on public packages - packages from a public repository and by connecting directly to a public repository, you open the door to possible attacks. This has already been demonstrated as an attack vector through Dependency Confusion attacks and the Codecov breach.

Continuous Packaging gives you a protective layer between your teams and public repositories; it defines isolation as the ability to cache packages away from public upstreams. Just some of the benefits this provides are:

- You control package availability. In the event an upstream becomes unavailable, you can continue to build and deploy.

- Protection from Vulnerabilities. If a vulnerability appears in a new version of a package, you have previous versions you may be able to roll back.

Cloudsmith Blog

"Cloud Native" - Why it matters?

What happens when you upload a Package?

Streamline Kubernetes Workflows with Cloudsmith

What is Conda?

Everything You Wanted To Know About Securing The Software Supply Chain

Getting Started with Terraform Modules and Cloudsmith

Getting Started with Continuous Packaging

Getting Started with Helm and Cloudsmith

Package Delivery Networks: How They Differ From CDNs

A Standardized Approach to SBOM

Using CircleCI to Push Packages to Cloudsmith

Restore Authority with Token Bandwidth Controls!