JFrog Xray scans the artifacts in your Artifactory repository. Kusari builds the dependency graph from source instead, across every repository you have, whether or not what it produces ever lands in Artifactory. If your supply chain security is anchored to the artifact repository and your questions stop at "is what we published vulnerable," Xray answers them. If you need provenance further upstream than the artifact — what pulled a dependency in, which applications actually reach it, and whether the build that produced it can be trusted — that's the gap Kusari fills.
| Capability | Kusari | JFrog Xray |
|---|---|---|
| Full-depth transitive dependency knowledge graph | Yes | Partial Transitive requires additional subscription |
| Portfolio-wide view across source repositories | Yes | Partial Only artifacts indexed in Artifactory |
| Identify vulnerable dependencies | Yes | Yes |
| Identify unmaintained or EOL dependencies | Yes | Partial Limited ecosystems |
| Identify typosquatted or malicious dependencies | Yes | Yes |
| Secrets detection | Yes | Yes |
| GitHub workflow security analysis | Yes | Yes |
| Open source license analysis | Yes | Yes |
| Full-depth transitive SBOM without an add-on | Yes | Partial Additional subscription |
| Infrastructure as Code misconfiguration detection | Yes | Yes |
| Reachability analysis with VEX | Yes | Partial Transitive requires additional subscription |
| Automatic agentic AI remediation of vulnerabilities | Yes | Yes |
| Integrated artifact repository | Via ecosystem partners | Yes |
| Analysis begins at the source, not the built artifact | Yes | No |
| Capability | Kusari | JFrog Xray |
|---|---|---|
| Configurable alerting | Yes | Yes |
| GitHub App available | Yes | Yes |
| GitHub Action available | Yes | Yes |
| CLI tool available | Yes | Yes |
| Proceed / do not proceed recommendation in the pull request | Yes | Partial Build-time policy gate only |
| Deploys without adopting a new artifact repository | Yes | Partial Requires Artifactory |
Xray isn't a bolt-on scanner someone chose separately. It's part of Artifactory, and if Artifactory is already your system of record for binaries then that integration is worth something real.
Everything you publish is already indexed. There's no separate inventory to stand up or keep current. Xray sees what the repository sees, which for a team whose golden path runs entirely through Artifactory is most of what they need to know.
The policy gate sits at promotion. If your control model is "nothing leaves staging unless it passes," promotion is the natural place to enforce that, and Xray enforces it there.
One vendor for the repository and the scanning. Fewer contracts, fewer integrations, one support path — which matters more in practice than tool comparisons usually admit.
Broad artifact-type coverage. Containers, Debian and RPM packages, Helm charts, and the rest of what Artifactory hosts, all scanned in place.
If that describes your setup, Xray may be all you need, and this page isn't trying to talk you out of it.
The limits show up in the same place the strengths do: the artifact.
Coverage stops at what's indexed. Xray reasons about artifacts in Artifactory. Source that hasn't been built, repositories that publish somewhere else, and anything a team ships outside the golden path are all outside its view. On a large estate that's usually a meaningful fraction, and you find out which fraction when someone asks "are we affected" about a repo nobody registered.
Transitive depth and SBOM are separate line items. Full-depth transitive analysis and a full-depth transitive SBOM each require an additional subscription. Since 95% of open source vulnerabilities live in transitive dependencies (J.P. Morgan, Eye on the Market, July 2026), that's the majority of the problem sitting behind an upgrade rather than in the product you already bought.
The gate is at build time, not review time. A build-time policy gate tells a developer their build failed. It doesn't tell them, in the pull request, which dependency caused it and what the smallest change is that resolves it. By then the change is already written and the context for fixing it cheaply is gone.
Answers are about the artifact, not the estate. Xray can tell you a container image is vulnerable. Answering "which of our applications pull this package, through what, and which of those actually reach the vulnerable function" means correlating across artifacts rather than querying one graph.
One row in that table carries most of the difference: analysis begins at the source, not the built artifact.
Xray reasons about what you published. Kusari resolves the dependency graph from source at build, across every repository connected to it, and keeps it updated as code moves rather than rebuilding it on request. A manifest declares what software is supposed to contain; an artifact records what shipped. Neither records what the build actually resolved, which is where the transitive depth lives.
That changes what you can ask. "Do we have this, and where" becomes a query against one graph rather than a correlation exercise across artifacts. And because the graph is built at source, the answer covers repositories whose output never reaches Artifactory at all.
Findings arrive in the pull request, with a verdict. Every change gets a proceed or do-not-proceed before it reaches production, with the dependency that caused it and a remediation path attached — in the tool developers already live in, at the point where the fix is cheapest.
Ranked by Kusari Score, not raw CVSS. Reachability, exploitability and blast radius weighted into one number, with a CISA KEV listing setting a floor of 9 out of 10 and EPSS setting one where there's no KEV entry. When reachability analysis or a VEX document establishes that a vulnerability can't be hit in a given application, that application comes out of the calculation entirely.
Fixes that hold. No blanket "upgrade to latest" that breaks the build. Kusari traces a finding to its root cause across the transitive chain, works out the smallest change that resolves it, and respects the constraints and approval workflows you already have. CI runs against the change and a separate inspection agent re-scans the result before it reaches you.
Wherever your code lives. GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins, CircleCI and more, with findings routed into Jira or ServiceNow and alerts into Slack or Teams. It sits above the scanners you already own — the intelligence layer above your existing stack — rather than replacing them.
Kusari's founders co-created the open standards now used by Google, Microsoft, Intel, Citi and Red Hat to secure their own supply chains.
Less than you'd expect, because it isn't really a switch.
You keep Artifactory. Kusari doesn't host artifacts and has no interest in becoming your repository. It connects to your source control and your pipelines, so Artifactory carries on unchanged. Xray can keep running too — it becomes one input to the graph rather than the whole picture, and its findings get unified with everything else rather than discarded.
The usual first step is running Kusari alongside what you have and comparing the two lists for a few weeks. That's less painful on your teams than a migration, and it's the only way to find out whether the difference described here shows up on your estate specifically. If Xray isn't the only thing you're weighing, you can compare Kusari against other supply chain security tools on the hub.
Three things worth planning for:
Building the graph from source needs CI access, so this starts with a conversation with whoever owns your pipelines. Most teams go repo by repo rather than all at once, which makes it a smaller ask than it sounds.
If your control model is entirely promotion-gated today, you're adding a review-time gate in the pull request. That's a workflow change for developers, not just a tool change, and it's worth socializing before it appears in their PRs.
If your policy and exception workflows are wired deep into Xray, rebuilding that plumbing takes engineering time you'll have to find. Running both for a while buys you that time.
It depends what you're replacing. If you're looking for something to swap in as your artifact scanner, no — Kusari isn't a scanner and doesn't try to be one. If what you actually want is an alternative to treating artifact scanning as your whole supply chain picture, then yes, that's the gap it fills. Most teams end up running both: Xray on what they publish, Kusari as the graph above it that answers where a dependency came from and which applications it reaches.
No, and we'd advise against it. Kusari doesn't host artifacts and isn't an artifact repository. It connects to your source control and your build pipelines, so Artifactory keeps doing exactly what it does today.
Anything that hasn't been published yet, and anything published somewhere else. Xray reasons about artifacts indexed in Artifactory; Kusari resolves the dependency graph from source across every repository connected to it, whether or not that repository's output lands in Artifactory. It also carries full transitive depth and a full-depth transitive SBOM without a separate subscription, and it records what pulled each dependency in rather than only that it's present.
Yes, and that's the normal arrangement. Kusari sits above the scanners you already own and takes their findings as inputs, unifying them into one graph rather than replacing them. Nothing about adopting Kusari requires turning Xray off.
No. Artifact storage comes through ecosystem partners rather than from Kusari, which is why it deploys without asking you to adopt a new repository or migrate what's in the one you have.
Less than thirty minutes on a public repository. We run it live, you watch, and you keep any pull requests it opens.
We run Kusari on a public repo of your choice, live, for thirty minutes. It resolves the dependency tree, sorts what's affected from what isn't, and ranks what's left by Kusari Score. If you want us to, we'll open pull requests for anything currently open and fixable before the time is up, and you keep those whether or not you decide to keep talking to us.