Regulatory compliance in the software supply chain is a moving target that shifts with every dependency, security advisory, and regulatory update. Cloudsmith’s EPM puts control back in your hands by enabling development and operations teams to create real-time policy enforcement, right where it matters: at the package level.

By leveraging OPA and Rego, EPM lets you define precise, programmatic policies that determine how packages are evaluated, tagged, or quarantined before they’re ever promoted downstream. That means compliance policy enforcement is built directly into your distribution pipeline rather than being left to chance, or worse, post-release audits.

For development teams out there, the last thing we want to do is slowing you down with red tape security features. We want to help shift compliance left in the supply chain so issues are caught early, consistently, and transparently. Whether it’s blocking unlicensed packages, quarantining vulnerable builds, or ensuring artifacts meet naming conventions, EPM ensures that policies are applied automatically and uniformly through your own unique policy-as-code configurations.

Copy-Left policy that matches license strings

This policy is important from a compliance perspective because the use of copyleft or restrictive open-source licenses in production environments can create significant legal and operational risks if not properly managed. Many of these licenses impose obligations, such as requirements to disclose source code, distribute derivative works under the same license, or provide attribution, that may in some cases be incompatible with an organisation’s business model, intellectual property strategy, or contractual commitments.

By proactively detecting both free-text and standardised System Package Data Exchange (SPDX) variants of these licenses, the policy ensures that potentially problematic code is flagged before it reaches production, enabling the necessary legal review or approval. This not only reduces the risk of inadvertent license violations but also demonstrates due diligence in open-source governance, which is often a key expectation in audits, customer contracts, and regulatory environments.

package cloudsmith
default match := false
# Expanded list of SPDX identifiers and common free-text variants
copyleft := {
    "gpl-3.0", "gplv3", "gplv3+", "gpl-3.0-only", "gpl-3.0-or-later",
    "gpl-2.0", "gpl-2.0-only", "gpl-2.0-or-later", "gplv2", "gplv2+",
    "lgpl-3.0", "lgpl-2.1", "lgpl", 
    "agpl-3.0", "agpl-3.0-only", "agpl-3.0-or-later", "agpl",
    "apache-1.1", "cpol-1.02", "ngpl", "osl-3.0", "qpl-1.0", "sleepycat",
    "gnu general public license"
}

match if count(reason) > 0
reason contains msg if {
    pkg := input.v0["package"]
    raw_license := lower(pkg.license.raw_license)
    some l in copyleft
    contains(raw_license, l)
    msg := sprintf("License '%s' is considered copyleft", [pkg.license.raw_license])
}

Trigger Condition
The license trigger conditions are highlighted in our detailed schema which is available towards the bottom of Cloudsmith OpenAPI under PolicyPackageLicense.

When and How It’s Triggered
Once ready, download the Python Gitlab v.3.1.1 package that we know has a GNU Lesser General Public License (LGPLv3) license that should trigger the policy:

pip download python-gitlab==3.1.1
cloudsmith push python $CLOUDSMITH_ORG/$CLOUDSMITH_REPO python_gitlab-3.1.1-py3-none-any.whl -k "$CLOUDSMITH_API_KEY"

Note: If you have a tagging response action attached to your policy, you could tag the package with non-compliant-license for further review, as seen here:

Quarantine Debug Builds

This policy checks whether a package includes specific debug, test, or temp descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the production repository.

package cloudsmith
import rego.v1
default match := false

match if count(reason) > 0

reason contains msg if {
  pkg := input.v0["package"]
  re_match(".*(debug|test|tmp).*", pkg.filename)
  msg := sprintf("Debug/test artifact detected in filename: %s", [pkg.filename])
}

Trigger Condition:
The policy will trigger on these kind of wildcard examples:

debugpy-1.6.7...whl
pytest-...tar.gz
mylib-test-1.0.0.tar.gz
tmp-utils-0.1.0.whl

Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns. Once ready, you can download the debugpy Python package and push it to Cloudsmith to cause the policy violation:

pip download --no-deps --dest . debugpy 
&& cloudsmith push python $CLOUDSMITH_ORG/$CLOUDSMITH_REPO debugpy-1.8.14-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl -k "$CLOUDSMITH_API_KEY"

From a compliance perspective, preventing debug, test, or temporary builds from entering production is critical because these artifacts often contain unverified code, verbose logs, or experimental features that were never intended for public release. If deployed, they may expose sensitive internal information, introduce security vulnerabilities, or degrade system performance, any of which can result in regulatory noncompliance, contractual breaches, or audit findings. Enforcing this control at the ingestion point ensures that only vetted, production-ready packages flow downstream, reducing the likelihood of costly incidents while demonstrating due diligence in software governance.

The use of RegEx strengthens this control by providing a highly adaptable mechanism for detecting noncompliant naming conventions across diverse development and CI/CD practices. Instead of hardcoding rigid checks, RegEx allows compliance teams to define broad yet precise patterns that evolve alongside the organisation’s software ecosystem. This flexibility enables policy enforcement to remain effective without creating excessive operational overhead.

