JFrog Curation vs Varnish Artifact Firewall
Keep Artifactory. Choose your gate.
JFrog Curation and Varnish Artifact Firewall can both block a package download that breaks your policy, but they check in different places. Curation runs inside the JFrog platform, on the remote repositories you enable it for. Artifact Firewall sits in front of the registries you use, Artifactory included, and checks each request that goes through it. If your team runs Artifactory, the choice comes down to which requests need checking and who should own the rules.
How do the two approaches compare?
Take an npm package your CI pipeline installed last week at version 1.0.1. Artifactory now has a cached copy, and the project’s lockfile pins that version. Your team has since blocked 1.0.1, and the next CI run installs from the same lockfile. First, check that the block works on a version Artifactory has never fetched. Then check the two cases that are easy to miss: the copy of 1.0.1 already in Artifactory’s cache, and the exact download URL recorded in the lockfile.
| Question | JFrog Curation | Varnish Artifact Firewall |
|---|---|---|
| Where is policy applied? | In the JFrog platform, on the Artifactory remote repositories where Curation is enabled. | At a firewall endpoint you run. Supported package requests that go through it are checked. |
| How do we maintain rules? | Policies and their scope are built from JFrog Catalog conditions. | Custom rules are written in YAML and distributed from Git, alongside rules generated from OSV data. |
| How does a version hold work? | Compliant Version Selection can resolve a request to an approved version. Support varies by package ecosystem and Artifactory version, so check yours. | A hide rule makes latest resolve to the highest allowed version but still lets pinned installs through. A deny rule does the same for latest and also blocks the version itself, so even a download pinned in a lockfile gets a 403 that names the rule. |
| Does a block apply to packages Artifactory already cached? | Only if cached-package enforcement is turned on for both the environment and the policy. | Yes, with no extra setting, because every download is checked before it reaches Artifactory, cached or not. Lockfile URLs also need to go through the firewall, either by regenerating them with the firewall’s URL or by pointing Artifactory’s hostname at the firewall. |
| How do we roll out safely? | Set the policy to Dry Run first. Packages that break it can still be downloaded, and they’re flagged in the Curation audit view. Switch to Block once you know the impact. | Start in report mode, which logs every decision without blocking anything, then switch to normal mode to enforce. The audit log records each rule’s action next to what was actually enforced, so you can see what the trial would have blocked. |
| Which registries does one policy cover? | Artifactory remote repositories only. | Self-hosted Artifactory, Artifactory SaaS, Nexus and public registries, all with the same rules. |
Sources: JFrog’s version selection, cached-package controls, Varnish rule configuration and enforcement by package type. See the full list of Artifact Firewall capabilities.
When is JFrog Curation a good fit?
Curation makes sense if your package traffic already goes through Artifactory, your team manages security policy in JFrog, and your subscription covers the controls you need. To try it, set up the Curation equivalent of one of your existing Xray policies and test it against both a fresh download and a cached copy.
Curation entitlement and deployment · Curation controls for cached downloads
When should you evaluate Varnish Artifact Firewall?
Artifact Firewall is worth a look if a platform team wants one set of package rules, reviewed in Git, applied across more than one registry, such as Artifactory, Nexus, registry.npmjs.org or PyPI. It also suits teams that want the policy check running on their own infrastructure. You deploy it yourself as a Docker image, Helm chart or Linux package, so policy decisions and audit logs stay in your environment. One npm repository and one CI runner is a good place to start, since it’s small enough to trace every request from end to end.
How should we compare cost and scope?
Ask JFrog which Curation entitlements you already have and what the coverage you need would add at renewal. Artifact Firewall is priced in blocks of 50 covered developers. To compare quotes fairly, base both on the same team size, package ecosystems and repository routes.
What happens in a blocking coverage check?
Bring one repository URL pattern, the package ecosystems you use and an example of a rule you need to keep. In a 30-minute call, we’ll work out where downloads enter your pipeline and which paths need testing, and agree on a pass/fail criterion for the evaluation. A good first test is a pinned tarball: does it get the decision you expect, and can your team trace it in the audit log?
Request a blocking coverage check · See the Artifactory setup and test procedure
For the scope and timing of JFrog’s Xray change, read our Block Download deprecation explainer.