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

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? 

Jason Myers

Technical Content Marketer

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

 upstream without having to supply credentials. Cloudsmith authenticates these upstreams using a managed organization access token (OAT), and authenticated requests carry a higher rate limit than anonymous access, which matters for teams pulling frequently from public Docker registries in CI/CD.

A pre-configured DHI upstream is also available, so you can start proxying and caching images from the DHI Community tier immediately with no setup. To access the DHI Select or Enterprise tiers, configure the DHI registry as a private upstream with your own Docker Hub credentials. Note that workspace names are shared with Docker to attribute usage when the Cloudsmith-managed token is in use.

Align npm dist-tags with upstream registries

Cloudsmith's default behavior assigns the latest dist-tag to the package with the highest semantic version number. For maintainers that explicitly point 

 at a specific release for compatibility reasons, Cloudsmith’s semantic version default can produce a wrong result.

 repository setting overrides the semantic version number default. When enabled, Cloudsmith checks the upstream registry's latest tag and applies it as an override, but only if that version is actually available to the client. If a cooldown policy or another rule filters that version from the index, Cloudsmith falls back to the semantically highest available release.

Teams publishing to both npmjs.com and Cloudsmith, or using tag-based resolution (

) in their pipelines, can now mirror upstream behavior precisely. 

Recover deleted packages within a 7-day restoration window

Cloudsmith has always retained deleted packages for seven days before permanent removal. Restoring one, however, required contacting support. The new "Recently deleted packages" view in the web app lets teams restore packages directly. Permanent deletion before the window expires is also available if needed. The API now supports both operations. 

Column visibility, column order, and table density are now configurable across key tables in the web app and settings persist per table. The compact density option fits more rows on screen without switching views or resizing windows. See the personalization 

Upstream logs are now available in the web app. Each upstream shows successful requests from the last 12 hours and failed requests from the last 24 hours. When an upstream breaks, the log tells you what went wrong and when, without needing to file a support request.

Teams with UK data residency requirements can now store artifacts on UK infrastructure. Select London as your storage region when creating a new repository, or transfer an existing repository via its Settings page. 

The Cloudsmith CircleCI Orb now reaches feature parity with the GitHub Actions and Azure DevOps integrations. Three meaningful changes shipped in v2.

 step exchanges short-lived tokens at runtime, eliminating the need to store long-lived API keys in CircleCI environment variables.

A zipapp-based CLI install. Rather than relying on 

 and whatever Python environment the runner provides, the orb downloads a self-contained zipapp from 

. Faster, more consistent, no environment dependency.

Full CLI access. Previous versions exposed a subset of CLI functionality through orb wrappers. v2 installs the CLI directly, so any CLI command is available from within run steps.

 command and introduced a few potential breaking changes. Review the 

Cloudsmith now proxies and caches Alpine Linux and Wolfi packages from their public mirrors, merging them into a single 

 signed with your repository's RSA key. Build environments trust one source for all APK dependencies without separate trust configuration per registry.

Wolfi doesn't use versioned branches, and public packages typically drop off the upstream after 12 months. Cloudsmith caches pulled Wolfi packages permanently, so builds that depend on packages no longer available upstream remain stable. 

Users can now attach custom key-value metadata, stored as arbitrary JSON, to any package via the API or CLI. Contextual data that belongs with the artifact but doesn't fit in tags now has a proper home directly alongside it.

Once attached, metadata is searchable via the package search filter using the 

 field, and usable in policy-as-code matching logic. The web app supports viewing and searching existing metadata; create, update, and delete operations require the API or CLI. 

Vulnerability detection now covers ecosystem-native OSV advisories

Cloudsmith's vulnerability scanning already matches packages against OSV advisories using SemVer-based version ranges. We extended that capability to advisories that use native ecosystem version formats that don't follow SemVer conventions.

If you have active vulnerability policies using the 

 dataset, expect more policy matches now that Cloudsmith has more comprehensive support for version range format differences. Review the 

 entry for the full list of covered ecosystems.

More events now trigger policy evaluations

Two new triggers join the existing set of events that initiate policy evaluations. One, any policy create, edit, or delete operation now immediately re-evaluates affected packages against the updated configuration. Two, a default, fallback evaluation runs every 12 hours. This runs against any packages that were not evaluated in the previous 12-hour window. These triggers apply to policy-as-code configurations only.