Approved Upstreams based on Tags

This policy exists to ensure that packages coming from upstream sources are explicitly reviewed and marked as "approved" before being allowed to proceed in the pipeline.

package cloudsmith
import rego.v1
default match := false

approved := "approved"
upstream := "upstream"
#allowed_repos := {"test-repo"}  # Define your set of allowed repositories

match if {
    not has_approved_tag
    has_upstream_tag
#    is_in_allowed_repo
}

has_upstream_tag if {
    some _, type in input.v0["package"].tags
    some tag in type
    tag = upstream
}

has_approved_tag if {
    some _, type in input.v0["package"].tags
    some tag in type
    tag = approved
}

Trigger Condition:
The policy matches when:

• The package has a tag "upstream".
• The package does not have a tag "approved".

You could think of this as an advanced use-case for tagging. When both conditions are true, the policy will trigger. Note: There is also a commented-out condition for restricting it to specific repositories, if you’d prefer to whitelist certain repositories that are not under the same level of regulatory scrutiny.

From a compliance perspective, this policy enforces a controlled workflow for handling externally sourced or upstream packages, which are often beyond the direct control of the security team. By requiring an explicit "approved" tag before these packages are considered safe, it creates a checkpoint where security, licensing, and quality reviews can be performed. This helps prevent unverified or potentially malicious code from entering production systems. It also encourages consistent documentation of the approval process, which can be important for compliance frameworks such as SOC 2, ISO 27001, or internal governance policies.

From a risk management perspective, the policy reduces the chance of introducing vulnerabilities, licensing conflicts, or compatibility issues from upstream sources. Operationally, it gives teams the flexibility to integrate valuable external software while maintaining a robust safeguard against unvetted changes. Over time, this approach can significantly improve software supply chain security, maintain regulatory compliance, and protect the organisation’s reputation by ensuring only reviewed and trusted packages make it into critical environments.

Architecture-specific allow list

This policy only allows amd64 architecture packages and blocks others like arm64.

package cloudsmith
default match := false

match if count(reason) > 0

reason contains msg if {
  some arch in input.v0.package.architectures
  arch.name != "amd64"
  msg := sprintf("Architecture '%s' is not permitted. Only 'amd64' is allowed.", [arch.name])
}

When and How It’s Triggered
To trigger the above policy (which blocks all architectures except amd64), you'd want to upload or sync a Python package that is built for a non-amd64 architecture - like arm64. However, pip by default fetches packages built for your local system architecture, so you typically won't download architecture-specific wheels unless they're explicitly tagged.

Here's a command to download a numpy Python package with an ARM-specific wheel using pip download:

pip download numpy --platform manylinux2014_aarch64 --only-binary=:all: --python-version 38 --implementation cp --abi cp38
cloudsmith push python $CLOUDSMITH_ORG/$CLOUDSMITH_REPO numpy-1.24.4-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl -k "$CLOUDSMITH_API_KEY"

This architecture-specific allow list policy plays a critical role in compliance by ensuring that only packages built for the approved amd64 architecture are permitted in production and testing environments. In organisations standardised on x86-based servers, containers, and CI/CD pipelines, introducing packages built for other architectures, such as the case with arm64, can create hidden risks such as runtime failures, inconsistent behaviour across platforms, or the inability to reproduce builds reliably.

From a compliance perspective, these risks undermine key principles of software assurance, reproducibility, and auditability, all of which are essential for demonstrating control over the software supply chain. Blocking non-amd64 packages at enforcement ensures that software deployed downstream aligns with documented infrastructure baselines, reducing the likelihood of noncompliant system configurations.

Additionally, different architectures may introduce unique vulnerabilities, require distinct patching procedures, or fall outside the scope of validated security tools and compliance checks. Allowing multiple architectures without proper governance complicates vulnerability management, weakens evidence for audit trails, and can create gaps in regulatory coverage. By restricting deployments to a single, vetted architecture, this policy simplifies compliance verification, strengthens the integrity of vulnerability scanning, and provides assurance that all deployed software is consistent with approved security and operational standards.

Build your own compliance policies with Cloudsmith EPM

These four examples illustrate just a handful of the ways Cloudsmith EPM can be applied to enforce regulatory compliance across your software supply chain. From licensing governance to architecture restrictions, debug-build quarantines to upstream approvals, each policy demonstrates how compliance controls can be codified, automated, and enforced consistently.

But this is only the beginning. Because EPM is powered by OPA and Rego, it offers almost limitless flexibility to address the unique compliance challenges your team is facing. Whether you’re aligning with industry standards like ISO 27001 or SOC 2, meeting customer contract requirements, or simply reducing operational risk, you can design policies as code that fit your exact environment.

The power lies in treating compliance as part of your pipeline rather than an afterthought. With Cloudsmith EPM, you can move fast without breaking trust, ultimately ensuring that every package that flows downstream has already been checked, validated, and approved against the rules that matter most to your business. Check out our official documentation on how to get started with EPM policies today.