By submitting this form, you agree to our 

Why we chose it, how we built on it, and where we’re going next

Ensuring the integrity of open source software is a growing priority for organizations of every size. But doing it in a way that doesn’t slow down developers is hard.

We believe the right long-term answer is a curated repository of known-good open source software that is continuously verified, with your organization’s security and compliance policies applied, and deeply integrated into your core workflows.

Cloudsmith is the right place to do this. We’re not just hosting packages; we’re providing the control plane and data plane for the software supply chain. And that starts with how we handle vulnerability data and threat intelligence.

We chose Trivy as the base for vulnerability scanning at Cloudsmith because it’s open source, fast, and widely trusted. 

We integrated Trivy into our cloud-native platform, giving our customers access to 

We’re expanding beyond Trivy, ingesting multiple data sources and ultimately adding pluggable security integrations.

 A curated, secure, resilient software supply chain that keeps developers productive and organizations safe.

 early on, as we were building Cloudsmith. It’s open source, well-supported, and widely trusted. It offers support for containers, OS packages, language dependencies, SBOMs and secrets scanning. It’s also well-maintained; with over 27,000 GitHub stars, millions of downloads, and millions of users, the global developer community clearly values the capability that Trivy provides.

It’s no surprise that Trivy is the default scanner in many other platforms. But integrating it into a cloud-native platform like Cloudsmith, where artifacts are constantly being pushed, pulled and promoted across repositories, meant solving for cloud scale, automation, and extensibility.

Trivy helped us get high-quality results fast. Here’s how we super-charged it for our customers.

Every artifact pushed to or cached through Cloudsmith is scanned automatically, without any manual configuration or setup required. This means security is built into the pipeline from the very first interaction. The scans run in the background, ensuring zero friction for developers while giving teams continuous visibility into security risks.

: Every Docker/OCI image published to Cloudsmith is automatically accompanied by an SBOM in the CycloneDX format. CycloneDX is widely supported across security tools and ecosystems, making it easy to integrate SBOMs into your broader supply chain risk management processes. By leveraging Trivy’s SBOM capabilities, we ensure that every image has a clear and standardized inventory

Because Cloudsmith is a universal artifact management platform, we can centralize vulnerability data for our customers across all of their formats and surface that information to them across their workspace. 

Cloudsmith is designed to work at global scale, so when we integrated Trivy as our scanner, we knew it needed to keep up too. Cloudsmith is 

proven to handle > 1 million requests per minute

 and we execute millions of vulnerability scans as customers add to their repositories.

Quarantine or notify when users are accessing insecure packages using Cloudsmith’s OPA based 

SAML, SCIM, OIDC, logging, and ISO 27001 compliance ensure a 

With Trivy running reliably across our platform, we started rethinking how to keep vulnerability data fresh and actionable.

We ingest CVE data continuously, from Trivy and also from additional sources like 

. And we apply that data to artifacts already in your repositories. That means no need to trigger rescans.

New advisory published? We re-check your existing packages against fresh data.

Define rules using CVSS, EPSS, license metadata or any other detail about your package, and act on them automatically.

 Every match, every decision, and every policy action is logged.

So we can add data sources like OSV.dev and package health signal data.

This turns scanning into a real-time feedback loop, so you can catch new risks as soon as they emerge.

The presence of CVEs isn’t the only signal about the quality of software packages. Our goal is to help you make better decisions about all the software in your supply chain based on trust, context, and quality, in addition to known vulnerabilities.

 New feeds (OSV, GitHub advisories, OpenSSF Scorecards) deepen our vulnerability data and unlock additional package formats.

 Build policies based on how well-maintained a package is, whether it has good documentation, how widely it’s been adopted, and other indicators of package health

 SBOM generation for additional formats, so you can build custom policies from your SBOM metadata.

Trivy kickstarted it. Cloudsmith takes it further.

Push an artifact. Let Cloudsmith scan it, sign it, apply policies, and let you know when new threats emerge. Security shouldn’t slow you down. With Cloudsmith, it doesn’t.

 Push an image or package and watch your policies kick in, so you can sleep easier tomorrow when the next CVE lands.

Ciara Carey

Solutions Engineer

Using Trivy Inside Cloudsmith

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 Cloudsmith 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 

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. 

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?

Cloudsmith Blog

Using Trivy Inside Cloudsmith

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