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

If time’s just a construct of human perception, does that mean all package managers interpret time differently? And what does that have to do with cooldown policies?

 help protect your software supply chain from zero-hour threats by holding packages for a set period of time to allow threat intelligence to catch up. But where does a package get held, and how does that impact how you configure your cooldown policy?

You can implement cooldown controls on either the client-side and on the server-side. This post highlights the difference between where the cooldown policy lives, and how that impacts your ability to implement and scale that policy. We’ll explore how they can be defined differently in various ecosystem package managers, and why all this flexibility actually might hinder (not help) the security posture of our software supply chain.

JavaScript developers most commonly pull 

 registry. The most popular Javascript package manager, 

, included the concept of a minimum release age (

 represents the number of days a dev must wait before they can receive a newly-released software dependency, as a single number unit. However, not all JavaScript package managers work the same way. The 

 client, for example, chose a completely different unit of time. We can see that 

 specifically treats cooldown (within the 

 registry also introduced the cooldown field 

) represents the configured cooldown period in 

) supports days and weeks in a more humanly-readable approach, similar to 

This leaves JavaScript teams in a situation where securing a polyglot Node.js environment requires a math degree and a cheat sheet! If your team wants to implement a cooldown policy and uses a mix of 

 (as only a few examples), you need to translate a basic 48-hour quarantine policy into days, minutes, seconds, and human-readable string tags simultaneously. This arbitrary config drift is more than a tedious task, it’s a genuine security liability. When security policies are this fragmented across tools running in the same language ecosystem, misconfigurations are more likely.

The Python ecosystem is similar to JavaScript when it comes to representations of time. Astral’s 

 package manager provided cooldown controls in 

