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

When talking about DevOps and software delivery pipelines, security, compliance, and governance should all be native to the development workflow. Yet traditional approaches to software supply chain security often feel bolted-on. Proprietary black boxes are hard to integrate - and harder still to understand or extend. Instead of adapting to your workflows, you’re expected to adapt to theirs, with little room for customisation or clarity about what they’re actually doing under the hood.

 differs from other legacy approaches. This is a powerful, flexible, and developer-friendly way to implement policy as code using the Open Policy Agent (

) and its associated Rego, natively within your artifact management pipeline.

Legacy artifact management systems typically offer pre-baked security gates that require manual reviews, or offer minimal configurability. While these should solve some business outcomes, they often don’t scope well to your specific business logic. Cloudsmith gives teams full access to define policies using Rego, a standard open-source policy language used in many enterprise solutions.

This familiar policy language is ideal for teams who are automating supply chain security controls. Cloudsmith’s policy management enables fine-grained, conditional control over package handling during security scanning. Additionally, Cloudsmith’s policy implementation integrates with automation tools via Cloudsmith's robust REST API. With policy as code, you can go beyond one-size-fits-all policies and encode the exact rules that matter to your organization, whether it's license restrictions, CVSS thresholds, naming conventions, or internal workflows.

Cloudsmith policies are evaluated during package synchronization, after a security scan completes. This gives teams a reliable hook to enforce quality, security, and compliance gates before artifacts move deeper into production pipelines. Here’s what makes it practical:

: 
All policies are written in Rego and must follow a specific schema. As long as Cloudsmith supports the specific built-in functions required in the policy, it should be valid. Rego is incredibly flexible. 

As seen in the example below, you can use RegEx within OPA Rego to match specific package filenames that contain a semantic versioning for the file name, or use RegEx to scope the unique business context that matters to you.

This Rego policy is designed to enforce a naming convention for packages in a Cloudsmith repository. Specifically, it ensures that package filenames starting with 

The policy implements filename prefix check to target only packages where the filename starts with 

. The regex match for SemVer, scans those h11- files, and it enforces a filename pattern where 

Finally, policy introduces mismatch handling, where the filename does not conform to this SemVer pattern with an approved extension, the policy matches and produces a human-readable message explaining why.

Policies are considered terminal by default. When a match occurs, execution stops and the associated actions trigger. This is the policy evaluation flow. Policies are evaluated in order of their precedence (lowest number = higher priority). When a policy’s Rego rule evaluates to 

, it’s considered a match. By default, Cloudsmith stops evaluating any further policies after this match. The actions associated with that matching policy (like tagging, quarantining, or changing state) are immediately triggered.


For a Cloudsmith policy to be enforced, it needs an associated 

 that defines the name and description of the policy, but also whether it’s enabled by default or is terminal, and more importantly defines the precedence at which it’s read:

Upon creation, the API returns a success response indicating the policy has passed validation and is active. The policy is also reflected in the Cloudsmith UI almost instantaneously, ensuring immediate visibility and enforceability within your package governance workflows.


Terminal behaviours matter, and this design is intentional. It allows users to short-circuit processing for high-priority rules, as well as avoiding conflicting actions across multiple policies and keep policy logic simple and predictable.

To apply the policy, you can create a HTTP POST request to the policies API with the 

 reflecting the data that is being sent to that API:

While terminal behaviour is the default, non-terminal policies can be configured explicitly by setting:

This lets evaluation continue to the next policy, even after a match. You can use this when you want multiple policies to apply, if you're using multiple independent tagging or analysis rules, or if you need layered enforcement, like tagging, then quarantining.

 (to Quarantine package and render them unusable) or 

 (with context for further reviews) via the API. Each policy can have multiple actions with a defined precedence. Once you have a Policy Slug generated from the created Cloudsmith policy, you can assign a tagging action for your policy ID:

A straightforward way to test this policy is to take a package that already has a valid SemVer-compliant filename and rename it by replacing the version number with a placeholder like “test.” For example:

Cloudsmith's REST API enables full Create, Read, Update, Delete (CRUD) operations on policies and their components. This is where automation shines:

Create or update policies dynamically from CI/CD scripts.

Simulate policy evaluations with real or staged package metadata.

Apply tagging or quarantining logic that integrates with your observability or DFIR tools.

 is currently the best fit for automating Cloudsmith policy as code workflows due to its flexibility in shell scripting (such as 

). Github Actions also provides an easy integration with rego files stored in your repo, secure handling of secrets such as the API Key, as well as built-in CI/CD lifecycle for validation, simulation, and deployment.

 before applying policies in production. This dry-run capability helps ensure your Rego logic behaves as expected, reducing the risk of false positives, which could result in things like blocking good artifacts.

The response contains a list of packages that were tested, with fields like 

 that would be taken if the policy is enabled. You can add a package search query to filter the packages being evaluated. This reduces all the packages to apply the policy to.

You can disable the policy either on policy creation, or at a later time via the API, as seen here:

 will tell users whether the policy matched the scope of their package:

