---
title: "Policy Management & Policy as Code for Software Supply Chains"
description: "Cloudsmith policy management gives you centralized, automated control over every package, dependency, and container flowing through your supply chain. Define rules in OPA Rego, enforce compliance at ingestion, and protect AI-generated and human-written code alike."
canonical_url: "https://cloudsmith.com/product/enterprise-policy-manager-archived"
last_updated: "2026-08-18T17:37:27Z"
---
# Policy Management & Policy as Code for Software Supply Chains

Policy management

## Policy Management for Your Entire Software Supply Chain

With policy management, Cloudsmith gives you centralized control over every package, dependency, and container - across every format and team - before software reaches developers, pipelines, or production. Built for the speed and scale of modern and AI-assisted engineering.

[Book a demo](/book-a-demo)

## One place to enforce policy

Set your rules at the registry: a CVE threshold, a license restriction, a cooldown period, a deny list. They cascade to every pipeline and developer that pulls from it. One control point instead of policy scattered across pipelines, making the secure path the default path. 

How cloudsmith helps

## Most organizations depend on open source they don't control. Policy management ensures the **safety, quality, and license compliance** of every package at the point of entry - including dependencies demanded by AI agents.

Instead of waiting until late in the SDLC, Cloudsmith policies act immediately on ingestion, blocking or quarantining risky artifacts and preventing non-compliant licenses from slipping through - whether those dependencies were specified by a developer or an AI agent.

### Enterprise-ready Controls

Policy as code - Define and manage rules using Open Policy Agent (OPA). Tailor enforcement to enterprise requirements and update policies as new threats or regulations emerge.




Cooldown policies - 
Supply chain attacks like Shai-Hulud use malicious, newly-published packages. With cooldown policies you can apply rules governing the use of newly-published packages in your Workspace.




Data enrichment - Every decision can be based on vulnerabilities, malware intelligence, licenses, EPSS scores, and metadata. Cloudsmith makes all this intelligence available to the policy engine.




Defined scope - Apply rules globally across your organization, or scope them to specific teams, repositories, or workflows. Detailed logs and reporting support audits and compliance frameworks.

### Continuous enrichment of risk data

Ingress control - Policies apply at the point of entry. Malicious, vulnerable, or non-compliant packages are blocked, quarantined, or tagged before they reach developers, pipelines, or production.




Continuous policy evaluation - Packages already in repositories are continuously re-evaluated against up-to-date threat feeds and license intelligence, ensuring your software supply chain remains secure over time.




Multi-format consistency - Whether npm, PyPI, Docker, NuGet, Maven, or beyond, every artifact traverses the same controlled gateway, subject to the same rules and data sources.

### Considered user experience

Developer-friendly by design - Policies are enforced automatically, so developers don’t need to stop and check. Real-time enforcement minimizes friction and maintains velocity.




Comprehensive documentation - Build on our library of OPA policies, written in Rego, tailoring them to your unique needs.

Policy management

## Secure your teams, pipelines, and AI workflows. Use policy as code to **interpret threat signals and automate enforcement actions**.

- Use industry standard OPA Rego to define software usage policies
- Apply  policies to packages and container flowing through Cloudsmith
- Perform actions based on your policies
- Make refinements based on policy logs

## Frequently Asked Questions

### How does policy management help us manage open source risk?

The majority of organizations rely on open source that they cannot control. Policy management implements safety, quality, and license compliance at the point of entry before any risky package even reaches the developers, pipelines, or production.

### Will policy management slow down developer workflows?

Policy management is built to enforce security without blocking productivity. When risks are detected, flexible actions—such as notifying, tagging, or quarantining—apply the right level of control for the environment. Because policy management makes deep artifact data available to policies, much of this can be automated, giving developers clear, immediate feedback. Applying policies <em>does take</em> a small amount of additional time, but the result is less time spent on security fire drills later, and faster access to high-quality, compliant software from the start.

### Can policies adapt to our specific compliance needs?

Yes. Policy management uses policy as code (via OPA) to tailor enforcement to enterprise requirements. Because all artifact intelligence is available to policies, rules can be updated quickly as threats, regulations, or internal standards evolve.

### What visibility do we get into policy decisions?

Every action is logged and exportable, giving security teams full visibility into what was allowed, blocked, or quarantined. These records provide clear insights for governance and make it easy to demonstrate that controls are in place during audits or internal reviews.

