By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

In Q3 we further improved platform security capabilities and enhanced developer experience.

 this quarter. This roundup provides a brief overview of each.

Policy management and risk detection are key security features in Cloudsmith and they reached general availability this quarter.

This is Cloudsmith’s policy engine that allows users to write policy-as-code across the web app, API, and Terraform provider.

With policy management you can write custom policies in Rego that are automatically enforced across your Cloudsmith account. This includes cooldown policies that hold newly released packages for a set period (see more on these below), policy templates to get started quickly, and decision logs that record evaluation. Everything lives under the 

With policy management, rules about which packages are safe and acceptable are automatically enforced on every package at the registry, before they reach your build environment. Changes in threat intelligence or updates to policies automatically trigger re-evaluation so your risk exposure is always current. 

This feature automatically checks incoming packages and those already in your repository against known vulnerabilities and malicious packages. Detection is powered by 

, which triggers new evaluations as new threat intelligence hits the data feed.

This feature helps compress the gap between when new threat advisories are published and when organizations evaluate packages against those advisories. Because this feature runs continuously, teams don’t need to wait for the next scheduled scan, a delay that widens their exposure window.

Cooldown policies became generally available for npm and Python in Q2, and in Q3 we expanded support to six more formats: 

. You can create cooldown policies via the web app, API, or Terraform. These updates extend the reach of cooldown policies beyond application libraries to include container images and Rust crates. 

This is an improvement in the policy editor that flags Rego problems as you write. On save, the web app and API reject disallowed builtins (such as 

), type mismatches, incorrect argument counts, and unsafe or undeclared variables. The web app editor also warns when a policy is missing `package cloudsmith` or a match rule, highlights malformed Rego inline, and autocompletes schema field names.

Catching mistakes while you type means fewer policies that silently fail to do what you expect, and a shorter learning curve for teams new to Rego.

Download vulnerability findings from the web app

 on a package’s Overview tab to export every vulnerability and malicious package record matched to it as JSON. This data is also available from the Packages Vulnerabilities List API endpoint.

Simplify incident investigation and compliance audits by allowing security teams to send findings to a ticketing system, SIEM, or auditor in one click, without writing an API script.

Hardened images tab for configuring upstreams

Upstream configuration now supports Docker Hardened Images (DHI), Chainguard Containers, and WizOS. The DHI Community and Chainguard Containers Free tiers come pre-configured. For paid tiers, the proxy URL is filled in for you, so you only name the upstream and add credentials.

Making hardened images quick to proxy lowers the cost of adopting them, and every pull is cached, logged, and subject to your policies.

Libraries tab for vendor-curated package registries

 tab quick-configures library registries, which include vendor-curated feeds of open source packages that may be pre-vetted, rebuilt from source, and security scanned. Currently, this feature supports Chainguard Libraries (Maven, Maven Remediated, npm, PyPI, PyPI Remediated) and RapidFort Curated Libraries (npm).

Teams can adopt curated, rebuilt-from-source packages as a drop-in upstream and manage them alongside public upstreams and private packages in one place.

Go upstreams for any GOPROXY-compatible proxy

Go upstreams can now point to any GOPROXY-compatible module proxy, in addition to the public mirror at 

. That includes private proxies such as the Buf Schema Registry (BSR).

This feature gives you one control point for all Go dependencies, with caching, policy, and logging, instead of managing multiple GOPROXY settings.

CLI v1.19.0: automatic OIDC and Docker credential discovery

The Cloudsmith CLI automatically discovers OpenID Connect (OIDC) credentials for all major CI/CD platforms and includes a Docker credential helper to automatically authenticate to Cloudsmith registries. This eliminates the need for static API keys in CI/CD pipelines.

Long-lived API keys stored as CI secrets are one of the most common ways credentials leak. With OIDC discovery, there’s nothing to store, rotate, or leak.

The Cloudsmith CLI now ships as a standalone, self-contained binary for Linux, macOS, and Windows, eliminating its dependency on a local Python environment.

This means that pipelines no longer break when a runner’s Python version changes, and installs are faster and identical on every platform.

CLI v1.21.0 to v1.26.0: Nix, Cargo and pnpm helpers, and repo admin

Multiple updates to the Cloudsmith CLI with this changelog include:

: Treats Nix as a first-class format and users can push Nix packages and manage Nix channel upstreams

: Includes support for Cargo and pnpm, plus a generic helper that prints a credential as JSON for any script

: Cloudsmith can now push a Debian package by reading the 

: SSO and OIDC sessions work in more places: encrypted file-based keyrings, new keyring environment variables, and 

: Keychain prompts no longer reappear after every token refresh

Package logs are now available in the web app under the 

 tab. This per-package audit trail allows users to track package actions, including copy, delete, hard delete, move, policy violation, quarantine, restore, resync, sync, and tag changes.

This update speeds up incident response and gives you ready-made compliance evidence.

Client logs show the full request chain behind a download

Client logs now capture format-specific metadata for every supported format, including metadata fetches and redirects, not just the final file download.

This helps you understand which version a build resolved and where that decision occurred. It also accelerates debugging questions around package selection and how certain packages made their way into specific builds.

Downloads, token use, and client logs in the Broadcasts app

 app now shows how published packages are consumed: counts of broadcasting packages, entitlement tokens active this billing cycle, usage by repository, and top downloads. A world map and table break down delivery by country, and a filterable client log stream shows individual requests.

For users that distribute software to customers, this improvement puts adoption and per-customer usage data in one place. That can help with product decisions and license compliance, and makes unusual entitlement token activity easier to spot.

Cloudsmith can now serve as a public or private Nix binary cache. Teams that use Nix can push packages with the native 

 command, and Cloudsmith signs store paths with the repository's Ed25519 key when they’re read, so key rotation takes effect immediately and multiple keys can be valid at once. Nix upstreams proxy and cache NixOS release channels, one upstream per channel.

Nix teams can retire self-hosted Nix caches and manage Nix packages with the same access control and visibility as their other formats. Signing on read means rotating a compromised key doesn’t require re-signing.

We added support for PEP 658, allowing Python package clients to fetch only metadata from the Simple API during dependency resolution.

Because you don’t need to download large archives, dependency resolution gets faster and more reliable, with less bandwidth and less load on upstream caches.

Cloudsmith API keys are detectable by GitHub secret scanning

Cloudsmith joined the GitHub secret scanning partner program. API keys carry a unique prefix registered with GitHub, so a key committed to source, a config file, or a 

 is flagged automatically, and Cloudsmith notifies the affected user and workspace owners to rotate it.

This program detects keys on push, not when someone misuses them, shrinking the window attackers have to exploit those keys.

Secret scanning alerts link to each detection location

Related to the previous changelog item, this update improves the email notification process by including detailed information about every place a key was found, grouped by files and commits, issues, pull requests, discussions, and wiki commits, with a direct link to each. Every detection also records an 

This information can speed up remediation from exposed secrets and provides a documentation trail for incident reviews.

Read-only access to billing, usage, and OIDC data

Workspace owners can now separately grant members read access to billing information, usage data (including artifact storage and delivery quotas), and OIDC settings, without giving anyone the Manager or Owner role.

SCIM group provisioning is now generally available

You can now provision Cloudsmith team membership from groups in your identity provider (IdP). Adding or removing a user from a mapped group in your IdP updates their Cloudsmith team membership automatically. Users provisioned through SCIM groups get the 

 role by default, which you can change from the 

With this update, your IdP becomes the single place to manage team membership across your organization, and Cloudsmith automatically follows, which also speeds up onboarding and offboarding. This functionality is available on Ultra and Enterprise plans.

Security researchers now submit reports through a dedicated platform at 

 that shows where each report stands. Rewards are now paid once a qualifying defect is confirmed, rather than after a fix ships.

Jason Myers

Technical Content Marketer

Everything Cloudsmith shipped in Q3 2026

What happens when a new vulnerability emerges for a package you already used in a build? If you don’t find out about that new vulnerability right away, then your production system is at risk until the next security scan runs. Scan results provide a point-in-time snapshot, but they’re only valid until the next CVE comes out. Currently, we’re seeing an 

 solves this problem using a near-real-time threat data feed to power a lightweight lookup rather than an in-depth scan, allowing it to run as new advisories emerge. If you scan daily, continuous risk detection can reduce a 24-hour risk window to as little as five minutes.

Scanning is a package-centric process. For every package in a repository, the scanner needs to schedule a scan, prepare the package to scan, perform the analysis, and then store the result. This is a resource-heavy process, making it expensive and time-consuming. Typically, that means packages get scanned once on upload and don’t get evaluated again until a daily or weekly scheduled scan occurs, or someone initiates a manual scan. In practical terms, this means that scan results go stale quickly because they are only relevant as of the time that the most recent scan occurred.

Because scanning is such a valuable tool, the natural reaction may be to run scans more frequently. There are several technical reasons that make scanning more often a challenge.

The first is a cardinality problem. Scan time scales with the product of the number of packages in a repository and the number of CVEs that have accumulated since the last scan. Enterprise-scale repositories are so large (e.g., tens of thousands of packages) and CVE lists are so long (e.g., hundreds or thousands, depending on the scan schedule) that a full rescan can take longer than the interval between new threat advisories.

Another issue is that scanning images increases the scanners’ workload. Each image contains a bundle of packages, e.g., the base image, installed dependencies, layers, and the scanner needs to unpack all those elements, identify them, and then scan each one. A base image package also gets scanned in every downstream image that includes it, which further compounds the cardinality issue.

Because scanning tools can’t run continuously, teams often use multiple different scanners at different development stages, e.g., at source, build, test, and runtime. Different tools often use different output formats and lack a common data store for scan results, so results from a source-stage SCA scan may not be able to share results with a build-stage SCA scanner. The result is a visibility gap that prevents teams from having a holistic view of their environment’s overall risk level.

Continuous risk detection uses matching to enable real-time security evaluations

Where scanning uses a package-centric approach, continuous risk detection uses matching, which is vulnerability-centric. Packages contain a unique package URL (PURL) that details the package name, ecosystem, and version. Threat advisories carry PURLs too, and continuous risk detection uses a lightweight database lookup to match the PURL in the threat advisory to packages entering or already in a repository. There’s no need to perform a complete in-depth scan, which means that the matching process can run continuously as new advisories get published.

Because matching is less resource intensive, it can run at the artifact registry layer. This is important because the artifact management platform plays a unique role in the software development lifecycle; it evaluates every package and dependency that enters the development environment, and interacts with every stage of the development process.

An artifact manager provides broad and consistent visibility across the entire development environment. It keeps a persistent set of metadata for every package in the repository over the lifespan of the package and knows every build that consumed a package. When a new CVE emerges, continuous risk detection can look at any package you’ve ever used and determine if there’s a match. Standalone security tooling lacks a persistent repository and can’t make the same determination.

Furthermore, because continuous risk detection is a native capability of the Cloudsmith platform, it’s able to trigger 

security policies when it detects a CVE match. You can use that same persistent repo data in custom policy-as-code security policies, making the two features intrinsically connected in the platform. This is another reason to use Cloudsmith as the control plane for software development.

The main limiting factor to both scanning and matching is that they rely on known CVEs, so zero-day threats remain a concern for security teams. In Cloudsmith, you can augment continuous risk detection with another proactive security policy: a 

. Cooldown policies hold newly released packages for a set period of time (e.g., 3-7 days) to allow threat intelligence researchers to vet them, helps to bridge the zero-day gap, and contributes to a defense-in-depth security posture.

Continuous risk detection matches threat data to new packages at ingest and continuously thereafter when new threat intelligence lands. Powered by 

, the data feed for continuous risk detection provides near real-time threat evaluations for every package in your repository.

 to learn more about continuous risk detection and how it can improve your security posture.

How continuous risk detection replaces point-in-time scans with real-time monitoring

Cloudsmith provides a control plane at the registry layer, enforcing policies against any ingested artifact to bolster your security posture. Here, we dig into the mechanics of the specific Cloudsmith capabilities that make enforcement at the registry work, and what makes each one meaningfully different from what you can do with a CI gate or a standalone scanner.

Policy management: Write policy against a breadth of risk signals

 is built on Open Policy Agent (OPA) and uses Rego as its written language. In Cloudsmith, the power of policy management comes from what you can write policy against.

Other enforcement approaches often rely on blunt, binary policies. This lack of granularity can result in blocking approved packages, which creates noise and disrupts developer workflows. For example, a binary control may block a package with a CVE score that exceeds a threshold. But CVE is only one of many potential threat signals. CVE severity tells you how bad a vulnerability 

 be. It doesn’t say anything about the likelihood of exploitability. Policy management lets you combine severity with EPSS scores. A package with a critical CVE with a 0.1% EPSS score and a package with a medium CVE currently being actively exploited are not equivalent risks, and your policies don't have to treat them as if they are.

Beyond vulnerability data, policies can evaluate against license type, upstream publish date, package age, custom metadata, and, for Docker images, SBOM contents. That constitutes a much broader range of signals for security teams to use when deciding whether a dependency belongs in their environment. Cloudsmith makes all that data available as policy inputs.

To aid with set-up, provide pre-configured policy templates covering the most common enforcement scenarios. Users can edit and amend these policies as their needs evolve. Legacy artifact management tools that claim similar policy-as-code capabilities added it by way of acquisition. This kind of bolt-on solution often forces users to manage admin configurations in multiple places. Cloudsmith policy management is native to the platform with all controls and options under the “Policies” tab. These policies also apply across Cloudsmith’s multi-format repos, so you can write a policy once and apply it globally.

Cooldown policies: Closing the remediation window

It’s impossible to predict what packages attackers will target next. So, when a new supply chain attack occurs against a package you depend on, what do you do in the window between when the attack begins and a CVE surfaces? That’s the most dangerous time because you may pull a compromised package without realizing it. Without a cooldown policy, that package enters your environment unchecked.

 address zero-day threats by hiding newly published packages from the index for a configurable period (e.g., 3-7 days). Threat researchers typically identify and report malicious packages within the first few hours or days after publication. The cooldown window provides a default buffer for threat researchers to catch up. If no advisory emerges during the cooldown window, the package releases into your environment once it ends. For security-focused teams managing active CVE incidents, this is one of the more operationally specific controls in the feature set; it targets the exposure window directly, rather than just blocking on severity at a static point in time.

Continuous risk detection: Enforcement that reflects current threat data

Vulnerabilities can go undetected for years after a package is published, or a dependency that was clean on Monday may have a critical CVE attached to it by Thursday. Regardless of how long a package has been in your private repository, you need a way to check it against current threat data.

. Rather than rescanning packages on a schedule, Cloudsmith extracts metadata from each package at sync time and continuously matches it against OSV.dev. When a new CVE, EPSS update, or malicious package record lands in the feed, and Cloudsmith finds a match with a package in your registry, this triggers your policies to re-evaluate the package and take the associated action, e.g., quarantine.

OSV.dev draws on a wide range of data sources, including NVD, GitHub Security Advisories, ecosystem-specific databases like PyPI and RubyGems, and malicious package records covering npm, NuGet, PyPI, and RubyGems, among others. EPSS scores are embedded directly, making them available as policy inputs without any additional integration work.

The result is policies that evaluate against a live view of current threat data, not whatever the feed showed when the package first arrived.

Every policy evaluation Cloudsmith runs produces a decision log entry: what triggered, what data informed the decision, what action the policy took, and why.

In a compliance review, e.g., SOC 2 Type II, DORA, FedRAMP, PCI-DSS, or CRA, log data is the evidence that your controls are real and operating as specified. In an incident response scenario, it’s the audit trail that tells you what was in your environment and what your policies did about it.

Decision logs are queryable via API, which means they integrate into whatever reporting or observability tooling your team already uses.

Why these capabilities reinforce each other

These capabilities cascade into and connect with each other. Continuous risk detection updates the risk profile that policy management evaluates against. Policy evaluations, including cooldown windows, produce decision log entries. Decision logs close the audit gap that makes enforcement defensible in a compliance review.

Cloudsmith delivers a continuous control plane for safely consuming open source dependencies. That's the structural difference between a security program built on Cloudsmith’s security features and one that relies on point-in-time scanning and downstream pipeline gates.

 about what security enforcement looks like for your environment.

How Cloudsmith security features work: policy, risk detection, and the audit trail

With legacy artifact managers, every ecosystem that dev teams use requires a separate repo. What happens when teams try to keep their line of work isolated, but they rely on the same ecosystem and packages as other teams? Platform teams have to configure multiple instances of the same repo for each team. This increases the complexity of the organizational repo structure, and means more repos, URLs, configs, and security policies to manage, not to mention greater storage needs. Using Cloudsmith’s 

 you can configure multiple upstreams in a multi-format repo, cache those packages once, and deliver them to downstream repos, all with a single URL.