Once the package is pushed to Cloudsmith, you can check your 

 package name to see if the package data is the data you expected to see in the policy evaluation:


If the policy is no longer required, you can use the 

By combining policy management with Cloudsmith's flexible REST API, you unlock a powerful new paradigm:

Governance that’s automated and programmable.

Policies defined by your logic, your rules.

With Cloudsmith, developers and platform engineers can treat security and compliance as first-class, automated citizens in their CI/CD systems. Whether you’re integrating with Terraform, GitHub Actions, or your own orchestration tooling, Cloudsmith’s policy management gives you the control you need to secure your software supply chain your way.

Nigel Douglas

Head of Developer Relations

Unlocking policy as code automation with Cloudsmith policy management

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

Cloudsmith's policy management capabilities are built on Open Policy Agent (OPA), using Rego to define policy as code. These policies control how packages move through your systems. They're versioned, reviewable, and enforceable.

Policy management is in early release, but it already draws on extensive metadata Cloudsmith collects from your artifacts: format, version, tags, license, vulnerability, malware scan results, and digital signatures. Policies tap into this data to take action based on what matters to your team.

This article follows the example provided by Ciara Carey, a Solutions Engineer at Cloudsmith, shown in the video below.

Policy management demo

From the Cloudsmith interface, navigate to the 

 policy to view the policy-as-code rules, written in Rego, for an example policy. These code-defined policies give you fine-grained control over artifact behavior.

This policy evaluates multiple risk indicators across all known vulnerabilities for a package to determine whether it should be flagged and quarantined. These indicators include CVSS and EPSS scores, the presence of a patch, and the age of the vulnerability.

At the top of the code, we set up our policy as code, written in Rego, with the necessary dependencies:

 variable to store whether the vulnerability matches our criteria:

We’re testing against parameters including EPSS and CVSS scores, repo name, age, and CVE exclusion, and these are declared as variables:

 from the lower setting in the video, to reflect a more realistic threshold.

 block, which evaluates the conditions for each vulnerability and sets match to true if all pass:

This example uses a nuanced policy that checks for several risk factors before it triggers an action. Let’s examine these checks and the code they use.

Target Repository and Iterate Vulnerabilities

Make sure we are targeting our preferred repo:

Then loop through each reported vulnerability. The policy then applies the conditions to every vulnerability in the dataset. A vulnerability is bound to the 

Apply and Evaluate Conditions for Each Vulnerability

The following checks are then applied to each vulnerability for the package:

 – Skips known and accepted vulnerabilities to reduce unnecessary noise:

This uses a simple Rego helper rule to check if the vulnerability is in the ignore CVE list:

– This check ensures that a patched version of the package exists. If not, the policy will not trigger:

 – Evaluates the severity of any vulnerability using a configured CVSS threshold:

This uses a helper rule to check if the EPSS score exceeds our limit:

 – Evaluates the likelihood of vulnerability exploitation using the configured EPSS threshold:

– This checks the vulnerability's age by comparing its published date to a threshold of 30 days ago. This gives the vulnerability a grace period to establish itself. If the vulnerability was published before that date, it meets the age condition for further evaluation:

 panel, you can add a series of actions taken in response to a policy trigger. In this example, Cloudsmith performs the following automated actions:

 – Adds a visible marker so teams can immediately identify problematic artifacts.

 – Blocks the artifact from being downloaded, deployed to infrastructure, or promoted to other repositories.

Once the actions have been added, toggle the switch to the right of the policy name to ensure the policy is active.

To test the policy, upload a package that matches the policy conditions. For example, one with a known vulnerability that exceeds the configured CVSS and EPSS thresholds.

 to push a package that triggers the policy.

Cloudsmith automatically scans the package, extracts metadata, and applies the policy. In the example, if the conditions match, Cloudsmith:

Quarantines it to block deployment, download, and promotion

The API offers a range of instructions to manage policies as part of policy management. For example, use the simulate API to test policies without enforcing them. This returns results as if the policy were active, helping teams validate changes safely.

Open the decision log to examine how the policy responded. Locate the policy ID and view the result. The interface shows the evaluated Rego policy and the triggered event's full context.

You'll find detailed metadata from the package, including:

This information forms the basis for policy evaluation. Scroll to the bottom to see what actions the policy took. The decision log provides a transparent record of what happened and why.

Ian Taylor

Tech Content Director

Policy Management Example: Quarantine Packages Using Policy as Code

 now supports the Exploit Prediction Scoring System (

), a data-driven metric designed to estimate the probability of a software vulnerability being exploited in the wild. Using policy management in Cloudsmith, you can now use a package's EPSS score to inform your package workflows, including those around 

EPSS scores or estimates the likelihood (probability) that a software vulnerability will be exploited in the wild. Cloudsmith users can use EPSS scores to prioritize vulnerabilities most likely to be exploited, to strengthen your organization’s security posture and automate your response to vulnerabilities.