### Is policy management limited to open source packages?

No. Although open source risk is a large contributor, the elastic framework of policy management allows you to impose rules on any artifacts across formats (from containers to language packages). Policies can be used to manage licenses, vulnerabilities, or even custom metadata, and they can be applied across the entire software supply chain.

### How does policy management stay effective against new and emerging threats?

Cloudsmith constantly infuses artifacts with new intelligence - such as vulnerabilities and EPSS scores, malware signals, and license updates. Since policies always consider the most recent data, packages in your repositories are re-checked automatically, keeping your protections updated as threats change.

### Who benefits most from policy management: DevOps teams or security teams?

Both. DevOps leaders receive low-friction automated enforcement that continues to keep developers working at high velocity, and AppSec and security teams achieve the governance and visibility that they require throughout the supply chain. Policy management fills the gap by connecting speed and security at enterprise scale.

### Is it possible to implement policies globally or only to specific teams?

You control the scope. Policy management allows you to implement policies at the org level, team level, repository level, or even workflow level. That flexibility makes it easy to impose global rules without compromising on team-specific requirements or experimental environments.

### What are cooldown policies and how do they protect against supply chain attacks?

Cooldown policies let you restrict the use of newly-published packages for a defined period after they appear in an upstream registry. Many supply chain attacks rely on injecting malicious packages that get pulled in immediately after publication - before the community or threat intelligence feeds have had time to flag them. By applying a cooldown window, you ensure that only packages with an established publication history can enter your supply chain, reducing your exposure to zero-day package attacks.

### Can cooldown policies be applied selectively, without blocking legitimate fast-moving dependencies?

Yes. Cooldown policies are configurable by scope, so you can apply stricter windows to high-risk ecosystems or repositories while leaving others unaffected. 

