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

Attacks targeting open source software (OSS) are on the rise, making the security of your software supply chain a top priority. What do you have to do, exactly, to secure your software supply chain?

This is the third blog in a Cloudsmith series about software supply chain security. The first blog gave an overview of the

Secure Supply Chain Consumption Framework (S2C2F)

, which is designed to mitigate against these attacks.

Level 1 of S2C2F is the bare minimum organizations should do to securely consume OSS. Today's blog focuses on the actionable steps and essential tools required to attain Level 1.

Level 1 primarily centers on the ingestion of OSS and requires the following:

Use an artifact repository (like Cloudsmith!) to cache OSS

Maintain an automated OSS inventory, such as a software bill of materials (SBOM)

Scan OSS for known vulnerabilities and licenses

Update your vulnerabilities (manually is okay at this level)

A major step in Level 1 is the adoption of an artifact repository like 

 as a central location for all OSS packages. This facilitates applying security controls for your OSS, and guarantees the availability of OSS package dependencies and protects you from incidents like the

Let's refresh on the eight principles of S2C2F:

— Consume your OSS from one location controlled by your organization, like Cloudsmith.

 — Create a list of all your OSS dependencies.

 — Update known vulnerabilities in a timely manner.

 — Force developers to adopt secure practices.

 — Audit that developers are consuming through the approved ingest method, and validate the integrity of the OSS that you are consuming.

 — Scan for malware and vulnerabilities using automation where possible.

 — Rebuild OSS on trusted infrastructure.

 — Have the ability to fork and fix code, when necessary, for a temporary fix.

Level 1 of the S2C2F concentrates on the Ingestion, Inventory, Scan and Update principles. The following initiatives are required:

Before you start implementing changes in your organization to align with S2C2F it is advised that you 

 of the organization's degree of maturity in software developer OSS management, security, and consumption processes.

Use a package manager to consume OSS packages. A package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. Scroll to the table below for a list of commonly used languages and their respective package format, registry, etc.

 to host all of your software packages and OSS packages. To set up Cloudsmith to cache your upstream OSS, do the following:

Update your software’s configuration file to point to your artifact repository (see the table below for the settings file for popular languages).

Start hosting your OSS packages on Cloudsmith by 

caching your public repositories or upstreams

. If the upstream repository you depend on goes down or is otherwise unavailable, your team can still access your cached versions stored in Cloudsmith. Cloudsmith will scan all the OSS packages for malware and vulnerabilities and also extract their licenses. This setup empowers our users to apply customized policies for enhanced security and management.

Level 1 of S2C2F requires organizations to maintain an automated inventory of all OSS used in development. There are a number of ways to take an inventory of your OSS

The gold standard for inventorying your OSS is to 

generate a Software Bill of Materials (SBOM)

 at build time. An SBOM is an ingredient list of all the dependencies in your software in a standardized format. SBOMs are needed for more advanced levels of this framework. OSS tools to generate SBOMs that can be integrated into your CI/CD include 

If you cache and proxy all the public registries that your organization uses on Cloudsmith, you can 

search for all packages that originated from an upstream

 via the UI or API by searching for tag:upstream (or even tag:maven-central if that's what you named the upstream when setting it up etc).

You can use your software’s dependency file (e.g. requirements.txt for Python builds) to see what dependencies your software is pulling in. This file may not include your software’s transitive dependencies (your dependencies’ dependencies).

Scan OSS for known vulnerabilities (i.e. CVEs, GitHub Advisories, etc.). Here are a few ways to do this:

Ideally you are integrating scanning tools early in your software development process using free tools like grype or paid tools like snyk.

Cloudsmith scans cached OSS for malware and vulnerabilities

. You can set a policy so that all packages must be above a certain vulnerability level and you can rescan a package for vulnerabilities.

Scan all the OSS in your organization for licenses.

for all cached OSS packages. Cloudsmith’s license policies allow you to define which package licenses are allowed within your organization.

Update vulnerable OSS manually using the results of your scanners, Level 1 S2C2F requires you to update vulnerable OSS manually. The framework advises that every organization should aspire to patch vulnerable OSS packages in under 72 hours. More advanced levels of S2C2F require you to use tools like 

Ingest it Inventory it Scan it Update it Cloudsmith
package managers Cloudsmith
Dependency-Track
CycloneDX
Syft
Trivy Cloudsmith
Grype
Snyk Manual (Dependabot for automation)Package InformationLanguage Package Format Package Manager Public Registry Config File Dependancy File Java JAR (Java Archive) Maven 

 pip.conf requirements.txt .Net (C#) NuGet NuGet 

 NuGet.config packages.config JavaScript/Node npm npm 

 package.json package-lock.json C/C++ No standardized format
vpkg and Conan are popular No standardized pm
vpkg and Conan are popular 

 conanfile.txt (for Conan), CMakeLists.txt (for CMake), vcpkg-configuration.json for vcpkg conanfile.txt (for Conan), CMakeLists.txt (for CMake) Rust Crates Cargo 

 .gemrc Gemfile Go Go Module go Go doesn't have a centralized registry go.mod go.sum PHP Composer Composer 

By prioritizing ingestion, inventory management, and scanning, you'll bolster your software supply chain's resilience against potential threats. Leveraging package managers, artifact repositories like Cloudsmith, and automated inventory tools enhances security and guarantees availability when consuming OSS.

What’s next from Cloudsmith? In future blogs, we’ll discuss how you can achieve the advanced S2C2F framework levels, offering actionable steps to further enhance your OSS consumption practices and fortify your software ecosystem. Subscribe below!

Register here for our upcoming webinar on S2C2F

 with the creator of S2C2F and leader of the Secure Software Supply Chain team at Microsoft, Adrian Diglio.

Secure Open Source Consumption: Level 1 of S2C2F

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Checking that the allocation of memory succeeded.

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

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

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

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

The C++ Core Guidelines advise against using 

 directly for creating dynamic objects in favor of smart pointers through 

 for reference-counted multiple ownership.

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

Operating system kernel settings like ASLR and stack canaries.

Why mitigations against memory vulnerabilities aren't enough

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

really impressive developer workflow at 15hrs/16hr

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

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

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

 but it comes with a steep learning curve.

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

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

Google launched a new programming language called 

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

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

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

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

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

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

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

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

Cloudsmith supports memory-safe languages

Could 2023 be the year of memory safety?

A vulnerability is a flaw in your software product that an attacker can exploit. A critical and easily exploitable vulnerability, like 

, can facilitate Remote Code Execution (RCE), allowing an attacker to remotely execute malicious code on a computer. 

Sonatype’s 2021 state of the software supply chain

 found that supply chain attacks, which include attacks that target vulnerabilities in software, are up 650%.

But finding vulnerabilities is not a piece of cake- people are still searching for packages vulnerable to Log4Shell in their system.

Cloudsmith, as a hosted package management service, wants to help our users secure their software supply chain, and one component of that is extending its support for vulnerability scanning to include Docker, Ruby, Python, Composer, Maven, NuGet, Golang, Cargo and npm.

Cloudsmith will automatically scan supported package types for CVEs when a package is pushed to a Cloudsmith repository or fetched from a public repository. You can use the results of a Cloudsmith Security Scan to drive other actions such as quarantining a package, or as part of a package promotion workflow. We know that vulnerabilities can be found after you build your software, so Cloudsmith allows you to trigger rescans on demand via the API/UI.

Cloudsmith blog

How to Manage Your Package Promotion Workflows with Cloudsmith

Secure Open Source Consumption: Level 1 of S2C2F

Could 2023 be the year of memory safety?

How to Manage Your Vulnerability Workflows with Cloudsmith