Cooldown policies now enforce at the index level

Cooldown policy enforcement is now done at the repository index level. The policy filters non-compliant versions before the package manager sees them. Builds resolve cleanly to the first compliant version available. Security teams configure one policy at the repository level, and it applies consistently across every consumer of that registry. Available in early access for Python and npm.

Cooldown policies

Multi-select package actions now include delete. Select up to 100 packages and remove them in one operation. Deleted packages land in the recently deleted view for a seven-day recovery window.

Set up and monitor upstreams more effectively

What Cloudsmith shipped in Q2 2026

Scanning for malicious packages at deployment catches issues already inside your environment. Scanning at the pull request catches what your CI pipeline already ran. If security controls don’t see a malicious package until after ingestion, it already has multiple chances to execute.

This is an architecture problem that requires an architectural answer. A dependency firewall is that answer. It’s a security posture that places guardrails between your development environment and public registries, evaluating what enters before any build runs.

How malicious packages enter your build environment without inspection

Build tools connecting directly to public registries like 

, and packages arriving as requested is a common approach to open source software consumption. When scanning runs at the pull request, in the pipeline, or at deployment, the package is already inside your environment.

) tools identify known vulnerabilities in packages already present in a codebase. That's genuinely useful. But even with the best scanners, an architectural gap exists between ingestion and where the first scanner sits. Establishing a control point in that gap allows teams to better govern the packages that enter their environments.

Two patterns produce this gap consistently.

The first is when no artifact management exists at all and developers pull directly from public registries. Teams can’t implement security controls because the layer necessary to do so isn’t in place.

The second, and it’s more common than most organizations realize, is when an existing artifact management tool handles the storage of software artifacts but enforces no security controls on the consumption of those artifacts (for example: AWS CodeArtifact or GitHub).

A third pattern is emerging due to the use of AI coding tools.

These agents generate code that expands the attack surface faster than most security programs have adjusted for. Tools like Cursor, AI-assisted editors, and LLM-powered agents recommend and install packages as a normal part of their workflow. Teams need governance that can match the pace of AI-powered development.

Developers tend to accept those recommendations without the scrutiny they'd apply to a manual dependency addition. The packages arrive through the same registries and the same pipelines as they would with manually-written code, but the human review step between "

Modern attacks execute before the scanner runs

The latest supply chain compromises exploit trusted open source packages. The 

 attacks succeeded because they targeted specific packages developers already trusted and executed payloads at install time – before any scanner ran.

Cloudsmith's analysis of 2025 OSV.dev data, comparing when malicious versions were published to npm against when OSV flagged them, shows that 

99 percent of npm package compromise attacks are identified within 72 hours of publication

. A package scanned within that exposure window looks clean because no malware identifier exists yet. By the time the community flags the threat, pipelines are already running it.

Scans are snapshots – threat intelligence isn't

There's a second failure mode related to scanning that plays out more slowly. A package enters your environment, the scanner runs, nothing matches, and it's marked clean. That evaluation is correct at that moment because no known vulnerability exists. Then six months later, a researcher discloses a critical CVE. Nothing triggers a re-evaluation, so the original point-in-time scan remains the most recent one and the package is still in production.

. That package existed in production codebases for years before threat intelligence identified the vulnerability. The problem in cases like this is when you treat a one-time evaluation at the boundary as permanent clearance.

New advisories arrive constantly for packages that evaluate as clean at ingest. A scanner that runs once, when a package first arrives, doesn't protect against what threat researchers find next month or next year. The scan result ages out the moment new intelligence contradicts it.

That said, scanning remains essential. But the fluid nature of supply chain threats, packages that evaluate as clean at ingest and become risks as new intelligence emerges, reveals a gap that point-in-time evaluation can't close on its own. Addressing it means supplementing scanning with controls that operate earlier in the process, before packages enter an environment where they can execute.

The control point that doesn't depend on developer behavior

A dependency firewall addresses both failure modes described above by changing where and when evaluation happens. The first is early detection at the boundary: identifying threatening or malicious dependencies before they enter your environment, rather than after they had the chance to execute. The second is ongoing assessment: unlike a scanner that runs once and treats the result as permanent, this posture evaluates continuously as new threat intelligence arrives. A package that cleared evaluation at ingest doesn't remain cleared by default; it remains cleared only if current intelligence still supports that conclusion.