. It uses relative durations, but also supports a bunch of other duration formats (inside 

The result in the Python ecosystem is a case of duplicate standards. While more modern, lightning-fast tools like 

 embrace highly flexible relative text strings, standard 

 leans heavily into the rigid syntax of ISO 8601. For security teams trying to enforce a consistent supply chain guardrail across a variety of developer endpoints and pipelines, this introduces a layer of translation friction. We aren't simply configuring the time window, we’re also managing entirely different syntactical philosophies from what was discussed in the JavaScript ecosystem - just to keep a volatile package at bay.

Package Managers with no support for Cooldown Policies

And that brings us to the lack of support for cooldown policies in many other popular language ecosystems. As of the time of writing, languages like 

 provide client-side support for cooldown controls in any direct configuration field.

In the absence of built-in cooldowns, devs without server-side or private artifact repository solutions rely on strict version pinning as their primary line of defence. But version pinning is a double-edged sword:

Pinning to an older version should (generally speaking) keep you safe from a zero-day compromise in today's release, but it leaves you exposed to older, known CVEs.

Pinning only works if you trust the version you are pinning. If you update your config to pin a newly released version and that version happens to be a compromised release from a hijacked maintainer account, well then, your client will happily download and index that malware regardless.

Without a cooldown policy acting as a quarantine buffer, devs updating their pinned dependencies are essentially playing Russian roulette with the latest release.

On a positive note, the open source supply chain is evolving all the time. Where cooldown controls don't exist today, they could very well exist tomorrow. What’s important to software developers and security teams is that we can curate or enforce security controls that seamlessly apply across the wide variety of languages and runtime ecosystems.

That’s where an artifact management platform like Cloudsmith comes to the rescue. The platform provides cooldown policy support for 

, with additional format support planned:

Cloudsmith supports cooldown policies in npm and Python

If time really is just a construct of human perception, package managers have certainly taken that philosophy to heart. But the real headache is trying to actually implement security controls in the real world. 

This is fundamentally a client-side crisis

We are forcing devs and their pipelines to rely on local, fragmented CLI tooling to enforce security policies that should be uniform. The fragmentation here is a massive vulnerability:

Different naming conventions and arbitrary time units across clients make universal configurations very challenging.

Some client-side tools allow granular exclusions, while others offer no cooldown protection at all.

While centralised registries like Cloudsmith work overtime to curate, scan, and secure upstreams, they need to account for rogue, outdated, or poorly designed local clients that bypass standard safeguards.

Trying to secure a polyglot codebase where the security posture of your entire pipeline is dictated by the weakest client-side tool in your stack is a logistical nightmare.

Cloudsmith solves this systemic headache by providing a single control plane for your entire software supply chain. By defining a universal policy that sits above individual ecosystems, you don’t waste time tweaking configurations across a wide range of runtimes. With Cloudsmith, you define the policy once, and enforce it across your entire workspace.


If you’re interested in learning more about Cloudsmith 

Nigel Douglas

Head of Developer Relations

How to configure time for cooldown policies

If you were hoping for a relaxing summer break without a software supply chain attack, the latest news will disappoint. Early on July 14th 

 identified that an attacker compromised AsyncAPI repositories and used the projects’ own CI/CD pipelines to publish four malicious npm packages. Together these packages see more than 2.9 million downloads a week, with @asyncapi/specs accounting for roughly 2.7 million of them.

Here’s what we know so far, why so many conventional defenses would have let these packages through, and what a governed control layer does about it.

The attacker exploited a misconfigured GitHub Actions workflow in the asyncapi/generator repository to steal a highly privileged token belonging to the project's automation account. They used that token to push a commit that triggered the release pipeline, which published trojanized packages to npm under the trusted @asyncapi namespace. A second repository in the same organization was then used to publish the highest-impact package, @asyncapi/specs.

For a full breakdown of the attack, Wiz’s post provides an excellent 

This attack has two details that matter for what follows. First, the malicious code was hidden inside otherwise legitimate source code and it ran on package import rather than install. Second, once triggered it installed a persistent credential stealer that swept for browser passwords, SSH keys, npm and GitHub tokens, and cloud credentials.

Why security scanners may have allowed these packages through

None of the usual signals a build environment relies on would have stopped these downloads.

 The packages came from the correct namespace, published through the project’s real release pipeline using a real maintainer token.

The versions were brand new, so no intelligence existed yet: 

At the moment of publication, no advisory named these versions as malicious. A team pulling @asyncapi/specs@latest in the minutes or hours after publication would have received a clean bill of health from every feed, because the community hadn't identified the compromise yet. This is the zero-hour window, and pulling directly from a public registry means running straight into it.

Install-time scanning looked in the wrong place:

 Many defenses focus on preinstall and postinstall hooks, because that's where supply chain payloads have historically lived. This payload executed on import instead. Tooling watching only the install lifecycle would have seen nothing.

 Even a developer inspecting the source would have had to scroll past hundreds of blank spaces to find the payload.

This pattern is consistent across many of this summer’s software supply chain attacks. When packages flow directly from a public registry into a build without a control point in between, a compromise can reach your environment because nothing was positioned to intercept it.

Check your lockfiles for the compromised versions

Assume secrets are exposed on any developer machine or CI runner that installed an affected version. Rotate npm tokens, GitHub tokens, SSH keys, AWS access keys, and browser stored credentials.

Audit CI/CD secrets for any pipeline that ran npm install during the compromise window.

The steps above are helpful but reactive, taking place only after a malicious package is already inside your environment. These steps also don’t scale, relying on someone to spot the advisory, trace which builds pulled what, and rotate the right credentials before an attacker uses them.

Artifact management platforms can add a control layer ahead of package pulls to prevent some of these dangers from ever becoming present. Simply put, when detection and response move upstream and run automatically, compromised packages are stopped or contained upstream.

Cloudsmith is that governed control layer. Every package that enters a Cloudsmith workspace, whether proxied from a public registry or published internally, is evaluated against policies that assess risk, and permitted or blocked before it reaches a developer machine or CI pipeline. Two capabilities map directly to how the AsyncAPI attack played out.

With Cloudsmith as a private registry proxying npm, PyPI, Maven Central, and others, npm install routes through Cloudsmith rather than straight to the public registry. Every package, including transitive dependencies, flows through one control point you can see and govern. Without that layer, there's no place to intercept a poisoned @asyncapi/specs on its way into a build.

 to help businesses vet new packages for risk: they set a minimum age a package must reach before it can be used. That closes the window most of these attacks target, the gap between a malicious package going live and an advisory going out, Cloudsmith’s cooldown policies are enforced at the index level. Versions younger than the age you set are filtered out before the package manager ever sees them, with builds resolving cleanly to the next available version.

Cooldown with Cloudsmith this summer. Relax knowing that Cloudsmith checks every open source dependency your team pulls, keeping malware like this out of your artifacts. 

 today about defending against malicious package attacks.




Meghan McGowan

Product Marketing Manager

Inside the AsyncAPI npm supply chain attack

AI dev frameworks are becoming a key target for software supply chain attackers. The logic is rather simple: if you can compromise the framework itself, you have the ability to compromise highly sensitive infrastructure today. That includes LLM API keys, cloud provider secrets, the kind of credentials that would allow an attacker to move laterally from there.

On June 17, a sophisticated software supply chain incident, specifically targeted 

 package name. Mastra is a popular open-source TypeScript framework used for building AI agents and 

By hijacking a former contributor’s creds, attackers were able to inject a malicious dependency across 144 packages in the Mastra ecosystem. With core components like 

 pulling nearly a million weekly downloads, the blast radius of an attack like this is massive. In this blog we’ll look at how the attack unfolded, how the malware evades detection, and how developers can secure their environment today.

The attackers executed a multi-stage campaign that relied on a blend of account takeover, social engineering (via package mirroring), and a dynamic second-stage runtime payload designed to bypass traditional static analysis.

The groundwork was laid a day prior to the primary breach. An npm user named 

. At this point, the package appeared entirely benign, indicating it was a fully functional clone of the highly popular 

By copying the original library’s version numbering, MIT license, and author metadata (

), the attackers ensured that any casual visual or automated sanity check of the package structure would look clean - one of the many ways the attacker is evading detection.

In the next stage, the threat actor updated the 

. Again, this version looked identical to its predecessor but introduced a relatively small, obfuscated file named 

, along with an execution trigger in the 

. Following a wave of community concern, 

 flag was explicitly used to suppress the Node.js runtime environment warnings, which ensured devs remained unaware during the installation.

A few minutes later, the attackers struck the 

, a legitimate former Mastra contributor whose organisational scope access had never been revoked. From there, they used an automated script that rapidly populated the 

 in just over an hour. Each package was updated to include the malicious dependency:

), any fresh install or build runner pulling the clean pinned version 

 was automatically forced to resolve and download the malicious 

 patch. From an execution perspective, when a dev or automated CI/CD pipeline runs 

 hook fires immediately, which causes the 

 script to initiate a highly-evasive first-stage dropper into the environment.

