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

Instead of wasting time clicking buttons in a UI, Cloudsmith gives dev teams the freedom to write their security rules as code for more power and flexibility. This approach, called policy-as-code, requires them to define precise limits/thresholds for what they consider a risky software artifact. When you're building policy-as-code, you can sometimes be stuck deciding exactly what thresholds to set for risky software artifacts. With a tsunami of vulnerabilities being thrown your way daily, it's impossible (and inefficient) to treat them all as emergencies. This blog post will help you understand the various scoring systems you can use to build smarter, context-aware security policies.

What is CVSS (Common Vulnerability Scoring System)?

For years, the Common Vulnerability Scoring System (

) has been the industry standard for rating the severity of vulnerabilities. It provides a numerical score from 0.0 (Low) to 10.0 (Critical), giving security teams a consistent way to assess risk.

A CVSS score is derived from three metric groups:

 Assesses the intrinsic qualities of a vulnerability, like the attack vector, complexity, and impact on confidentiality, integrity, and availability. This is a theoretical, worst-case assessment.

 Reflects characteristics that change over time, such as the availability of exploit code or an official patch.

 Allows you to customize the score based on your specific environment, considering factors like the importance of the affected system.

While CVSS is excellent for understanding a vulnerability's theoretical potential for harm, it can't answer the most important question: "

Does this actually pose a threat to my environment right now?

 (Common Vulnerabilities and Exposures) identifier without an accompanying CVSS score. This happens for a few reasons:

A CVE ID is often assigned the moment a vulnerability is disclosed. The detailed analysis required to calculate a CVSS score comes later from non-profit organisations like the 

 Some vulnerabilities affecting obscure products or deemed too minor may never get formally scored.

 If researchers and vendors disagree on a vulnerability's impact, it might remain un-scored until a consensus is reached.

What is EPSS? (Exploit Prediction Scoring System) and Why It Matters for Risk Prioritization

This is where the Exploit Prediction Scoring System (

) changes the game. Managed by FIRST.org, EPSS doesn't measure theoretical severity; it estimates the probability (from 0% to 100%) that a vulnerability will be exploited in the wild within the next 30 days.


A high CVSS score signals potential danger, but EPSS provides the real-world context needed to answer critical questions like:

"Is this vulnerability reachable from the internet?"

EPSS uses a machine learning model trained on vast datasets of vulnerability and threat intelligence. It's continuously updated to provide daily probability scores, helping you focus on the threats that are most likely to materialise.

It’s important to note that the EPSS model itself is updated periodically to maintain its predictive accuracy. For example, EPSS v4 was introduced on March 17, 2025, to improve performance.

When you look up an EPSS value, you'll see two numbers:

The direct output of the model. This is the probability of exploitation. (for example 0.92, or 92%).

 Ranks a vulnerability against all others. A percentile of 0.98 (or 98%) means this vulnerability is more likely to be exploited than 98% of all other CVEs.

How to Build a Risk-Based Vulnerability Triage Strategy Using CVSS, EPSS, and KEV?

Neither CVSS nor EPSS tells the whole story alone. The most effective strategy combines them with other key data points, like the CISA Known Exploited Vulnerabilities (

) catalog, which lists vulnerabilities that are actively being exploited in real-world attacks.

By layering these sources, you can move from a theoretical risk assessment to an evidence-based one. Imagine you have thousands of vulnerabilities. Instead of chasing every "Critical" CVSS score, you can narrow your focus dramatically.

The goal is to get to a workflow like the one depicted above. Of 922 known vulnerabilities, 352 might be rated "Critical" by CVSS. But by applying EPSS, you might find that only a small fraction have a high probability of exploitation. Add in context, like whether the package is actually in use and has a fix available, and you can pinpoint the few vulnerabilities that demand immediate attention.

Here is a practical matrix you can adapt for your own security policies to decide when it's okay to use a package versus when you need to take immediate action.


Use the matrix to prioritize fixes by combining severity, exploitability, and context in CVE details.

Don’t rely on labels alone. 
For example, a “High” CVE with low CVSS and EPSS may not need urgent action.

Always assess whether the vulnerability is actually exploitable in your environment. Do this before deciding to block or patch a vulnerable software package.

Both were assessed “High” by CVSS due to potential impact/scope if triggered, but EPSS (being telemetry/data-driven) remained very low because there was little to no evidence of widespread attacker uptake.

 in the Linux kernel had a CVSS of 7.0 (High) but an EPSS of just 0.04%. Why? Its exploitation requires local access and specialised conditions, making it an unattractive target for widespread attacks.

High EPSS before NVD had published details

 (a critical PHP vulnerability) had an EPSS score of ~94% days before the NVD published its full analysis and CVSS score. Teams relying only on NVD/CVSS feeds would have been blind to a major, actively exploited threat.

Why Traditional Vulnerability Management Fails in DevSecOps Pipelines

Blend EPSS (likelihood), KEV (known exploitation), and exposure context (is it reachable/authenticated?). For example, treat CVE-2024-4577 and 

 as urgent even if your NVD-only feeds lag.

When the NVD record date is later than public disclosure/research, lean on EPSS + vendor advisories + KEV until NVD catches up.

While it’s one thing to enumerate vulnerabilities within a platform, it’s another thing to enable our customers to manage the vulnerabilities in an effective way to reduce organisational risk as quickly as possible, while not impeding on development processes.

Creates a generic ticket: “CVE-2024-XXXX found in package Y”

Developer stops current work to research CVE while vulnerable package remains deployed in staging or production

Developer figures out which version fixes the vulnerability

Beyond EPSS: Combining Scoring Systems for Smarter Vulnerability Management

While EPSS is valuable in implementing a risk-based vulnerability management approach, it has limitations that have to be considered when integrating EPSS within a broader security strategy. For one, EPSS scores are only applicable to vulnerabilities with CVE identifiers, so unknown or unreported vulnerabilities (including zero-day vulnerabilities) that haven’t been cataloged with a CVE identifier are not covered.

EPSS should be part of a larger strategy, as organisations benefit more when they use EPSS along with CVSS and other vulnerability prioritization methods. The CISA KEV (Known Exploits) catalog, for example, informs security professionals if the vulnerability has already been successfully exploited in the wild. Combining EPSS, CVSS, and CISA KEV allows organisations to implement risk-based more effective vulnerability management.

Modern vulnerability management isn’t just about finding what's broken; it's about knowing if it actually matters. By combining CVSS, EPSS, and CISA KEV, you can build an automated triage system that only flags what's truly urgent.

This smarter lifecycle asks four simple questions:

Is it being actively exploited or likely to be (EPSS, CISA KEV)?

Is the affected asset internet-facing or part of a critical system?

If the answer to all is "yes," you act. If not, you can de-prioritize it and let your developers focus on what they do best: building great software.

Toward a smarter vulnerability lifecycle with Policy-as-Code

This triage model reflects the realities of limited time, team resources, and the explosion of third-party software risk. Users are advised to focus primarily on CVEs associated with in-use packages that have a known fix available. If there’s no fix available, we cannot take proactive steps to patch the known vulnerable packages.

Nigel Douglas

Head of Developer Relations

Using vulnerability scoring systems to prioritize risks in your environment

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)

Cloudsmith Blog

Using vulnerability scoring systems to prioritize risks in your environment

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