Maintaining upstreams for every individual repository comes with an overhead tax. The amount of effort teams have to put into maintaining upstreams can quickly become a burden depending on how they structure their repositories. Legacy artifact managers rely on language-specific repos so teams need to configure an upstream for each repo. Therefore, if you use npm, Python, Rust, and Maven, then each language has its own upstream URL, configuration, and security policy. Now, if you’re working on a small team and those are the 

 repositories you pull from, it's manageable. But at scale, going from four repos to 40+, things get much more complex.

While maintaining dozens or hundreds of repos is a very real burden, it's the toll all those endpoints take on your security at scale that's easy to overlook.. The need to configure security policy for each individual upstream simultaneously increases the attack surface and the number of gaps within that attack surface. Policy enforcement becomes inconsistent and hard to do across enterprise-scale upstream configurations. A single enforcement point decreases risk by removing many of the gaps within the attack surface.

Connected repositories are a native Cloudsmith feature that links repositories and resolves packages through a single URL. The images below illustrate two different architectural configurations of connected repositories.

Cloudsmith supports multi-format repositories, so users can configure a single repository with multiple upstreams, as seen in configuration B. The OSS Packages Repository has upstreams for Maven, Python, and NuGet, and this is where packages from those ecosystems get cached. The repository, which is where end users pull from, doesn’t perform any caching or duplication of packages in the OSS Packages repo; it inherits the upstreams from the OSS repo and pulls packages straight through. When configuring connected repositories, teams can set priorities for each upstream (see config B). If two upstreams have the same priority, Cloudsmith automatically breaks these ties based on the upstream creation timestamp.

Package resolution is also automatic for connected repositories. You can see in configuration B above that the Enterprise Packages Repository is PRIORITY 1, the Shared Packages Repository is PRIORITY 2, and the OSS Packages Repository is PRIORITY 3 for the main repository. Cloudsmith resolves packages inside Cloudsmith in priority order first, then resolves packages outside Cloudsmith in priority order. Going back to the diagram, any packages in the main repository get resolved first, followed by packages in the Enterprise Packages Repository, then packages in the Shared Packages Repository, and finally packages in OSS Packages Repository. Each of the upstreams in the OSS repo will have a priority status, so those will resolve according to their established priority.