Developers start their work with packages that clear those guardrails, meaning the inputs to their work are more likely to be secure from the start. Vulnerabilities, threats, and license flags caught at the boundary save considerable rework compared to discovering the same issues in a PR review, a pipeline scan, or a post-incident forensic report.

For the vast majority of packages that clear evaluation, the process is entirely transparent and frictionless to developers. When friction occurs, like disabled scanner plugins, skipped linting rules, and manual approval workflows, developers create workarounds. Developers don’t need to bypass a control they don’t interact with. Compliance that relies on structural enforcement is more reliable than manual, behavior-based approaches.

For security and DevSecOps teams, the value is consistency at scale. Every developer, every AI agent, every pipeline, and every team in the organization hits the same guardrails. Policy applies universally and automatically, closing the gap between what policy says and what enforcement carries out.

A dependency firewall posture doesn't replace the scanning you already have. It moves the trust decision to the ingestion boundary, so your team uses safe, evaluated packages before anyone writes a line of code.

For a practical guide to building a dependency firewall, covering controlled ingestion, continuous policy evaluation, and the OPA-backed policy engine, read 

A dependency firewall gives your scanner better inputs

, you're not just installing the requested package. You're also pulling in every transitive dependency in the package’s dependency graph. Many of these are packages you didn’t consciously choose, from maintainers you don’t know, including code that executes automatically before any build pipeline step runs. An average React application can pull in over 900 dependencies, most of which arrive automatically, not by selective choice.

That's the architecture of modern software development. Reusing open source packages at scale makes it possible to ship complex applications that meet the high expectation of users without rebuilding foundational infrastructure from scratch. But the security model currently in use wasn’t designed to address the exposures created by reusing open source packages.

A leaked npm publish key makes that exposure visible. The credential isn't the problem, rather it's what reveals the gap between where organizations believe enforcement happens and where it actually happens.

The evolving nature of software development and the rise of security supply chain attacks changed who's paying attention to this gap. Security teams don't need to experience an incident to start conversations around their supply chain. The 

-style worms, and near-misses reported by high-profile engineering organizations present a threat environment that makes industry signals a catalyst for change. So, while the trigger is different, the gap is the same.

It may seem like a leaked npm key is a credential rotation problem and not a supply chain problem. Here’s how we get from key to attack.

No matter how a publish key gets exposed, whether that’s in a CI log, a repository that was briefly public, or a secret rotation that wasn't fully completed, that key grants write access to one or more packages on the public npm registry. Write access means the ability to publish a new version.

The attacker publishes a version that looks legitimate: same package name, incremented version number, valid metadata. In the axios compromise, the malicious versions were tagged 

. Consumers pulling the latest version get the malicious one automatically on their next install.

Here's where the transitive dependency becomes the attack surface. Most downstream consumers aren't pulling the compromised package directly. They're pulling a framework that depends on a tool that depends on the package. No developer makes a conscious choice to install it. The package manager resolves the dependency graph and pulls everything in. In the axios case, the attackers added a new software dependency named 

 which serves as a legitimate encryption and hashing utility. The associated npm 

 script runs automatically during installation. The malicious code executed before any build step, before any scanner ran, before anyone knew the package arrived.

By the time a developer or CI job completes 

, attack code can exfiltrate credentials, establish remote access, and take steps to avoid detection.

The credential leak opened the door. The artifact pipeline, specifically, the absence of an interception point between a package being requested and when the package is executed. This is precisely where the adversary makes an impact.

Investing in security tooling can create a sense of false confidence. Especially as organizations grow, adapting to nuanced changes in the software development process at scale can be challenging. So, this confidence makes sense: they have application security scanning, CI/CD pipeline scanning, and endpoint detection. These are good tools, but where they sit in the timeline is the problem.

 analyze the code your team wrote. SAST tools like Checkmarx, Veracode, Snyk, and Semgrep, do serious work and find real vulnerabilities. They analyze source code before the build runs. The SAST tool already finished its pass by the time your build system is pulling packages from npm. It has no visibility into the dependency tree. So, a compromised transitive dependency gets pulled in, its installation script executes, and the SAST report comes back clean because the SAST tool never saw the dependency tree.

 runs after the package manager pulls the requested packages. In npm, 

 scripts run during download, not during execution. When the malicious code runs at install time and your pipeline scanner runs afterward, then it's checking the pool for contaminants after the swimmers have been in it for an hour. The tool works correctly and you get a clean report, but that’s because the timing is wrong once again. The attacker already has your credentials.

 is excellent at detecting anomalous behavior once code is running, like suspicious network traffic, unusual file operations, and credential access patterns. CrowdStrike, your EDR tooling, etc., catch these things, but they're reactive by design. By the time your endpoint detection notices the suspicious outbound connection, the credentials are already gone. Detection at minute three doesn't help much when the exfiltration happened at minute one.

