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.
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 does take 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.
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.
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.
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.
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.
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.
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.
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.
Yes. Cooldown policies are configurable by scope, so you can apply stricter windows to high-risk ecosystems or repositories while leaving others unaffected.
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.
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 <MAJOR>, <MINOR>, and <PATCH> 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.
The attack on SolarWinds in December 2020 was a watershed moment: it provided a stark demonstration of how much damage a compromised software supply chain could cause, and a wake-up call for how much trust organizations place in the integrity of the software they depend on. Overnight, everyone learned what a software supply chain was. Developers spent weeks mitigating the risk. Six years later, attackers are now supercharged by agentic AI’s capabilities, and increasingly going after open source packages. The very dependencies that make modern software possible are also putting it at risk. The scale and magnitude of today’s onslaught, with multiple attacks a day, would have been unimaginable in 2020. At the same time AI enables attackers to target any company through the software that runs their business, companies are also building more software than ever. The pace of software development has outstripped what any manual review processes could keep up with. Dependency decisions were traditionally made by a human developer, but now those decisions are increasingly made by AI, either by a citizen developer who is vibe coding or by an AI agent whose mission doesn't include keeping your supply chain free of malicious packages and actors. The usual security model teams have relied on - periodic scanning, resolving issues immediately where possible, backlogging lower-priority issues - can’t keep up with the pace or the style of the attacks we face today. In March 2026, a maintainer account for the popular npm package axios (100M+ weekly downloads) was compromised, allowing attackers to slip in a malicious dependency carrying a postinstall script that ran the instant npm install was called. A malicious package can compromise a developer's machine or a build pipeline instantly, before the first build. Workflows built to protect production are no longer enough to prevent breaches. Protecting your entire organization from cyberattacks requires defense in depth. A critical component of keeping software safe is a curated repository. This means a private, controlled repository that manages software artifacts from the point of ingestion, all the way to production. A curated repository builds a trusted supply chain through knowledge, enforcement, and orchestration When every pull, every build, and every package request flows through a centralized repository like Cloudsmith, you get one place to control what software enters your supply chain, and how it moves through to production. The right private, curated repository serves several functions. It: Covers the packages, formats, and ecosystems your developers use Inspects packages to understand their composition, while extracting key metadata Understands where a package is coming from and where it goes Enriches what’s known about a package to include quality and risk characteristics Can prevent use of a package based on that knowledge, or until more is known about it Can govern how a package moves toward production, or whether it's allowed at all This kind of curated repository becomes the orchestration layer that builds trust in your software supply chain. The way to get it is to use a universal artifact management platform with risk detection and policy built in. Serves as a dependency firewall Provides visibility into where every package comes from Aggregates insights into package quality and risk Updates its risk data as new threats emerge Provides control over how software components move toward production Policy management and continuous risk detection are now baseline requirements Cloudsmith's new policy management and continuous risk detection capabilities should be considered table stakes for any organization that wants to control and secure its software supply chain. Custom policies Write your own logic in Rego, the open source policy language used in the Open Policy Agent (OPA) framework, tailored to your specific security and compliance requirements. Always-on enforcement Policies are evaluated on package ingestion, and re-evaluated in real time automatically as policies or threat intelligence changes Cooldown policies Cooldown policies hold new package versions back from clients for a set window of time, so security researchers have a chance to identify malicious releases. Policy templates Cloudsmith-recommended policies already written for you, so you don't need to write Rego from scratch. Decision logs A full audit trail of every policy evaluation, viewable in the web app and downloadable via API Because they’re written as code, Cloudsmith policies are incredibly powerful and flexible. You can make decisions based on key attributes of a package, like license information or package age. Cloudsmith's continuous risk detection systems bring security intelligence into the policy layer, so your policies keep up with the latest threat intelligence. Detection In the Cloudsmith platform, threat detection runs automatically, for every supported package format in your workspace. Cloudsmith refreshes threat intelligence every five minutes, so if a new or updated record affects packages already in your repositories, they’ll be matched automatically. The days of scheduling periodic rescans are over. To make sure nothing is missed, packages are matched to public security advisories based on a standard identifier called a package URL (PURL). Cloudsmith supports SemVer and ecosystem-native version ranges when matching advisories to specific versions of packages. Viewing results A single publicly identified vulnerability may be reported by multiple sources, resulting in duplicate records from different upstream databases. Cloudsmith automatically detects these duplicates, grouping and surfacing one primary record per vulnerability. This results in cleaner data and more focused reviews. By default, packages are sorted by severity, highest first: Malware, then Critical, High, Medium, Low, and Unknown. Control your software supply chain without slowing down developers Over the years, we’ve found that artifact management has historically been the purview of platform engineering teams. These teams traditionally look to centralize critical workflows, to ensure consistent, standard delivery. But we’ve seen a change in the market recently. Security teams are increasingly recognizing that centralizing these workflows enhances security. Cyber security teams can partner with developers by enforcing policies that redirect direct access to public registries to a curated, managed repository that serves as a trusted proxy. Development teams still need to move fast, so enforcement actions that affect a developer's workflow have to be built with the developer experience in mind. Cloudsmith solves this in a uniquely developer-friendly way. Cloudsmith policies remove bad packages from the index that is presented to package managers. This changes the package version selection process, so that developers get compliant packages the first time, rather than an error message and a broken build. If a specific pinned package version is requested, but that version has been quarantined for security reasons, clear messaging and integrated workflows tell developers why their build failed, and what they can do about it. A secure software supply chain starts with universal artifact management We’ve all come a long way since the SolarWinds attack in 2020. We’ve learned how to secure the software supply chain, without slowing down developers. Every package your team requests should pass through curated repositories, where policies tailored to your security and compliance requirements can protect your builds, backed by realtime, always-updated threat intelligence. The artifact management platform serves as the orchestration layer, across every team, pipeline, and AI agent, enforced at the source, automatically. See how continuous risk detection and policy management work or contact us for a demo to see how we can solve your needs.
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'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.
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.