March 2026: malicious versions of axios get published directly to npm. May 2026: attackers forge valid provenance for 42 TanStack packages on npm, with 84 malicious versions shipped before detection. August 2026: a worm uses one maintainer’s stolen credentials to self-propagate through keyv and its dependent packages.
Builds pull in thousands of open source packages from public registries without a second thought, and attackers are getting very good at poisoning these packages at the source. As dependency installation increasingly runs through agents rather than engineers, these supply chain attacks are going to happen faster and more frequently.
The software supply chain security ecosystem seems to have converged on the same fix within the last year: proactive enforcement. npm 12 has disabled dependency install scripts outright by default, closing what GitHub called the single largest code-execution surface in the npm ecosystem.
Repository managers reached the same conclusion. Sonatype’s Repository Firewall can quarantine and auto-release packages ahead of consumption. Cloudsmith runs cooldown policies that hold newly published packages until they have been checked. Socket inspects packages for behavioral indicators of compromise ahead of installation.
Perhaps the most significant architectural adjustment we’ve seen is that JFrog is deprecating the Block Download feature in Xray between April and November 2026. Thousands of organizations worldwide run their software supply chain through JFrog’s platform, so a change to how Xray behaves affects a large share of code actually shipped.
Xray keeps scanning and flagging vulnerabilities, but it loses the power to act on what it finds. Curation, licensed and priced on its own, per seat, evaluates a package’s metadata, including its age and publisher and blocks it at the gate if it fails policy.
Set the commercial questions aside and look at the architecture. A move such as this demonstrates the widely shared conclusion that enforcement belongs at the gate, evaluated before a package downloads, not scanned for after it has already been installed. It is a clear signal about where the whole category is going.
The question it leaves open is more interesting, and it is the one renewal conversations should actually be about.
Everyone Will Enforce at the Gate: What’s Left to Decide?
When gate-based enforcement becomes table stakes, the differentiator narrows to two architectural decisions beneath the enforcement point: who owns the policy decision, and where does it physically run?
These questions matter because the timeline has changed. Maintainer-account takeovers and self-propagating worms already compromise packages faster than catalog updates or ticket queues can move. The next wave of consumers pulling those packages is autonomous agents installing dependencies with no human in the loop, at whatever speed their compute allows. Both questions lead to the same conclusion: enforcement has to live on the wire, evaluated the moment a request is made, and the policy behind it has to be something the customer controls and can change in seconds.
Who owns the security policy? In JFrog Curation, policy lives inside JFrog’s own catalog and UI. Cloudsmith takes a more open approach, letting customers write policy as Rego, genuine policy-as-code, with the code executing inside Cloudsmith’s hosted platform. Either way, the vendor’s platform has to be there for the policy to run: JFrog holds the policy itself, Cloudsmith holds where it executes, but neither lets you take the policy elsewhere.
Where the decision executes is a separate question. Socket, Sonatype’s Firewall Pro, and Veracode’s Package Firewall all answer the question differently: front whatever registry a customer already runs, no platform migration required. But those decisions call out to a SaaS API before a build can proceed. Neutral about which registry you use; but not the same as portable if it depends on the vendor’s cloud.
Portability also breaks for a reason that has nothing to do with outages. Post-merger and post-acquisition, it is common for a large organization to find Artifactory running in one business unit, Azure Artifacts or Nexus in another, and GitHub Packages somewhere else again, not through any deliberate choice. A policy engine welded to one platform enforces consistently on the traffic that platform sees, and leaves a different, weaker posture everywhere else. Universal compatibility, the same policy applied across whatever registries an organization runs, should itself be table stakes, the only way a security policy can mean what it claims to mean.
So we see two trade-offs across the software supply chain security ecosystem. Deep tooling in exchange for platform lock-in. Registry neutrality in exchange for external cloud dependency.
Both trade-offs carry a third cost: developer friction. Developer friction and developer buy-in are two sides of the same coin. JFrog’s own release notes cite CLI timeouts and silent failures as a reason for its own product change. When a vendor admits that a security control developers cannot predict is a cost worth fixing, that’s something to listen to.
Policy written as code and kept in Git is an ownership question, but it is also a friction question. A change a developer can read as a pull request is one they can trust, while a change that arrives as an opaque update is not. Shipping a new policy in report-only mode before it blocks anything is the same instinct in a different form: nothing kills a developer’s willingness to work with a security control faster than a rollout that breaks a build.
JFrog, and others, are moving blocking out to the edge, to the point where a request first meets a registry, before anything downloads. That is exactly where Varnish already sits, and has sat for two decades of caching traffic at the edge of other people’s infrastructure. Varnish Artifact Firewall is the position in this market that keeps both the policy decision and the place it runs with the customer, the direct consequence of taking the two questions above seriously.
Policy is written as Git-native YAML, with a last-known-good fallback if the policy source itself becomes unreachable. It sits in front of the registries a customer already runs rather than replacing them, so adopting it is not a migration, and it works across whichever combination of registries a given organization happens to have accumulated. It is stateless and self-sufficient enough to deploy and scale without professional services, and because it runs in-process, the decision happens before a package downloads, with no round trip to distant clouds.
Quarantine is the mechanism underneath all of this. A newly published version is held back for a set window before anything is allowed to depend on it, hidden rather than deleted, giving time for a problem to surface before a build can reach it. What happens next depends on what the request asks for. An unpinned request for the latest version resolves to the newest version that has cleared quarantine, so a build that never depended on the held-back version keeps working without ever knowing it existed. A pinned version is designed to pass through as a deliberate choice, not silently overridden. A request that fails policy outright, not just time-held, is denied, and returns a clear error and an audit entry rather than a silent failure. Before any of this reaches enforcement, a policy can ship in report-only mode, logging what it would have quarantined or blocked without acting on it, so a team can see the real impact before switching it on. Each of those outcomes, held, resolved, denied, or simply logged, is visible to the developer at the point it happens, which is what developer control looks like in practice
Attacks almost never carry a CVE while they’re still active, the community catches them first, flagging malicious versions on databases like OSV.dev within hours to days of publication, well before any CVE gets assigned. Varnish pulls updated rules from OSV.dev automatically, every hour, so a quarantine window is built on a source that is already catching the important details. Other ruleset sources are being added to widen that coverage further.
What This Means Before the XRay Deprecation
The case that JFrog makes for gate-based enforcement is effective enough and shows that it is no longer a competitive differentiator but a baseline. What is left for a customer to decide is not whether to enforce earlier, but who writes the rule and whose infrastructure it runs on, and the risk driving that decision is only accelerating. A deprecation deadline is forcing that decision for Xray customers specifically, but the underlying choice is the same one facing anyone in this category: keep paying a vendor, per seat, for a decision made on their platform, or own the policy, and the infrastructure it runs on, yourself.