This is the architecture of the standard security model, and it has a structural blind spot: every control point operates after ingestion. Code downloads and executes before any of those controls see it. That's not a problem you solve by adding another scanner at a later stage in the same pipeline. Adding more tooling downstream of the gap doesn't close the gap.

Consider a fire department. They detect and respond to fires. We need fire departments. But we also need a fire code that prevents fires from starting. The fire code is embedded in the design and operation of buildings; it’s invisible because it's foundational. Fire response and prevention are different things, and both matter. The difference is that only one of them stops the problem before it starts.

The artifact registry functions like the fire code. It’s where that kind of foundational control can actually live for software supply chains. It sits at the boundary between untrusted software, like everything on the public internet, and your trusted environment. Every package your developers and build systems consume passes through it. That makes it the one place in the entire delivery pipeline where enforcement can happen before code downloads, installation scripts run, or anything executes.

Enforcement at the trust boundary changes the attack timeline entirely. A compromised version of a package previously marked as safe gets evaluated against policy before it enters the environment, so doesn’t reach your environment at all. Policy stops being advisory ("

this package is risky, here's a dashboard entry

") and instead becomes an automated enforcement control ("

this package is not entering this environment for this reason

A few things become possible at the artifact layer that aren't possible anywhere downstream:

 A package that was clean when it arrived six months ago and has a new CVE or a threat intelligence flag today gets re-evaluated without manual action. Build-time scanning doesn't revisit what's already in the environment, but an enforcement layer at ingestion can.

 Most modern supply chain attacks don't begin with a known vulnerability. They begin with compromised open source maintainers. These threats don't appear in a common vulnerabilities feed and instead rely on scanning the open source upstream registries (PyPI, npm, Packagist, etc.) for unwanted code changes (

) using a database like OSV.dev. . This data is actionable at the artifact layer, before the package is introduced into any developer builds.

An audit trail that answers the incident question.

" should be answerable from a single system of record. An enforcement layer at ingestion is that record – what entered, when, under what policy state, with what provenance. Not a multi-tool investigation across disconnected logs.

The instinctive response to a supply chain incident is to add tooling. Buy the additional security module. Enable scanning at another pipeline stage. Each addition addresses a visible gap and each one is a reasonable decision in isolation.

The accumulated result is a different problem: a patchwork of controls with seams between them. Each tool has its own configuration requirements, its own maintenance cycle, its own expertise to operate correctly. The security stack grows in response to incidents until nobody fully understands how it fits together or what to do when something falls through a seam. The operational burden of the stack becomes its own risk.

This pattern shows up consistently in teams that started with a repository and added security on top: fragmented coverage, high maintenance overhead, and a circumvention problem. When authentication against an internal proxy creates enough friction, developers route around it and pull directly from the public registry. A control that gets bypassed at scale is worse than no control because it creates the appearance of coverage while the actual exposure grows.

The architectural distinction matters here. Controls built into the artifact layer from the foundation behave differently from controls added on top of a repository designed for something else. The former is simply infrastructure while the latter is configuration layered on infrastructure with a different original purpose. Those are two different approaches that behave differently under pressure.

Teams choosing a platform built for supply chain security describe making that choice explicitly to avoid assembling the capability from components. The assembly works, until it doesn't. The seams are where attacks succeed.

The leaked npm key is almost never the actual exposure. It's the event that made the exposure visible.

The supply chain incident – the credential, the flagged package, the build that broke in a way nobody could explain quickly – functions as a diagnostic. It reveals where enforcement actually lives in the pipeline, which is almost always different from where teams assumed it lived.

The useful question that comes out of the diagnostic: where in your pipeline does enforcement actually happen? Does it occur before packages enter the environment, or after?

Cloudsmith Blog

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

EU CRA compliance: building a defensible posture with Cloudsmith

AI is breaking your artifact governance – and not by writing bad code

What is a package cooldown policy? How to prevent malicious dependencies from entering your environment.