Cloudsmith users can continue to write policy as code using 

) and leverage EPSS-based logic in their OPA policies for more granular, data-informed decisions around vulnerability management. This automated responses approach allows Cloudsmith users to remain protected in real time as Cloudsmith automatically re-checks and re-applies your policies when EPSS scores change.

 will quarantine and tag a software package with “

” vendor severity rating and if the EPSS score exceeds the defined threshold in your 

For the purpose of a real-world demonstration, we will use the vulnerable Spotipy package as highlighted in 

 example is a Python library specifically used with the Spotify Web API. Affected versions of this package are vulnerable to 

 through the CacheHandler class. In this scenario an attacker could gain unauthorized access to admin-level actions on the Spotify account by reading Spotify authentication tokens exposed in the file created by the CacheHandler class with the 

What’s interesting about this example is that it was picked up by EPSS but hasn’t yet received a “vendor severity” scoring from 

, emphasizing the need for EPSS as well as traditional vendor scoring sources within our EPM policies. Vulnerability naming schemes, like the Common Vulnerabilities and Exposures (

) system, provide standardised identifiers for publicly known IT system vulnerabilities. This CVE classification differs from EPSS in the sense that EPSS uses real-world threat data to predict the likelihood of those vulnerabilities being exploited

In the above example, you can see that spotify was detected with a vulnerability from the recently applied policy. The tag was added with “exceeded-epss” providing that it was the EPSS predictability score that caused the quarantine status. Package quarantining allows users to temporarily block any downloads of a package until you release the package from that quarantine state.

If you'd like to see a demo of Cloudsmith's policy management capabilities with EPSS confidence scoring, why not call over to 

, South Hall – ExCeL London. We’ll be providing live demos until Friday.

Cloudsmith introduces EPSS Scoring in Policy Management

In a rapidly evolving digital environment, organizations across various sectors—including technology firms, financial services, and manufacturing—rely on effective management of software artifacts to secure their software supply chains

The risk of supply chain attacks has intensified, revealing vulnerabilities at every stage of artifact management. Compliance breaches, data leaks, and unvetted code present serious threats, and Cloudsmith aimed to tackle these challenges head-on.

Cloudsmith, renowned for its cloud-native artifact management platform, has introduced powerful policy management capabilities built for modern security needs. Combining policy as code with Cloudsmith’s search capabilities, teams can define, enforce, and monitor policies across the entire artifact lifecycle.

The software supply chain faces several pressing security and compliance issues:

: Vulnerabilities in third-party components open doors for attackers, making controlled artifact ingestion vital.

: Increasing regulations demand strict adherence to compliance standards.

: Without enforceable policies, unmanaged access and configurations can increase the risk of incidents.

: Many tools lack flexibility, offering predefined policies that may not address unique security needs.

Cloudsmith’s approach to policy management

Cloudsmith’s policy management capabilities serve as a control plane across the entire artifact management lifecycle. Using policy as code, the platform enables organizations to implement custom, consistent, and traceable policies, strengthening their security posture.

“Software supply chain attacks are a growing concern,” said Glenn Weinstein, CEO of Cloudsmith. “Our policy management capabilities give teams complete control over software artifact ingestion, access, and delivery, protecting organizations from vulnerabilities, bad actors, and misconfigurations.”

Cloudsmith’s policy management capabilities directly address these challenges with features that enhance security and simplify how teams manage policy:

: Build policies based on any available data or attribute, ensuring they align with specific security and compliance standards.

: Speed up implementation with templates for common use cases, reducing time to achieve a secure software supply chain.

: Safeguard against untrustworthy packages by enriching package data. Cloudsmith integrates multiple data sources for thorough quality and risk analysis.

: Use Cloudsmith’s API to automate policy creation and store policies as code, enabling consistent, observable, and repeatable security practices.

With policy management, Cloudsmith empowers organizations to:

: Hosting policies on the artifact management platform offers enterprise-wide policy enforcement, reducing misconfiguration risks.

: Policy as code provides a consistent, scalable security posture.

: With clear, automated policies, organizations can confidently maintain compliance and reduce audit burdens.

In a world where supply chain security is paramount, Cloudsmith’s policy management capabilities provide the flexibility, insights, and automation needed to build a resilient and secure software ecosystem.

Stay ahead of evolving security threats and safeguard your software supply chain with Cloudsmith’s policy management capabilities. Experience how policy as code, combined with powerful integrations, helps you enforce security policies, enhance compliance, and protect your organization from vulnerabilities. Schedule a personalized demo to explore how Cloudsmith can streamline policy management and ensure a more resilient, secure software ecosystem for your team.

 and see how Cloudsmith can help you take control of your software artifacts and mitigate risks across your supply chain.

Cloudsmith Blog

Unlocking policy as code automation with Cloudsmith policy management

Using Trivy Inside Cloudsmith

Policy Management Example: Quarantine Packages Using Policy as Code

Cloudsmith introduces EPSS Scoring in Policy Management

Introducing Policy Management: Strengthening Security and Compliance with Policy as Code