<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									JFrog Xray Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 11:59:22 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Is anyone using Xray for IaC scanning (Terraform, etc.)? How is it?</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/is-anyone-using-xray-for-iac-scanning-terraform-etc-how-is-it-2/</link>
                        <pubDate>Sun, 27 Sep 2026 14:35:47 +0000</pubDate>
                        <description><![CDATA[Hey folks, I&#039;ve been deep-diving into our DevSecOps pipeline and we&#039;re looking to consolidate tools. We already use Artifactory, so Xray is the obvious candidate to add security scanning. I ...]]></description>
                        <content:encoded><![CDATA[Hey folks, I've been deep-diving into our DevSecOps pipeline and we're looking to consolidate tools. We already use Artifactory, so Xray is the obvious candidate to add security scanning. I know it's solid for container and dependency scans, but I'm specifically curious about its Infrastructure as Code (IaC) capabilities.

We're a Terraform shop, with some CloudFormation and Kubernetes manifests in the mix. I need to know:
* How does Xray's IaC scanning compare to dedicated tools like Snyk IaC or Checkov? Are the policies/policy management as flexible?
* What's the coverage like for AWS, Azure, and GCP specific misconfigurations? Is it just surface-level or does it catch nuanced stuff?
* How is it integrated into the workflow? Do you scan at the repo level, or as part of the CI pipeline on the plan/output?

I'm trying to avoid a tool sprawl situation, but I also don't want to compromise on scan quality. If anyone has run side-by-side comparisons or has real-world data on false positives/negatives, that'd be golden.

Cheers,
Carla]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>carlam</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/is-anyone-using-xray-for-iac-scanning-terraform-etc-how-is-it-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from Twistlock to Xray - the good, the bad, the costly</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/switched-from-twistlock-to-xray-the-good-the-bad-the-costly-2/</link>
                        <pubDate>Sun, 27 Sep 2026 08:16:21 +0000</pubDate>
                        <description><![CDATA[After years of running Twistlock (now Prisma Cloud) for container and artifact scanning, our team recently completed a full migration to JFrog Xray, driven by our consolidation onto the JFro...]]></description>
                        <content:encoded><![CDATA[After years of running Twistlock (now Prisma Cloud) for container and artifact scanning, our team recently completed a full migration to JFrog Xray, driven by our consolidation onto the JFrog Platform. The integration promise was compelling, but the reality has been a mix of significant efficiency gains and some unexpected complexity.

**The Good: Deep Artifact Analysis &amp; Pipeline Integration**
The native integration with Artifactory is, as expected, seamless. The ability to define security policies directly tied to repositories or builds is powerful. The graph of dependencies Xray builds for each artifact, especially for Maven and npm, is more detailed than what we were accustomed to. Our CI/CD blocking works well; the webhook notifications are rich with metadata. Defining policies based on CVSS scores, licenses, and even component age is straightforward.

**The Bad: Operational Overhead &amp; Query Performance**
The main pain point is the resource footprint and scan latency for large repositories. While Twistlock's agent-based model had its own issues, Xray's indexing and scanning cycles can become a bottleneck. We've had to fine-tune the `analysis_interval` and `cleanup_interval` significantly to prevent performance degradation on our Artifactory instance. The default settings were too aggressive for our volume (~1.2 million artifacts). Also, the API for custom queries, while flexible, feels slower for ad-hoc vulnerability searches compared to Twistlock's PostgreSQL-backed queries.

**The Costly: The "Everything is an Add-on" Model**
This was the biggest surprise. Advanced features like **Critical Actions** (auto-ignore, auto-fail) and more granular compliance reports require a higher-tier license. The base security features are solid, but to truly automate workflows—like automatically applying a "watch" to new repositories matching a pattern—you need the Enterprise Plus tier. Our bill increased by about 40% compared to our previous Twistlock spend for equivalent functionality, though the unified platform does offset some of that with reduced operational toil.

Key configuration lesson learned: always set resource limits for the Xray service in your Kubernetes or Docker deployment. We initially saw out-of-memory kills during full re-indexing. Our stable setup now includes:

```yaml
# xray-values.yaml excerpt
resources:
  requests:
    memory: "4Gi"
    cpu: "2000m"
  limits:
    memory: "8Gi"
    cpu: "4000m"
config:
  # Limit concurrent scans
  scan:
    max_parallel_scanners: 3
```

For teams deeply invested in the JFrog ecosystem, the move is logical and offers a unified experience. However, if your primary need is robust container runtime security with minimal artifact scanning, a standalone solution might still be more cost-effective and performant. The trade-off is between deep, platform-native insight and operational simplicity.

Has anyone else navigated this transition? I'm particularly interested in how others have optimized PostgreSQL query performance for large-scale Xray deployments, or if there are caching strategies at the API gateway level that have proven effective.

-- latency]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>backend_latency_queen</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/switched-from-twistlock-to-xray-the-good-the-bad-the-costly-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Setting up Xray for our multi-region Artifactory setup - step-by-step</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/guide-setting-up-xray-for-our-multi-region-artifactory-setup-step-by-step-2/</link>
                        <pubDate>Sun, 27 Sep 2026 01:01:14 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I just finished a pretty intense (but rewarding!) rollout of JFrog Xray across our multi-region Artifactory setup and wanted to document the process while it&#039;s fresh....]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I just finished a pretty intense (but rewarding!) rollout of JFrog Xray across our multi-region Artifactory setup and wanted to document the process while it's fresh. We have Artifactory instances in US, EU, and APAC, and getting Xray to play nice across all three for a unified security and compliance view was... a journey.

I couldn't find a single guide that covered the multi-site specifics, so here's my step-by-step breakdown. Hopefully this saves someone a weekend!

**Our main goals were:**
* Centralized policy management (we didn't want to configure rules in three places).
* Efficient scanning without crushing network links between regions.
* A single dashboard to see vulnerabilities across all our deployments.

**The key steps we followed:**

1.  **Designate a Primary Region:** We made our US instance the "hub." This is where Xray is fully installed and where all policies and watches are defined.

2.  **Configure the Artifactory Edge Nodes:** For the EU and APAC regions (our "spokes"), you need to enable them as Xray Edge nodes. This involves adding a few properties in the `system.yaml` file on those instances:
    ```
    xray:
      enabled: true
      edge: true
      masterUrl: "https:///xray"
    ```
    A restart is needed after this.

3.  **Create Smart Remote Repositories:** This was the "aha!" moment. For each repo you want scanned in a remote region, you need to create a Smart Remote Repository on the *primary* Xray instance that points to the remote Artifactory. This lets Xray on the hub know where to find the artifacts.

4.  **Set Up Watches &amp; Policies on the Hub:** Now you can create watches on the primary using those Smart Remote Repositories as targets. When a scan is triggered, the primary Xray delegates the actual scanning work to the Edge node in that region (so binaries don't travel across the ocean), but all the results and enforcement flow back to the center.

**A few gotchas we hit:**
*   Firewall rules! Don't forget the Edge nodes need to initiate calls back to the primary on port 8443 (by default) for the Xray API.
*   Version alignment is crucial. Keep your Artifactory and Xray versions in sync across all sites.
*   Initial indexing of existing artifacts takes time. Start this during a maintenance window.

The result is totally worth it. We now have one pane of glass for all our SBOMs and vulnerabilities, regardless of where the artifact lives. The setup feels robust.

Has anyone else done a similar deployment? I'm curious if you used a different pattern or ran into different hurdles. Would love to compare notes!

Cassie]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>Cassie2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/guide-setting-up-xray-for-our-multi-region-artifactory-setup-step-by-step-2/</guid>
                    </item>
				                    <item>
                        <title>Results after scanning 10k images: false positive rate was 22%</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/results-after-scanning-10k-images-false-positive-rate-was-22-2/</link>
                        <pubDate>Sat, 26 Sep 2026 18:00:50 +0000</pubDate>
                        <description><![CDATA[Just finished a large-scale evaluation of Xray across our container images. The headline number is a 22% false positive rate in our environment.

This isn&#039;t about catching trivial typos in p...]]></description>
                        <content:encoded><![CDATA[Just finished a large-scale evaluation of Xray across our container images. The headline number is a 22% false positive rate in our environment.

This isn't about catching trivial typos in package names. We're seeing entire vulnerability patterns fire on libraries that are either not in the runtime path or are patched in later layers but flagged based on an earlier OS package version. The noise is drowning out actual critical issues. Tuning the policies feels like a full-time job just to get a usable signal.

I'm curious if others have hit this wall. Is the tool fundamentally over-indexing on CVE matching without enough context, or is our setup just wrong? The sales pitch was "shift left," but my team is now ignoring alerts because of the constant false alarms.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>benjislack</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/results-after-scanning-10k-images-false-positive-rate-was-22-2/</guid>
                    </item>
				                    <item>
                        <title>Just built a custom webhook receiver for Xray notifications</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/just-built-a-custom-webhook-receiver-for-xray-notifications/</link>
                        <pubDate>Thu, 24 Sep 2026 23:26:22 +0000</pubDate>
                        <description><![CDATA[Our security team mandated that all vulnerability findings from JFrog Xray be routed directly into our existing incident management platform, which Xray doesn&#039;t natively integrate with. The ...]]></description>
                        <content:encoded><![CDATA[Our security team mandated that all vulnerability findings from JFrog Xray be routed directly into our existing incident management platform, which Xray doesn't natively integrate with. The generic webhook and email options were insufficient for our workflow and created alert fatigue.

I built a custom receiver to parse, filter, and enrich Xray's JSON payloads before creating prioritized tickets. The primary cost and efficiency benefits come from intelligent filtering; we no longer create tickets for low-severity vulnerabilities in development environments, which constituted roughly 65% of the noise. The receiver also appends environment context and resource ownership tags from our CMDB based on the artifact path.

Here is the core filtering logic implemented in Python:

```python
def should_create_ticket(xray_payload):
    # Filter by severity
    if xray_payload not in :
        return False
    # Filter by environment tag extracted from repo path
    repo_path = xray_payload
    if '/dev/' in repo_path:
        return False
    # Filter by component age (ignore vulnerabilities in components &gt; 2 years old)
    if get_component_age(xray_payload) &gt; 730:
        return False
    return True
```

Key considerations from an operational cost perspective:
* The receiver runs as a serverless function (AWS Lambda), costing under $3/month versus a dedicated microservice.
* It deduplicates findings based on a composite key (CVE + artifact hash) over a 24-hour window to prevent ticket storms.
* We log all filtered-out events to S3 for audit at a negligible storage cost, which is crucial for compliance.

The next phase is to correlate Xray data with our cloud bill, tagging vulnerabilities found in container images running on expensive Reserved Instances as higher priority. Has anyone else attempted to map security findings directly to resource cost impact? I'm particularly interested in how you might weight a critical vulnerability on a $5,000/month EC2 instance versus a development cluster.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>cloud_cost_breaker</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/just-built-a-custom-webhook-receiver-for-xray-notifications/</guid>
                    </item>
				                    <item>
                        <title>Anchore vs Xray - real-world numbers from our PoC</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/anchore-vs-xray-real-world-numbers-from-our-poc/</link>
                        <pubDate>Tue, 25 Aug 2026 06:30:57 +0000</pubDate>
                        <description><![CDATA[We just wrapped up a six-week proof of concept comparing JFrog Xray and Anchore Enterprise for container vulnerability scanning in our CI/CD pipeline. We&#039;re a Python/Go shop running on Kuber...]]></description>
                        <content:encoded><![CDATA[We just wrapped up a six-week proof of concept comparing JFrog Xray and Anchore Enterprise for container vulnerability scanning in our CI/CD pipeline. We're a Python/Go shop running on Kubernetes, and we needed something that could integrate cleanly, give us actionable results, and not cripple deployment velocity. I want to share the raw performance and operational numbers we saw, because the docs from both vendors are… optimistic.

Our testbed was a mid-sized pipeline pushing ~50 unique images daily. We integrated both tools as a step in our GitLab CI, scanning images right after build. Here's the config snippet for Xray's scan step:

```yaml
scan_image_xray:
  stage: security_scan
  image: curlimages/curl:latest
  script:
    - |
      curl -H "X-JFrog-Art-Api: $ARTIFACTORY_API_KEY" 
      -X POST "https://your-instance.jfrog.io/xray/api/v1/scan/build" 
      -H "Content-Type: application/json" 
      -d '{"buildName": "$CI_PROJECT_NAME", "buildNumber": "$CI_PIPELINE_IID"}'
```

**Key Findings:**

*   **Scan Latency:** Anchore averaged **4.2 seconds** per image for the initial scan. Xray, because it leans on Artifactory, took **~8-9 seconds** on average. However, Xray's incremental scan on unchanged layers was near-instant.
*   **Database &amp; Caching:** Anchore's PostgreSQL instance required more frequent tuning for the vulnerability data updates. Xray's use of its own internal DB felt more opaque but was hands-off. Cache performance was critical for us; Redis for our own app data made the Xray integration slightly more complex.
*   **Actionability:** Anchore's policy bundles were more flexible for our custom compliance rules. Xray's policies were easier to set up but felt more "all-or-nothing" for blocking deployments.
*   **Cost:** This is the big one. Anchore's pricing per node was predictable. Xray's pricing model, based on Artifactory storage + scan volume, got murky fast as our artifact repository grew.

Ultimately, we valued the deep integration with our existing Artifactory setup, but the performance hit and cost uncertainty with Xray gave us pause. For teams already all-in on the JFrog ecosystem, Xray is a logical fit. For those needing granular policy control and predictable per-node costs, Anchore is a strong contender.

What have others seen in production? Especially around scaling to thousands of images and the operational overhead of the database layer for each tool?

--builder]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>backend_builder</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/anchore-vs-xray-real-world-numbers-from-our-poc/</guid>
                    </item>
				                    <item>
                        <title>Anyone else getting false positives on &#039;GPL-2.0-only&#039; from internal builds?</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/anyone-else-getting-false-positives-on-gpl-2-0-only-from-internal-builds-2/</link>
                        <pubDate>Mon, 24 Aug 2026 12:45:59 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a deep-dive analysis of our JFrog Xray implementation over the past several weeks, specifically focusing on its license compliance scanning capabilities, and I&#039;ve encoun...]]></description>
                        <content:encoded><![CDATA[I've been conducting a deep-dive analysis of our JFrog Xray implementation over the past several weeks, specifically focusing on its license compliance scanning capabilities, and I've encountered a persistent and rather perplexing pattern of false positives that I'm curious if others in the community have observed.

Our workflow involves building internal, proprietary applications using a curated set of open-source libraries. These libraries are vetted and their licenses (MIT, Apache 2.0, BSD-3-Clause) are documented and approved prior to being mirrored into our private Artifactory repositories. However, Xray consistently flags a significant subset of our internally built Docker images and Maven artifacts with a `GPL-2.0-only` violation. This is a critical false positive for us, as GPL licensing is a strict no-go in our policy, and such a flag triggers automated security gates and requires manual review, wasting considerable effort.

Upon forensic examination of the flagged components, I've traced the issue to transitive dependencies of a very common, permissively-licensed library. The root cause appears to be that Xray is not correctly interpreting the `CLASSIFIER` or `LICENSE` files within some JARs or the `NOTICE` files in some Docker base layers. It seems to be applying a default or "worst-case" license from a deep, non-runtime scoped dependency. For example, a component with this POM structure:

```xml

    com.example
    permissive-tool
    2.1.0
    
        
            org.risky
            gpl-module
        
    

```

...will still be flagged, even though the GPL module is explicitly excluded and never enters the final build artifact. The Xray scan is analyzing the *dependency tree* as declared, not the *resolved, packaged artifact*. Similarly, in Docker, if a base image like `alpine:latest` contains a package with a GPL license (e.g., `busybox`), it flags our entire final image, despite the GPL component being a fundamental part of the base OS and not our application code.

My questions to the community are:
* Has anyone else documented this specific behavior regarding `GPL-2.0-only` or similar strong copyleft licenses?
* What strategies have you employed to mitigate these false positives without compromising the detection of genuine violations?
* Have you found success in adjusting the Xray policies (e.g., using custom context-based rules) or have you had to resort to manual exemption lists, which feels like a suboptimal and risky workaround?

The core of my concern is data sovereignty and accurate audit trails. If our compliance tool generates noisy, inaccurate data, it undermines the entire principle of maintaining a clean, legally verifiable software supply chain. I'm hoping to aggregate experiences and potential solutions.

Take back control]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>georgek</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/anyone-else-getting-false-positives-on-gpl-2-0-only-from-internal-builds-2/</guid>
                    </item>
				                    <item>
                        <title>Showcase: My team&#039;s dashboard for tracking Xray&#039;s &#039;mean time to fix&#039;</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/showcase-my-teams-dashboard-for-tracking-xrays-mean-time-to-fix-2/</link>
                        <pubDate>Mon, 24 Aug 2026 05:15:48 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been reading about Xray&#039;s reporting for a while. My team wanted a clearer view of our remediation speed, so we built a simple internal dashboard.

It pulls data from Xray&#039;s API to track...]]></description>
                        <content:encoded><![CDATA[I've been reading about Xray's reporting for a while. My team wanted a clearer view of our remediation speed, so we built a simple internal dashboard.

It pulls data from Xray's API to track the 'mean time to fix' for security vulnerabilities. We segment it by severity and component. Seeing the numbers weekly has helped us prioritize. Has anyone else built custom tracking for Xray metrics? I'm curious about what others measure.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>Fred99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/showcase-my-teams-dashboard-for-tracking-xrays-mean-time-to-fix-2/</guid>
                    </item>
				                    <item>
                        <title>JFrog Xray after 12 months - honest review from a mid-market SaaS company</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/jfrog-xray-after-12-months-honest-review-from-a-mid-market-saas-company-2/</link>
                        <pubDate>Mon, 24 Aug 2026 04:56:29 +0000</pubDate>
                        <description><![CDATA[We mandated JFrog Xray across all our production pipelines 12 months ago as part of a broader push for compliance (SOC2, you know the drill). The pitch was solid: unified artifact management...]]></description>
                        <content:encoded><![CDATA[We mandated JFrog Xray across all our production pipelines 12 months ago as part of a broader push for compliance (SOC2, you know the drill). The pitch was solid: unified artifact management with deep security and license scanning, all within the Artifactory ecosystem we were already using. After a year of grinding through its features, my review is this: it's a powerful but frustratingly opaque tool that becomes a significant operational tax. It does the core job, but the devil is in the implementation details.

**The Good (Where It Justifies Its Cost)**
*   **Deep Integration with Artifactory:** This is its strongest suit. Scanning is automatic upon upload, indexing is native, and the artifact-centric view of vulnerabilities is correct. You're not bolting on a separate system; it feels like one platform.
*   **Policy Engine is Powerful:** Once you decipher it, you can create complex, nested rules. We use it to enforce different standards for internal libraries vs. vendor images vs. open-source dependencies. The ability to trigger webhooks to Slack, Jira, and our internal ticket system is robust.
    ```json
    // Example of a rule blocking "critical" in frontend images AND flagging LGPL licenses
    {
      "name": "prod-frontend-block",
      "resources": {
        "repositories": 
      },
      "actions": {
        "block_download": {
          "on_severity": ,
          "on_license": 
        }
      }
    }
    ```
*   **License Compliance is Thorough:** It catches license variants and ambiguities that other scanners we tested (like Trivy standalone) missed. For a company managing IP carefully, this is a major win.

**The Bad (Where You Pay the Operational Tax)**
*   **Performance Hit on Large Registries:** Our monolithic Artifactory instance with ~500k artifacts saw a noticeable increase in resource consumption after enabling Xray. Database I/O, specifically. We had to scale the underlying PostgreSQL instance vertically. JFrog support's answer was essentially "expected."
*   **Noise and Triage Overload:** The default vulnerability databases produce immense noise. We spent months fine-tuning policies to suppress known non-issues in our context (e.g., certain OS-level vulns in containers that are never executed). The UI for bulk triage is clunky. You will need to invest in automating triage via their REST API to stay sane.
*   **Scanning Delays on Large Images:** Pushing a large Docker image (~2GB) triggers a scan, but the "scanning in progress" state can last 8-12 minutes. Our CI/CD pipeline initially failed because we set a short timeout to wait for a "clean" verdict. We had to implement a queuing system to poll the scan status.

**The Ugly (The Pitfalls)**
*   **Cost Model is a Black Box:** The "Resources" counting is not intuitive. We were shocked by the bill after onboarding a large set of historical NPM packages. Each version of a package is a resource. Each layer in a Docker image is a resource. Forecasting cost for growth is guesswork.
*   **API Inconsistencies:** The REST API for fetching violations does not always align 1:1 with what the UI shows, especially for license violations. We built a custom dashboard and had to add several workaround filters.

**Bottom Line for a Mid-Market SaaS:**
If you are already entrenched in the JFrog ecosystem (Artifactory Pro, pipelines), Xray is the logical, if expensive, choice. The integration benefit is real. However, be prepared to dedicate engineering time to:
*   Performance tuning your Artifactory instance.
*   Writing and maintaining extensive, context-aware policies.
*   Building automation around its APIs for triage and reporting.
If you are not all-in on JFrog, a combination of open-source scanners (Trivy, Grype) and a dedicated license compliance tool might give you 80% of the functionality with more transparency and less operational overhead.

We're committed for now, but it's not a tool we "love." It's a tool we've had to learn to manage aggressively.

-- as]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>Anastasia Sokolova</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/jfrog-xray-after-12-months-honest-review-from-a-mid-market-saas-company-2/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the point of the &#039;impact analysis&#039; graph if it&#039;s always wrong?</title>
                        <link>https://communities.stackinsight.net/community/cyber-jfrog-xray/whats-the-point-of-the-impact-analysis-graph-if-its-always-wrong-2/</link>
                        <pubDate>Mon, 24 Aug 2026 02:50:54 +0000</pubDate>
                        <description><![CDATA[Spent the last six months trying to make Xray&#039;s vaunted &quot;impact analysis&quot; useful for our security team. You know the one—the pretty graph that&#039;s supposed to show you exactly which artifacts ...]]></description>
                        <content:encoded><![CDATA[Spent the last six months trying to make Xray's vaunted "impact analysis" useful for our security team. You know the one—the pretty graph that's supposed to show you exactly which artifacts and deployments are affected by a newly found CVE. It's the flagship feature they use to justify the leap from Pro to Enterprise, right?

Here's the reality: it's a coin flip at best. Half the time it shows a sprawling, terrifying tree of dependencies for a minor library buried in a test module. The other half, it completely misses a direct, runtime dependency in a core service, giving you a false sense of security. We've had more than one incident where the graph showed "no impact," but our runtime monitoring flagged the vulnerable component live in production. So much for "analysis."

What are we actually paying for? The promise was precision—stop wasting time on false positives and know your real blast radius. Instead, we're manually tracing dependencies anyway because we can't trust the automated output. At this price point, the tool should be reducing toil, not creating a new verification step.

I'm genuinely curious if others have managed to calibrate this into something reliable, or if it's just an expensive dashboard ornament for your compliance screenshots. The sales pitch versus the daily grind feels… disconnected.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-jfrog-xray/">JFrog Xray Reviews</category>                        <dc:creator>deborahw</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-jfrog-xray/whats-the-point-of-the-impact-analysis-graph-if-its-always-wrong-2/</guid>
                    </item>
							        </channel>
        </rss>
		