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

Attackers only need one weak point in your supply chain to disrupt your builds, so security teams have to take precautions against every threat and advisory that comes out. Most teams no longer ask whether a software supply chain attack will affect them. They ask whether the right controls are already in place when it does.

Artifact management is the one layer every package passes through

Proactive defensive measures give teams the best opportunity to neutralize supply chain attacks before they strike, or to catch them early, before they can do significant damage. The artifact registry is the ideal location to enforce security policy because it provides a control point at ingestion for incoming packages. Because every stage of the development process pulls packages from the same artifact registry, policy decisions made at ingestion apply to developer workstations, CI builds, and production deployments.

A package cleared at ingestion enters downstream stages already vetted against your policies. A package blocked at ingestion never enters the build environment in the first place.

The attack model evolved but security controls didn’t

Attacks are more sophisticated now, targeting points earlier in the development process. Traditional malware, like ransomware, targeted individual machines and impacted them in an obvious way. Endpoint tools that scan files before execution evolved to combat this attack vector, and much of today’s security stack assumes this attack model as the default.

Supply chain attackers don’t need to target a specific machine. They compromise the actual software supply chain and what bad actors are trying to achieve through these attacks is much less transparent. Oftentimes malware exfiltrates sensitive information so that attackers can compromise additional systems. For example, Shai-Hulud spread by stealing npm, GitHub, and cloud tokens. Other times, the goal is to utilize the resources of a compromised machine for activities like cryptomining. These attacks are subtle by design and can delete evidence of their existence before you realize you’ve been compromised (like the Shai-Hulud variant that hit 

Attackers increasingly gain entry through the open source packages you depend on, and most teams rely on open source software to build the bulk of their applications. When an application uses hundreds or thousands of dependencies, attackers only need to compromise one to gain access.

When installing a package means running it

Beginning in September 2025, Shai-Hulud turned install-time malware into a self-propagating worm. TeamPCP, the group behind the Shai-Hulud attacks, open-sourced the code for the worm in May 2026, which 

gave rise to the Miasma and Hades versions

 and spread this attack type to PyPI, RubyGems, and other open source ecosystems.

These worm attacks rely on code that runs automatically at install time (e.g., npm preinstall / postinstall hooks, and equivalent build hooks in other affected ecosystems), so the malicious payload runs the moment a developer or CI runner installs the package.

Note: npm 12, released in July 2026, turns off install scripts by default. However, this feature only works with upgraded and configured versions of npm, and allowlists can re-enable install scripts. It’s also an ecosystem-specific solution, where a registry-level policy applies to every package that gets pulled in.

At that point, downstream scans of the build output or container image aren’t able to see the compromised package. Further, for newly released packages an advisory may not exist yet for the scanner to evaluate against. The critical point here is that this attack model exposes architectural gaps in security posture, not tooling failures. Scanners remain a critical and useful tool; however, they’re not designed to evaluate install-time code execution. As a result, controlling package ingestion is critical for defending against this type of attack. When installing a package means running its code, choosing a version means granting that code execution rights, so package selection becomes a trust decision.

Beyond malware: vulnerability and license risk

The Shai-Hulud class of attacks garners headlines, but software supply chain challenges exist beyond malware. Different organizations have different tolerances for package vulnerability risk signals, like CVSS severity, EPSS exploit probability, or a listing in CISA’s KEV catalog. Similarly, package licensing can have a significant impact on the legality and economic viability of using certain packages. The last thing teams want to happen is to get to the deploy stage only to find a critical vulnerability, or a license issue. Vetting package properties at the registry prevents issues from impacting downstream workflows.

AI agents multiply the dependencies that no one reviews

AI exacerbates the dependency problem. AI agents work at machine speed and can do so around the clock. These tools generate high volumes of code with more dependencies than humans have the capacity to review. Many of these are transitive dependencies and developers may not have visibility into these package decisions, especially with the increased volume of overall dependencies. This is another facet of package trust that can be dealt with by using the artifact registry as a control point for evaluating these packages at ingestion.

Activating the artifact registry as software supply chain control point

If the artifact registry is the ideal control point for the software supply chain, what does that control actually look like?

 allows you to enforce security policy before problematic packages reach your build environment. Policy enforcement is automatic and can be set once at the Cloudsmith workspace level and applied to every pipeline and developer that pulls from it. You can scope policy at the repo level as well, so any repos that require additional protection or leeway can be set up according to your needs.

The general shape of a dependency firewall includes:

: This one is straightforward. Packages with a known 

: This is a configurable, forced hold on newly released packages. Teams typically opt for 3–7 days, as most malicious packages are identified within days (or hours) of publication. A cooldown policy provides protection during the exposure window between when a package is published and when a threat advisory typically emerges.

: Writing policies around CVSS, EPSS, and KEV data. Every company has different thresholds for what they are willing to use, and that may change across environments (e.g., dev, test, prod). Cloudsmith’s policy management lets you write policy-as-code so you can have granular control over what gets in and what gets blocked.

: Write policies that check license type to protect your software from future licensing issues by limiting the types of licenses your developers can consume from the outset. For example, if you want to block copyleft AGPL licenses in distributed software.

The artifact registry touches the entire software development lifecycle. Traditionally, it was a tool for storing artifacts and packages, but its ability to enforce policy at ingestion makes it the ideal control point for software development. Preventing compromised packages from entering your environment denies attackers the opportunity to inflict damage on your systems. Clearing packages at the registry layer also ensures that downstream workflows and processes, like scanning, have safer inputs.

Every control described above is a policy you can write once and enforce across every repo. Learn more about 

Jason Myers

Technical Content Marketer

Why enforce supply chain security at the artifact registry 

Cloudsmith now supports hosting public and private Nix binary caches. Teams that use Nix and NixOS can point existing 

 workflows at Cloudsmith without any additional tooling.

(Note: Nix format support is currently in Early Access.)

Nix builds work differently from most package ecosystems. Initiating a build in Nix begins with an evaluation of all the inputs that go into the build. This includes source code, dependencies, and build instructions, and each item gets hashed. The evaluation output is a derivation (a 

 file), which is a build recipe that describes what’s in the build. Nix then hashes the derivation to compute the package’s store path. Because downloading a pre-built version is faster than building from source, Nix then asks its substituters (remote binary caches like the default 

) whether that store path already exists. If it does and is signed by a key that Nix trusts, then Nix will download it. If it doesn’t exist, Nix builds it from scratch.

 packages from the public cache, but their own builds require a private binary cache, which is typically self-hosted. Relying on the public cache means accepting availability and bandwidth limits, which may not meet the needs of compliance-focused teams. Self-hosting a private cache with 

 or S3 means patching, scaling, and on-call duty for infrastructure that only serves packages.

 for Nix release channels. You must configure a separate upstream for each channel you want to use.

The first time you request a store path that Cloudsmith doesn’t have, it fetches the package from the configured NixOS channel, caches it, and serves it. Subsequent pulls are served from Cloudsmith’s cache, so builds are fast and keep working during a 

You can also push new Nix builds to a Cloudsmith repo, which then functions as a private Nix binary cache, but without the overhead tax of self-hosting.

Signing and verifying Nix packages in Cloudsmith

Where other ecosystems use package name and version number to identify packages, Nix uses a cryptographic hash to identify and verify them. Cloudsmith signs each package’s 

 with the repository’s ED25519 key on every read, and Nix verifies that signature against trusted keys. Because signing happens on every read rather than once at upload, key rotation takes effect immediately, with no backlog of packages to re-sign, and multiple keys can be active and signing simultaneously.

To get started using Nix with Cloudsmith, you can create a dedicated Nix repository. Add that repo to your Nix 

 list, and the repository’s public key to 

. This configuration means Nix treats Cloudsmith like cache.nixos.org. To proxy a public channel, add that as an upstream to the repo.

For private repos, authenticate with an entitlement token in a 

 file. Push Nix packages you build locally to your Cloudsmith Nix repo using 

 flag because locally built packages are unsigned and Cloudsmith handles signing on read.

For detailed setup instructions, see our 

Cloudsmith allows you to consolidate cached Nix packages in a single, cloud-native environment with multi-format repositories. Teams no longer rely on public cache availability, or pay the operational tax of self-hosting. Upstreams cache public channel packages in Cloudsmith for fast, reliable pulls.

Nix packages often sit outside the access controls and audit logging that cover the rest of your software supply chain. Bringing Nix into a Cloudsmith workspace, with 30+ formats in multi-format repositories, lets you govern Nix packages with the same access controls, entitlement tokens, and audit logs that you use on the rest of your software supply chain.

 for more information about using Nix in Cloudsmith.

Cloudsmith expands support to Nix

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.

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 

Cloudsmith Blog

Why enforce supply chain security at the artifact registry

Cloudsmith expands support to Nix

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