What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Feature availability across subscription tiers: confirm with vendor
- Current supported package type list: verify against vendor documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Xray scans what is in your binary repository rather than what is in your source tree, and it does so recursively. When an artifact lands in Artifactory, Xray indexes it and then indexes what is inside it: a container image down through its layers to the operating system packages and the application archives within, a Java WAR down through its bundled JARs, an npm tarball down through its contents. That recursive descent builds a component graph for every artifact, matched against JFrog's vulnerability database and license data.
Because Artifactory already knows which builds consumed which artifacts and where they were promoted, Xray can run impact analysis in both directions. Given a new vulnerability, it identifies every stored artifact and recorded build containing the affected component, including artifacts assembled long ago. Policy is enforced through watches that bind rules to repositories, builds or release bundles, with actions that fail a build, block a download, block promotion, or notify. Blocking download is the distinguishing capability: a violation can stop a developer pulling the package at all.
Where it fits
This sits at the artifact layer, covering the whole supply chain flowing through Artifactory: dependencies arriving from public registries, internal artifacts moving between repositories, and release candidates promoted to production. It is operated by whoever runs the binary repository, usually a platform team, with security defining watch policies. The hard prerequisite is Artifactory itself. Xray is not a standalone scanner and there is no meaningful deployment without the repository underneath it.
Strengths
- Recursive indexing sees nested components that surface-level manifest scanning never reaches.
- Blocking downloads at the repository stops a known-bad package before it enters a build, rather than reporting on it afterwards.
- Impact analysis across stored builds answers which shipped artifacts contain a component without re-scanning anything.
Limitations
- Total dependence on Artifactory. If you are not already a JFrog shop, adopting Xray means adopting a binary repository platform, which is a much larger decision.
- Matching is version-based, without reachability analysis, so severity and policy are the only prioritization levers.
- Indexing large repositories is resource intensive, and the initial index of an established Artifactory instance is a capacity planning exercise rather than a switch. Capability is also tiered across subscription levels.
Who it suits
The obvious choice for organizations already standardized on Artifactory, where it turns an existing chokepoint into an enforcement point with little new architecture. It makes far less sense as a standalone purchase, and it is not the tool for a team that wants findings in pull requests, since its natural place is later, at the artifact rather than the commit.
Used JFrog Xray? Recommend it under your own name and title.
Recommend this tool