The underlying mechanics of the first-stage execution reveal a strong emphasis on evasion and anti-forensics. It has four clear evasion tactics:

 allows the script to safely reach out to an attacker’s C2 infrastructure even if the interception tools or self-signed proxies attempt to inspect or block the traffic.

, the second-stage payload is then able to spin out into its own OS process. When the core 

 routine finishes or is terminated, the malware continues running silently in the background.

: Finally, the script finishes by calling 

 immediately after execution, the installer leaves behind a clean directory tree, baffling standard post-incident file scanners.

: Mastra utilises npm's trusted publisher flow inside their CI pipeline, generating robust Sigstore-backed SLSA provenance attestations for authentic releases. However, while Mastra generated provenance, their 

The tragedy of this fourth evasion tactic is that it was entirely preventable. Because a strict verification policy wasn't required on the registry side, 

 willingly accepted the attacker’s mass updates pushed directly from a stolen PAT, even though they dropped the cryptographic provenance signature. Any client configuring a strict signature-verifying installation policy would have immediately blocked this entire campaign.

How developers can secure their environments today

By using open infrastructure tooling like 

, organisations can detect the malicious 

 package as well as the various malicious packages published to the compromised Mastra org on June 17.

However, security shouldn’t just be reactive. Developers can’t just wait for security advisories. While 

 has stepped in to pull any compromised versions from the registry, if you had run an install during the exposure window, before these advisories were published, you should treat the environment as compromised.

Securing your software supply chain requires a proactive architecture. If you're managing external dependencies using Cloudsmith, here’s how you could mitigate attacks like 

: You’ll be hearing this from us a lot, but cooldown policies really are one of the most effective solutions to this recent wave of open-source supply chain attacks. Malicious packages are often caught and reported within hours of publication. By establishing an upstream proxy with a cooldown window (let’s say, holding newly-published packages for 

 before they become eligible for download), you create a natural buffer that keeps automated pipeline scripts from pulling zero-day dependencies.

: As highlighted earlier, you should never rely purely on range-based specifiers (either 

) for high-value upstream dependencies. Where possible, ensure a strict 

 is enforced across all local and CI/CD builds. This guarantees that your builds anchor exclusively to known, cryptographically hashed versions.

Inside the Mastra npm supply chain attack

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.

 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 policy engine runs on Open Policy Agent (

), the same open standard used in Kubernetes environments and across the cloud-native ecosystem. Policies are written 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 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 

 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.

Jason Myers

Technical Content Marketer

Dependency Firewall

How to use Cloudsmith as a dependency firewall

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 

Cloudsmith Blog

How to configure time for cooldown policies

Inside the AsyncAPI npm supply chain attack

Inside the Mastra npm supply chain attack

How to use Cloudsmith as a dependency firewall

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 cooldown policies block newly published packages without disrupting your builds

The EU Cyber Resilience Act: What engineering teams need to do to be compliant

The Miasma worm's path of destruction

EU CRA compliance: building a defensible posture with Cloudsmith

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