Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

Cloudsmith built Enterprise Policy Management (EPM) on Open Policy Agent (OPA) and uses Rego to define policies as code. These policies control how packages move through your systems. They're versioned, reviewable, and enforceable.

EPM 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 Rego-based rules 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 Rego script with the necessary dependencies:

package cloudsmith # use the Cloudsmith namespace

import rego.v1 # use the standard Rego library

We then declare the match variable to store whether the vulnerability matches our criteria:

default match := false

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

max_epss := 0.2
max_cvss_score := 7
target_repository := "org-repo-name"
older_than_days := -30
ignored_cves := {"CVE-2023-45853"}

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:

match if {
    # load data
    # perform tests
}

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:

# Check repository
input.v0["repository"]["name"] == target_repository

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:

# Iterate through all vulnerabilities in `v0["vulnerabilities"]`.
some vulnerability in input.v0["vulnerabilities"]

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:

# Must not be in our ignored CVE list
not ignored_cve(vulnerability)

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

ignored_cve(vulnerability) if {
    vulnerability["identifier"] in ignored_cves
}

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

 # Must have a known patch for this vulnerability
 vulnerability["patched_versions"]

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

# Must exceed our CVSS score threshold
exceeded_max_cvss(vulnerability)

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

exceeded_max_cvss(vulnerability) if {
    some _, val in vulnerability.cvss
    val.V3Score >= max_cvss_score
}

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

# Must exceed our EPSS score threshold
exceeded_max_epss(vulnerability)

And the helper rule:

exceeded_max_epss(vulnerability) if {
    vulnerability.epss.score > max_epss
}

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:

# Check published date is older than (now + older_than_days).
t := time.add_date(time.now_ns(), 0, 0, older_than_days)
published_date := time.parse_rfc3339_ns(vulnerability.published_date)
published_date <= t

Putting it all Together

You can see the full listing below:

package cloudsmith

import rego.v1
default match := false

max_epss := 0.2
max_cvss_score := 7
target_repository := "org-repo-name"
older_than_days := -30
ignored_cves := {"CVE-2023-45853"}

match if {
    input.v0["repository"]["name"] == target_repository
    some vulnerability in input.v0["vulnerabilities"]    
    not ignored_cve(vulnerability)
    vulnerability["patched_versions"]
    exceeded_max_cvss(vulnerability)    
    exceeded_max_epss(vulnerability)

    t := time.add_date(time.now_ns(), 0, 0, older_than_days)
    published_date := time.parse_rfc3339_ns(vulnerability.published_date)
    published_date <= t
}

exceeded_max_epss(vulnerability) if {
    vulnerability.epss.score > max_epss
}

exceeded_max_cvss(vulnerability) if {
    some _, val in vulnerability.cvss
    val.V3Score >= max_cvss_score
}

ignored_cve(vulnerability) if {
    vulnerability["identifier"] in ignored_cves
}

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 using EPM. 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.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet