By submitting this form, you agree to our 

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.

Cloudsmith Blog

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