By submitting this form, you agree to our 

Cloudsmith’s Enterprise Policy Management (EPM) now supports the Open Source Vulnerability (

) database as an additional data source, so users can define 

 policies. OSV.dev is a distributed vulnerability database specifically for open source software (OSS) packages, including dependencies. The open, precise, and distributed vulnerability information for OSS projects from OSV complements EPM’s existing vulnerability data from Common Vulnerability Scoring System (

) and Exploit Prediction Scoring System (

The OSV database was originally developed by Google, and is fully open source. It consolidates data from multiple vulnerability repositories that follow the OSV schema, such as 

 database, Python Packaging Advisory Database (

OSV offers a straightforward API that allows clients to look up vulnerabilities based on either a specific commit hash or a package version. All records adhere to the 

 specification, which was created through collaboration with open-source communities. This schema provides a standard approach, for both human- and machine-readable format for detailing vulnerabilities, ensuring they can be accurately linked to exact package versions and commits.

Creating a Malicious Package policy in Cloudsmith

Let’s look at an example of Cloudsmith EPM policy. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.

 a blog post in July 2025 about a set of npm linter packages, including 

, that were hijacked via phishing to drop malware. Looking up eslint-plugin-react_editor within the OSV database we can see there’s already a matching entry with the ID 

Each malware ID comes with an associated 

 that provides all the surrounding context for policy decisions. We are using a free string search for “MAL-” to capture malware IDs.

In this scenario, we downloaded the tarball in a sandbox environment:

 tarball to Cloudsmith without installing it locally, which is safer when testing the malicious package.

 We are detecting based on malware, not on vulnerabilities. In this case there is no CVSS vulnerability data associated with the package, however, the package is still quarantined and tagged for Malware due to the malware findings from the Malicious Packages project.

 explain how the package was quarantined with the relevant malware information. Here’s a command you could use to return information specific to OSV findings:

 filter, you get the entire output of the Cloudsmith EPM decision logs. Within these logs, you’ll see:

: Times the policy evaluation started and ended.

: The exact data used to evaluate the policy.

: Which actions were actually invoked on the package.

Protect Yourself Against Malicious Packages!

By integrating OSV as a data source, Cloudsmith EPM gains access to vulnerability intelligence that directly maps to specific OSS package versions and commits. These 

 policies complement the existing CVSS and EPSS coverage by filling critical gaps, particularly in cases where a package may not register a conventional CVSS vulnerability score but is still compromised, such as with malware-flagged releases.

With OSV’s standardised schema and rich ecosystem of upstream sources, EPM will detect and act on threats that might otherwise slip through traditional scoring-based detection, extending its ability to quarantine, block, or tag malicious packages before they impact production environments.

Nigel Douglas

Head of Developer Relations

Managing Malicious Packages with Cloudsmith EPM

At Cloudsmith, we believe that visibility, control, and automation are essential to securing your software supply chain. That’s why we built Enterprise Policy Management (EPM) as a programmable enforcement layer to let developers and security teams define and apply rules that govern the behaviour of packages within your repositories.

This post lifts the curtain on the input data, technology stack, and policy lifecycle that drive Cloudsmith’s real-time, zero-trust decision engine - now extended to delay and block even the first download of non-compliant packages from upstream sources.


Rego is the policy language to manage Cloudsmith pipelines

At the core of EPM is Open Policy Agent (OPA) and its declarative language, Rego. OPA serves as the embedded decision engine, evaluating each package against the policies you define. Our CEO, Glenn Weinstein, already explained in a recent 

 why it makes sense to use open standard approaches that our end-users are already familiar with when managing artifact pipelines.

Cloudsmith wires OPA into the security scan phase of our 

. This phase processes every new package (whether uploaded directly or fetched from an upstream proxy) and applies the policies you’ve authored to determine the correct action to take (such as tagging, quarantining and blocking).

Input Schema provides the fuel for Policy Decisions

Policy logic in EPM is evaluated using a structured input document, passed to OPA. This document contains a complete snapshot of package context:

To avoid surprises, we strongly recommend, users write policies against known, documented fields. Some examples can be seen on our 

 to validate your logic against real package inputs. Finally, review the EPM 

 to confirm your policy is matching as expected.

OPA won’t throw errors for undeclared fields, but it also won’t enforce your intent unless the data is actually there.

Visualising the policy lifecycle from request to enforcement

EPM policies are evaluated during specific phases of the package lifecycle: when a package is uploaded and when new vulnerability advisories are discovered.



The lifecycle of an EPM policy begins when a 

 - typically during the first security scan of a package as it synchronises into a repository. At this point, Cloudsmith compiles the package’s metadata, including structure, uploader, repository, all into a versioned input document for policy evaluation. Link to the 

, the input is matched against the rego-based policy using the OPA engine. Each policy defines a set of conditions including checks for security vulnerabilities, licensing violations, naming conventions, or custom business rules. Furthermore, 

 are generated during the evaluation phase.

 begins. If the policy evaluation results in a match, a predefined sequence of actions is executed in precedence order. These actions (such as 

) allow you to enforce outcomes like tagging and quarantining packages. Actions are defined separately and attached to policies, and each can be configured to run in sequence, with the option to stop further execution if the action is marked as terminal.

Importantly, each policy is evaluated independently. This means multiple policies can match and execute their actions in combination, unless one of them is marked as 

, which halts further policy evaluation after it matches. Within a single policy, actions are executed in a deterministic order based on their 

 values, enabling precise control over outcomes like tagging or quarantining. This modular, layered approach allows you to compose nuanced lifecycle controls that align with your compliance and operational requirements.

Continuous security through CVE and EPSS feeds

Cloudsmith ingests vulnerability data from Common Vulnerabilities and Exposures (CVE) feeds. Each vulnerability includes standard metadata, such as CVSS v3 scores (via 

), the published dates, descriptions, and the associated identifiers. These allow granular rule logic based on severity, age, fix availability and more.

 (Exploit Prediction Scoring System) scores, which estimate the risk of a particular vulnerability to be exploited in the wild. These scores are embedded in each vulnerability record under 

, enabling policies that trigger on the high likelihood of exploitation, as opposed to having a high CVSS score but is unlikely to be exploited as a real threat to an organisation.

Through Continuous Security, Cloudsmith refreshes both CVE and EPSS data regularly. The CVE database via 

 is refreshed approximately every 6 hours. Likewise, the EPSS data is updated every 24 hours. These automated feeds ensure that EPM policies act on fresh vulnerability insights - even after a package is ingested. Unlike classic vulnerability management, where scans soon get outdated, we keep artifact scan results up-to-date with the most relevant vulnerability feeds, allowing users to automate their responses if anything changes.

Knowing how Cloudsmith’s EPM combines static package metadata with dynamic vulnerability intelligence (such as CVE+CVSS+EPSS) refreshed continuously, it provides users with a robust foundation to craft nuanced, data-driven policies. You can, for example, block only recently published EPSS‑high CVEs with fixes, or create aging ramp policies using published date logic.

Policy enforcement at the point of ingress

With Cloudsmith's EPM, development teams can now enforce security and compliance policies before a package is ever downloaded, even on the very first request. Historically, packages fetched from upstream registries were cached and served immediately, with scanning and enforcement applied only after the first pull from upstream. This approach prioritised speed and developer velocity, but came with a trade-off: the earliest moment of ingress remained unchecked, allowing potentially vulnerable or non-compliant code into the development environment before any policy was applied.

" flow. While this isn't a unique flow to EPM, users can certainly use this flow within EPM. If a requested package isn’t already in your repository, Cloudsmith will pause the download until the package has been fetched, scanned, and evaluated against your defined policies. If it fails policy enforcement, either due to issues like high CVSS vulnerabilities, disallowed licenses, or missing metadata, the package will be blocked from being served entirely.


This approach changes Cloudsmith’s traditional model from reactive to proactive. It delivers true zero-trust enforcement from the outset, ensuring that no developer or CI pipeline can accidentally ingest unvetted software. Every package, whether direct or transitive, becomes subject to the same rigorous controls, ultimately helping organizations align with security frameworks like 

 and pass compliance audits with confidence.

All Cloudsmith EPM policies follow a consistent structure using Rego:

This logic fails the policy if the package’s license is not approved. In doing so it returns a clear, human-readable 

 message, which is helpful for debugging and explaining decisions. The standard structure sets 

, ensuring that matches are both explicit and traceable. Finally, it sets 

 only when there are one or more policy violations. In this way, OPA decisions are deterministic, explainable, and fast, making them ideal for secure automation.

Rego provides powerful primitives for matching package names, filenames, tags, and other strings. Some real-world examples:

Enforce filename prefix:


not startswith(pkg.filename, "internal-")

This flexibility allows you to enforce naming conventions, prevent shadow IT, or ensure metadata hygiene. If you are ever unsure about the supported fields that can be used in EPM Rego policies, check out the 

 for Cloudsmith. Alternatively, Cloudsmith’s Ralph McTeggart created a useful 

 to better understand how to construct and validate policies on the fly.

Advanced example of blocking high-risk vulnerabilities with fixes

You can also craft more sophisticated rules that incorporate CVSS severity, EPSS risk, and whether a fix is available. This lets you enforce “

” - only quarantining packages that are both severe and exploitable, and that could be remediated.

The above policy only matches vulnerabilities that already have a fix available. We explained in a previous 

 why this approach is important when tackling CVE tsunamis. This policy requires CVSS v3 score ≥ 8.0 (which is categorised as a HIGH severity). However, it also requires the EPSS score ≥ 0.5 (moderate to high likelihood of exploitation). As always, it should prevent high-risk downloads but also flags the issue with a descriptive message so DevOps teams can take action quickly.

By combining multiple data signals (severity, exploitability, fixability), you avoid noisy false positives and focus your policy enforcement on the vulnerabilities that truly matter. This balance helps developers ship securely, without drowning in alerts or blocking known harmless dependencies.

Cloudsmith’s EPM framework is driven by structured package metadata and enriched by real-time security scan outputs. This data forms the basis of each decision evaluation, allowing Rego-based policies to act deterministically based on concrete inputs such as CVSS scores, file counts, license data, and uploader identity. The integration of OPA ensures that every policy execution is reproducible, traceable, and fully customisable to suit the operational and security requirements of each workspace.

By embedding this decision logic at the point of package synchronisation, EPM supports early intervention and automated remediation, such as quarantining, tagging, or rejecting packages before they propagate through your CI/CD pipeline. The result is a policy engine that aligns tightly with your organisation’s compliance posture, operational norms, and internal trust boundaries, all without compromising the speed and automation you’ve come to expect from Cloudsmith.

Pull back the hood on the data and tech that informs EPM

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.

That’s where Cloudsmith’s Enterprise Policy Management (

) 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 EPM 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 EPM, 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 EPM 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 EPM 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 EPM policies 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 EPM 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 EPM gives you the control you need to secure your software supply chain your way.

Unlocking policy-as-code automation with Cloudsmith EPM

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

Enterprise Policy Management (EPM) is a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain. Teams can codify rules once and apply them continuously across repositories. With Cloudsmith’s platform, organizations extend policy enforcement across teams, environments, and geographies without introducing friction, including the open source packages that the chain depends on.

Our EPM solution is powered by data at every stage. The policy engine has access to all available package metadata to inform decisions. Every policy action is recorded with full context, providing detailed logs for customers to support audits and investigations. EPM includes compliance dashboards, that surface insights in security, compliance, and policy activity. This gives you continuous oversight and helps you refine your approach.

This article provides an overview of EPM and how it strengthens the software supply chain. For a worked example using policy as code, see 

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

We built EPM because governance should not slow you down; it should accelerate trust. Threats to your software supply chain are evolving faster than human oversight can track, and automation is the only viable path to resilience. EPM puts policy enforcement early in the development process. It makes decisions transparent and implements your security and compliance posture into something repeatable, testable, and version-controlled, like the rest of your codebase. Developers get immediate insight to help select packages. They know which meet policy standards for security, licensing, and quality.

Policies are codified rules that automate decisions and enforce rules on which packages are allowed in your software supply chain. They provide guardrails that ensure security, compliance, and operational consistency. Policies can block vulnerable packages, restrict problematic licenses, and control access.

For example, an enterprise may add a policy that stops packages with high-risk vulnerabilities from reaching production environments. The policy would be prescribed by logic as follows:

Define logic that evaluates vulnerability criteria and applies a quarantine action to affected packages.

The criteria specifies that the vulnerability must be listed in the Common Vulnerabilities and Exposures (CVE) database.

The policy then checks if the vulnerability exceeds a defined 

If conditions are met, the package can either be quarantined and blocked from promotion to production or tagged with additional context for further forensics.

This previous example is a vulnerability policy and is one of the types Cloudsmith EPM supports:

 prevent non-compliant code from being used.

 automate tagging, quarantining, or deleting based on metadata.

Without strong policy management, teams face increased risk and unnecessary effort:

- Missing automation allows known CVEs or malicious packages to reach production.

 - Teams must scramble for audits instead of demonstrating continuous compliance.

- Engineers spend hours reviewing dependencies or waiting for late-stage approvals.

Without shared policies, standards vary across teams and environments.

Without codified policies, organizations cannot fully benefit from the scale and speed of the cloud.

Catching vulnerabilities early in the software delivery lifecycle reduces both the financial cost of remediation and the risk of reputational damage.

EPM was built to avoid these issues in response to real-world supply chain threats and close collaboration with our customers. Codification and automation provide a unified approach for teams to enforce decisions that were previously enforced manually and inconsistently, proving less robust or scalable.

In an automated delivery environment, policies are essential for reducing manual overhead, preventing costly mistakes, and proving compliance, and have particular relevance within the organization:

-For CISOs, policies are the cornerstone of a secure software supply chain. They enable proactive threat mitigation, enforce compliance with frameworks like SLSA and SC2CF, and provide the audit trails required for regulatory confidence. Cloudsmith’s EPM lets CISOs shift from just enforcing checklists to actively collaborating with engineering teams by using the same tools. Implementing automated policies makes it easier for the engineering team to build securely.

- CTOs are focused on enabling product velocity without compromising architectural integrity. Effective policy management acts as a safeguard for CTOs, giving them confidence to move fast with greater safety, supporting both innovation and security goals. With EPM, they can align engineering output with business goals, ensure consistent implementation of best practices, and reduce the operational burden of manual reviews.

Teams immediately benefit by switching from public repositories to Cloudsmith as a curated repository for their developers. Policies then provide clarity, speed, and safety for engineering teams. Instead of guessing what is allowed, developers get immediate feedback when a package or dependency violates a rule. Our EPM integrates policy checks directly into the artifact pipeline, shifting decision-making left and reducing the noise and frustration caused by late-stage security reviews. 

EPM: Cloudsmith’s Approach to Policy Management

Cloudsmith Blog

Managing Malicious Packages with Cloudsmith EPM

Pull back the hood on the data and tech that informs EPM

Unlocking policy-as-code automation with Cloudsmith EPM

Using Trivy Inside Cloudsmith

Enterprise Policy Management with Cloudsmith