[Read our cooldown policy documentation](https://docs.cloudsmith.com/supply-chain-security/epm/cooldown-policy)

## Additional Resources

Curious about how policy management was built? Wondering what great policy enforcement looks like? Take a look at the resources below to learn more.

### [Rego Policy Cookbook](/campaigns/cloudsmith-rego-policy-cookbook)

Strengthen your governance and security posture with ready-to-use Rego policies. This free cookbook provides a curated collection of policy templates to help you enforce best practices, maintain compliance, and lock down security in your software supply chain — without starting from scratch.



### [Unlocking policy as code automation with Cloudsmith policy management](/blog/policy-as-code-automation-with-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 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 (OPA) and its associated Rego, natively within your artifact management pipeline.



From proprietary to programmable

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.



Policy as code is practical and powerful

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:



Rego-based rules: 
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 h11- follow semantic versioning (SemVer) and end in either .tar.gz or .whl.



Human-Readable Breakdown:
The policy implements filename prefix check to target only packages where the filename starts with h11-. The regex match for SemVer, scans those h11- files, and it enforces a filename pattern where , , and  are all numeric.





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.



Terminal logic: 
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 match = true, 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 payload.json 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 payload.json 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.



Custom Actions:
You can define actions like SetPackageState (to Quarantine package and render them unusable) or AddPackageTags (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:












Full Lifecycle Control via API

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.



GitHub Actions is currently the best fit for automating Cloudsmith policy as code workflows due to its flexibility in shell scripting (such as jq and curl). 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.



Simulation First, Enforcement Second

We recommend using the simulation API endpoint 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 match: true/false, any reason messages, and the associated actions 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:





If the policy is already enabled, the decision log will tell users whether the policy matched the scope of their package:





Once the package is pushed to Cloudsmith, you can check your h11 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 DELETE API request:





Your policy, your pipeline

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



Governance that’s automated and programmable.

Standards that are open and inspectable.

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.




### [Pull back the hood on the data and tech that informs EPM](/blog/data-and-tech-informing-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.



But how does it work under the hood?



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 blog post 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 package synchronisation pipeline. 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 Rego recipes page. Additionally, consider using the Simulation API to validate your logic against real package inputs. Finally, review the EPM Decision Logs 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 trigger fires - 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 Policy Triggers section of our docs.



In the Evaluation Phase, 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, Decision Logs are generated during the evaluation phase.



Once evaluation is complete, the Outcome Phase begins. If the policy evaluation results in a match, a predefined sequence of actions is executed in precedence order. These actions (such as AddPackageTags, SetPackageState) 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 terminal, which halts further policy evaluation after it matches. Within a single policy, actions are executed in a deterministic order based on their precedence 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 input.v0.security_scan → CVSS.V3Score), the Status (such as fixed and unfixed), the published dates, descriptions, and the associated identifiers. These allow granular rule logic based on severity, age, fix availability and more.



Cloudsmith also supports querying EPSS (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 vulnerability.epss.score, 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 Trivy database 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.



Now, Cloudsmith introduces a "Block Until Scan" 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 SLSA or NIST SSDF and pass compliance audits with confidence.


Anatomy of a Policy



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 reason message, which is helpful for debugging and explaining decisions. The standard structure sets default match := false and sets match := true if count(reason) > 0, ensuring that matches are both explicit and traceable. Finally, it sets match := true 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.



String Matching and Package Context



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-")



Checker uploader identity:
pkg.uploader == "nigel-douglas"



Block missing metadata:
not pkg.license



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 REST API documentation for Cloudsmith. Alternatively, Cloudsmith’s Ralph McTeggart created a useful ChatGPT Policy Advisor 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 “smart blocking” - 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 blog post 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.


Summary

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.

### [The evolution of Shai-Hulud-style worms](/blog/evolution-of-shai-hulud-worms)

A chronological teardown of the Shai-Hulud worm lineage (including the Mini Shai-Hulud, Miasma, and Hades variants). Learn how subsequent actors bypassed static scanners using Github Actions memory scraping, native build hooks, trojan binary extensions, and LLM analysis misdirection across npm, PyPI, RubyGems, and Docker.

### [Cloudsmith introduces EPSS Scoring in Policy Management](/blog/cloudsmith-introduces-epss-scoring-in-enterprise-policy-management-epm)

Cloudsmith's policy management now supports the Exploit Prediction Scoring System (EPSS), 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 Package Promotion and Package Quarantine.

What is EPSS?

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 rego-based policies in Open Policy Agent (OPA) 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.

The above OPA policy will quarantine and tag a software package with “exceeded-epss” if it sees “HIGH” vendor severity rating and if the EPSS score exceeds the defined threshold in your Cloudsmith repository.

For the purpose of a real-world demonstration, we will use the vulnerable Spotipy package as highlighted in CVE-2025-27154. The spotipy example is a Python library specifically used with the Spotify Web API. Affected versions of this package are vulnerable to Incorrect Default Permissions 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 rw-r--r-- (644) default permissions, as stated by Snyk security researchers.

What’s interesting about this example is that it was picked up by EPSS but hasn’t yet received a “vendor severity” scoring from NIST, 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 (CVE) 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.

Meet Us at Kubecon London

If you'd like to see a demo of Cloudsmith's policy management capabilities with EPSS confidence scoring, why not call over to Booth S280, South Hall – ExCeL London. We’ll be providing live demos until Friday.

### [Policy Management Example: Quarantine Packages Using Policy as Code](/blog/enterprise-policy-management-example-quarantine-packages-using-policy-as-code)

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.

Viewing Code-Based Policies

From the Cloudsmith interface, navigate to the Policies section. Select the Block Risky Packages 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.

Exploring Policy Code

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.

Adding Declarations

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

We then declare the match 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:

Detecting a Match

The match is determined using a match if 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 vulnerability parameter:

Apply and Evaluate Conditions for Each Vulnerability

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

CVE on a user-maintained ignore list – 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:

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

Exceeds CVSS score threshold – 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:

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

And the helper rule:

Check age of vulnerability – 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:

Putting it all Together

You can see the full listing below:

Actioning and Enabling the Policy

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

Tags the package as "risky" – Adds a visible marker so teams can immediately identify problematic artifacts.

Quarantines the package – 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.

Triggering the Policy

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.

Click Repositories and select one for upload. Then use Push/Pull Package 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:

Tags the package as risky

Quarantines it to block deployment, download, and promotion

Logs the decision for audit and review

Using the API

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.

Checking the Decision Log

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:

Checksum values

Vulnerability scan results

Tags

Repository name

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.

Speak to a Cloudsmith expert about protecting your organization from threats using policy management.

[Book a demo](/book-a-demo)