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 an OPA-backed policy engine, from initial configuration through to enforcement.
Cloudsmith upstreams 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.
Upstream trust 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 acme-utils@9.9.0 to npm can't shadow your internal acme-utils@1.2.0. The attack surface closes at configuration, not after detection.
Cloudsmith evaluates every package against the OSV database (which aggregates records from GitHub Security Advisories, the OpenSSF Malicious Packages Project, the NVD, and language-specific datasets), EPSS scores from FIRST for real-world exploitability, and SPDX license metadata. For Docker images, Cloudsmith generates a full software bill of materials (SBOM) automatically at publish time.
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 policy engine runs on Open Policy Agent (OPA), the same open standard used in Kubernetes environments and across the cloud-native ecosystem. Policies are written in Rego and managed through Cloudsmith's Terraform provider, 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 in OPA/Rego with structured exception workflows, instead of binary allow/block toggles spread across multiple UIs.
The engine normalizes package metadata across 30-plus formats, so a single Rego policy 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 Rego recipe cookbook 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.
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.
Block malware globally. 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.
Hold new packages with a cooldown policy. 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.
Set a vulnerability threshold. 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 CVSS score of 9.5 and a patch available warrants a different response than one with the same score and no fix yet. Blocking a team where no remediation path exists creates friction without reducing risk.
Add license policies. Copyleft 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 simulation API 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 403 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 exemption policy that marks specific packages as approved and releases them from quarantine. Developers enter the exemption flow through the 403 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 policy_input 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.
Book time with the team to see how a Cloudsmith dependency firewall fits alongside your current stack.