Connected repositories can reduce upstream sprawl and provide teams with more flexibility in how they structure their repos within their artifact manager. The repo architecture that’s right for your team will depend on what factors you value. Typically the key tradeoffs come down to isolation, visibility, access controls, and operational overhead. (If you want a detailed breakdown of the architecture configurations below, our team can 

 This configuration is exactly what it sounds like. A single repo for every package. While this is structurally simple to set up and run, there is no isolation between lines of work or development environments. This approach works for small teams, but quickly becomes unwieldy for larger teams.

 This approach creates one repo for every language or format a team uses. This is a familiar repo structure used by legacy artifact managers. It offers a single source of truth for each development language and keeping a format-specific approach can make migrating to a new artifact manager easier. However, this structure lacks combined visibility across formats for usage, licenses, vulnerabilities, logs, etc.

 This structure has a repo for each team, service, or product. The line of work approach allows teams to own their repos, which means they can set up granular access controls, giving them more accountability over the trust decisions in their development environment. As for tradeoffs, this structure has higher potential to house duplicate packages and to create sprawl, especially if the repos don’t support multiple formats. Teams need strict tagging discipline when using this approach. For example, poor tagging could lead to deleting packages needed for production

This approach includes one repo for each different production environment, typically build, test, and production. Environment-scoped RBAC and retention rules help to avoid some of the challenges with the line of work approach. This structure also provides a really clean promotion pathway; teams can clearly tell which development stage a package in is based on the repo storing it. The tradeoff is that teams have less visibility into specific lines of work, and need to make sure they follow clear naming conventions to avoid package conflicts.

 This approach combines the line of work and environment-based structures. It consists of one repo for each line of work within each environment-based repo. While it combines the best aspects of those two approaches, it also introduces the potential for repo sprawl, depending on how many lines of work a company has. This structure also requires advanced package promotion logic to ensure the right packages get promoted to the right location. Sharing packages across lines of work can also be challenging, depending on how teams configure their repos.

Connected repositories give you flexibility. The flexibility to pick a repo structure that fits the needs of your organization and the way your teams want to work. You get the flexibility of optimizing your repo structure to accentuate the tradeoffs you want over the ones forced on you from inherited systems. Connected repositories can reduce the URL- and upstream-sprawl that resulted from choosing anything other than a super-repo.

Ready to optimize your repo architecture? 

Simplify repository structure with connected repositories

The tools security teams reach for first inspect code at different points in the development process: at the PR stage, at build time, or monitoring what's running in production. They're solving real problems, and they're good at them. What they don't do is govern which packages are allowed to enter your environment in the first place.

That control happens at the artifact registry, which is the one place every package, team, and pipeline passes through. A scanning tool that runs at PR time sees a dependency after it's already been fetched. A runtime tool sees it after it's deployed. Cloudsmith sits upstream of both: before a dependency reaches a developer, a build tool, or a CI job, Cloudsmith checks against current threat intelligence and uses your policies to clear or block it. The scanning you already have gets cleaner input. Cloudsmith provides the enforcement layer the security stack was missing.

Three capabilities form the foundation of a dependency firewall posture: controlled upstream ingestion, continuous metadata enrichment, and a customizable policy engine. Together they create a control layer that decides what enters your environment automatically and keeps re-evaluating that decision as intelligence updates.

Most security tools evaluate packages after they enter your environment. Cloudsmith governs what's allowed in before a build runs and checks everything in your repositories when new threat intelligence drops. No team has to configure its own pipeline rules to get that coverage. This guide covers upstreams, continuous enrichment, and policy as code built on OPA, from initial configuration through to enforcement.

 route all public registry requests through your Cloudsmith repositories rather than letting build tools pull from registries directly. Every package request resolves through a configured upstream. Cloudsmith fetches each package once and caches it permanently, serving it from your repository from that point forward. When a public registry has an outage, your builds continue.

The security consequence matters more than the availability benefit: you have a single point through which all package traffic flows. Without it, policies can't enforce consistently because downstream rules only catch what passes through them. The upstream is the prerequisite everything else builds on.

 closes dependency confusion attacks at the configuration level, before policy evaluation runs. When you mark a public registry as untrusted, Cloudsmith won't fetch a newer version of a package from that registry if a local version already exists. A higher version number on the public registry doesn't win. An attacker publishing 

. The attack surface closes at configuration, not after detection.

Cloudsmith evaluates every package against the 

 database (which aggregates records from GitHub Security Advisories, the OpenSSF Malicious Packages Project, the NVD, and language-specific datasets), 

 for real-world exploitability, and SPDX license metadata. For Docker images, Cloudsmith generates a full software bill of materials (

The part that separates this from point-in-time scanning: Cloudsmith polls its intelligence sources continuously. When a new advisory is published, Cloudsmith checks every package already in your repositories, not just what arrives after the disclosure. A package that cleared evaluation yesterday can be quarantined today, automatically, without anyone manually triggering a re-scan.

This is the enforcement model that most registries and scanners don't offer. A scan at ingestion tells you whether a package was safe when it arrived. Continuous re-evaluation tells you whether it's still safe now. When new malware signatures drop, or a previously low-severity vulnerability gets weaponized and its EPSS score spikes, Cloudsmith checks your inventory for a match and triggers policy enforcement.

Policy evaluation also runs at package promotion events and when new packages are published, and on a fallback schedule if nothing else has changed.

Cloudsmith's approach to policy management is built on Open Policy Agent (

), the same open standard used in Kubernetes environments and across the cloud-native ecosystem. Policies are written as policy as code in Rego and managed through Cloudsmith's 

, giving you full lifecycle management of rules, precedence, enabled state, and actions as code, all version-controlled alongside the rest of your infrastructure.

Cloudsmith puts policy enforcement, malicious package detection, vulnerability matching, and license governance in one platform, under one policy model. That means policy as code, using OPA and Rego, with structured exception workflows, instead of binary allow/block toggles spread across multiple UIs.

This normalizes package metadata across 30-plus formats, so a single policy as code definition, written in Rego, applies consistently whether you're managing npm packages, Docker images, Maven artifacts, or Python wheels. Policy input includes CVSS scores, EPSS scores, OSV malware identifiers, license type, fixed versions, repository names, uploader identity, build-time tags, and for Docker images, the full component-level SBOM.

Cloudsmith provides policy templates and a 

 to accelerate policy authoring. Every policy evaluation creates a decision log record, which includes the input data, what the policy matched, and which actions ran, giving you the traceability to audit decisions and roll back when needed.

Creating a baseline policy set for a dependency firewall

Four policies form a strong starting point. Each addresses a distinct risk; together they cover the primary ways malicious or non-compliant packages enter a production environment.

 Packages carrying an OSV malware identifier get quarantined across every repository in the workspace – current and future. The coverage is immediate and unconditional, and the signal quality is high enough that there's almost no argument against this policy. Apply it globally, set its precedence to #0 (first), and move on.

 A cooldown is a timed hold for newly fetched packages from public registries, enforced at the index level. Cloudsmith won't download or cache packages within the cooldown window, making them unavailable to build tools. Compromise attacks on trusted packages are typically identified within days of publication. A three- to seven-day hold gives threat intelligence time to catch up before a package reaches a pipeline. When a malware identifier matches during the window, the package gets quarantined. When a package clears the window clean, it downloads, caches, and becomes available automatically. Clean cases need no human decision.

Cloudsmith exposes both the CVSS score and the fixed version in policy input metadata, so policies can distinguish between risk profiles rather than applying a single blanket rule. A package with a 

 warrants a different response than one with the same score and 

. Blocking a team where no remediation path exists creates friction without reducing risk. 

 packages (e.g., GPL, AGPL) entering through transitive dependencies create legal exposure that surfaces late and expensively. A license policy flags or quarantines non-compliant license types at ingestion. Teams that catch a GPL dependency at the boundary have a straightforward remediation path. Teams that discover it during a security audit or acquisition due diligence do not.

When policies match a package, they take actions: quarantine, tag, or both. Tags trigger webhooks, which route to Slack notifications, Jira tickets, CI/CD events, or any supported alerting tool. Add a tag action to every policy. It makes enforcement decisions visible and actionable outside the Cloudsmith UI.

Before adding quarantine actions to a live policy, Cloudsmith's 

 runs the policy against your existing repository contents without creating decision log entries or touching any live package state. The response shows which packages would match, the reasons, and what actions would be taken.

This is how you measure blast radius before enforcement. A policy that looks narrow on paper can match more packages than expected when run against a production repository. Simulation lets you find that out before a build breaks. The recommended path: start policies with tag-only actions. Use decision logs to review what matched, assess signal quality, and surface false positives. When you're confident, add the quarantine action to the existing policy. The Rego logic stays the same. Moving from reporting to enforcement is a configuration change, not a rewrite.

Engineers trying to hit delivery commitments route around security controls that slow pipelines, generate unexplained blocks, or require manual steps outside normal workflows. A dependency firewall handles this by making the secure path the fast path: packages that evaluate clean pass through without any additional steps in the developer's workflow.

When a developer requests a specific package version that's in quarantine, they receive a 

 response with policy context in the body. The message is configurable: you set it in the policy description. Point developers to the exemption workflow, the right Slack channel, or a PR template for requesting a waiver. They know what caused the block and have a clear path forward.

When using a cooldown policy and a developer requests the latest version of a package with a quarantined release, Cloudsmith removes the quarantined version from the repository index and serves the most recent policy-compliant version.

Security policies need a structured exception path. Without one, practitioners route around controls entirely, which defeats the purpose of having them.

The recommended approach uses an allowlist-style 

 policy that marks specific packages as approved and releases them from quarantine. Developers enter the exemption flow through the 

 response, which points them to the process. From there, a GitOps workflow handles the rest: a developer raises a pull request to add their required package to the allowlist; the security team reviews and approves; automation merges the change, re-evaluates the policy, and sets the package to available. The PR review is the only manual intervention required for this process.

Git records every decision with a person, a timestamp, and a reason. The audit trail exists outside the platform, changes are reversible, and your CI tooling handles the reconciliation.

Decision logs record every policy evaluation: the exact input data used, what the policy matched, and which actions were taken. The 

 field contains the data that drove the decision, which is useful when you need to explain a quarantine to an auditor, a team lead, or a compliance reviewer. If you query for all policy matches in the last seven days and you get a concrete, reportable picture of your threat landscape.

Webhooks fire on quarantine events, tag additions, or releases from quarantine. Configure them to route notifications to your alerting tools of choice (Slack, Jira, etc.) to ensure the right people get the information they need without manual polling. Manage webhooks through infrastructure as code at the repository level to ensure every repository carries the same alerting setup.

Establishing a dependency firewall with Cloudsmith starts with controlled ingestion. Enable the malware block globally and put it into enforcement. Add cooldown, vulnerability threshold, and license policies with tag-only actions first. Use the simulation API to understand blast radius. Review decision logs to assess signal quality. When you're confident in what each policy matches, change the action from tag to quarantine. The policy logic doesn't change.

Teams that add Cloudsmith alongside Snyk, Wiz, or other security and scanning tools get pre-ingestion control where they didn't have it before and without replacing the scanning that already works. The packages that reach your downstream tools already clear evaluation at the registry. Your existing scanning layer gets cleaner input. And when new threat intelligence drops, Cloudsmith re-evaluates everything in your repositories automatically. Threat intelligence updates continuously, and with Cloudsmith enforcement does too.

 to see how a Cloudsmith dependency firewall fits alongside your current stack.

Dependency Firewall

How to use Cloudsmith as a dependency firewall

The Cloudsmith platform improved with each new 

 in Q2 of 2026. Our focus on constant innovation comes out in the new features we shipped, and the major and minor improvements we made to the platform that help users better manage artifact pipelines at enterprise scale.

In case you missed the changelogs as they came out, here’s a quick roundup of what changed over the past quarter.

Branded distribution of software components with Cloudsmith Private Broadcasts

Private Broadcasts give teams a branded distribution portal with access controlled by entitlement tokens. The two new capabilities increase Broadcasts value to users. Package Groups let you batch packages by format and name, so end users browsing a repository containing multiple package versions see a clean, organized structure rather than a flat list of files. Search syntax support for access links means you can pre-filter what a shared link shows.

Private Broadcasts

Large engineering organizations typically need to balance two things that pull in opposite directions: developers want a single place to pull every package they need, and platform teams need fine-grained control over who can publish or promote to any given repository.

Connected repositories are the solution. A source repository can aggregate packages from multiple connected repositories with no indexing delay. When a shared library lands in a connected repo, it's immediately visible to every team consuming the source. Priority-based resolution handles the case where the same package version exists in multiple places. Teams don't need to know anything about the underlying repository structure – they pull from one location, and Cloudsmith handles the rest.

Inherited upstreams extend this further. If your shared library repository points to Maven Central or PyPI, the teams consuming the source repo get access to those public packages automatically, through the same pull point, without separate trust configuration.

Connected repositories are now available for Maven, Docker, Python, npm, Go, Cargo (Rust), NuGet, Helm, Conda, and Conan.

What’s new in Cloudsmith’s Terraform provider

Our team improved our Terraform provider this quarter, logging two new capabilities for managing Cloudsmith at scale.

Cloudsmith's Terraform provider (v0.0.75) now covers the full policy lifecycle. Four new constructs let you define quarantine rules, tag cleanup policies, and cooldown policies in HCL, version them in Git, and apply them through standard 

 includes a working example module that creates a quarantine-on-missing-tag policy, a tag cleanup policy, and a cooldown policy in one block.

Create and manage connected repositories with Terraform

I mentioned connected repositories above, and users can now manage those via Terraform. The new 

 resource lets you declare repository topology in code. That configuration then lives in version control alongside the repositories themselves, which makes it auditable, diffable, and deployable through the same pipelines as everything else.

Automatically authenticate Docker Hub and DHI upstreams

Cloudsmith Blog

Everything Cloudsmith shipped in Q3 2026

How continuous risk detection replaces point-in-time scans with real-time monitoring

How Cloudsmith security features work: policy, risk detection, and the audit trail

Simplify repository structure with connected repositories

How to use Cloudsmith as a dependency firewall

What Cloudsmith shipped in Q2 2026

A dependency firewall gives your scanner better inputs

Dependency attacks start before your scanner runs

Cloudsmith credentials are now detectable by GitHub Secret Scanning

How Cloudsmith's cooldown policies stop newly published packages without disrupting your builds

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

How artifact management closes the CRA compliance gaps that leave you exposed