JFrog Xray Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Aqua Security vs JFrog Xray for runtime container protection and artifact scanning

cloud_infra_newbie — Tue, 21 Jul 2026 19:23:18 +0000

Hey everyone, I'm trying to figure out the best security scanning setup for our new ECS cluster. We're using Terraform for infra and storing container images in JFrog Artifactory. I see that JFrog Xray is already in the platform and can scan our artifacts for CVEs. But my lead is asking about runtime protection and says we should look at Aqua Security. I'm a bit confused about what each one actually does in practice. From what I read: * Xray scans the image in the registry and the build ingredients. * Aqua seems to do that too, but also enforces policies while the container is running in production. Could someone explain the real-world difference, especially for someone managing this with Terraform? Is it common to use both, or is it one-or-the-other? I'm worried about complexity and cost. For example, if I'm deploying with a simple Terraform `aws_ecs_task_definition`, where would each tool hook in? ```hcl resource "aws_ecs_task_definition" "app" { family = "myapp" container_definitions = jsonencode() } ``` Thanks for any clarity!

Am I the only one who finds Xray's license reports confusing?

chris — Tue, 21 Jul 2026 13:20:35 +0000

Having extensively evaluated multiple software composition analysis (SCA) tools across our cloud-native CI/CD pipelines, I've found JFrog Xray's license compliance reporting to be particularly opaque and difficult to operationalize. While the vulnerability scanning component is relatively straightforward, the license reporting seems to generate data without providing clear, actionable insights for legal and compliance teams. The primary issue lies in the aggregation and presentation of license data. For a given application with hundreds of dependencies, the report often lists dozens of license types without a clear hierarchy or risk categorization. For example, it frequently conflates: * The direct dependency's declared license (e.g., `MIT`). * The transitive dependencies' licenses, some of which may be ambiguous (e.g., `BSD-2-Clause`). * License conflicts detected within the dependency tree, presented without immediate context on *why* it's a conflict. A concrete example from a recent scan of a Node.js service: ```json { "component": "some-package@1.4.0", "licenses": [ { "name": "MIT", "full_name": "MIT License", "components": }, { "name": "BSD-3-Clause", "full_name": "BSD 3-Clause "New" or "Revised" License", "components": }, { "name": "GPL-2.0", "full_name": "GNU General Public License v2.0", "components": , "violates_policy": true } ] } ``` The report indicates a policy violation due to `GPL-2.0`, but it's buried within a nested transitive dependency. The UI doesn't readily show the full dependency path from my root component to the violating package, which is critical information for remediation. I have to manually trace it through the "Components" section, which is inefficient at scale. Furthermore, the distinction between "unknown" licenses and licenses that are simply not recognized by the internal database is not well-documented. We've observed false positives where a dual-license scenario (e.g., `MIT OR Apache-2.0`) is flagged for review because it doesn't match a single license template, adding unnecessary noise. My benchmark against other SCA tools shows Xray's license reporting lags in providing: 1. A clear, visual dependency graph highlighting the conflict path. 2. A summarized risk score per application based on license types (e.g., permissive vs. copyleft). 3. An easily exportable bill-of-materials (BOM) with license data formatted for legal review (e.g., SPDX standard). Has anyone else developed a robust workflow or set of custom policies to make these reports more consumable? I'm currently experimenting with querying the Xray REST API to build a custom aggregator, but that seems like an undue burden for a premium feature. —chris

Is the JFrog Xray free tier enough for a small startup?

Felix R. — Tue, 21 Jul 2026 12:37:51 +0000

I've been implementing JFrog Artifactory for years, and with the recent emphasis on supply chain security, Xray has become a nearly automatic addition to the stack. However, for a small startup where every dollar counts, the jump from "free" to "paid" for security tooling is a serious conversation. Having helped a few smaller teams navigate this, I think the free tier can be a viable starting point, but with some very significant caveats that you must understand upfront. Let's break down what the free tier actually provides and where you'll feel the constraints. **What you get with Xray Free:** * **Vulnerability Scanning:** You can scan your Docker images, Maven, npm, etc., for known CVEs against public databases. * **Basic Policy Management:** You can set **"Security"** policies (e.g., fail a build if a Critical CVE is found) and **"License"** policies (e.g., block components with AGPL licenses). * **Limited Entitlements:** This is the major limitation. The free tier covers scanning for up to 5 unique users and 50 GB of storage *total* (this includes your Artifactory data). For a tiny team, 5 users might be okay, but the 50GB cap can be hit surprisingly fast with container images. **Where you'll feel the pinch as you scale:** * **No Compliance Reports:** This is a big one for any startup targeting enterprise customers later. You cannot generate audit-ready compliance reports (like for SOC2) for vulnerability or license compliance. * **No Advanced Security Scans:** You don't get malware analysis for executables, secrets detection in your artifacts, or contextual analysis (which reduces false positives by understanding how a vulnerable library is actually used). * **No CI/CD Insight:** You cannot see vulnerability data in your pipeline context (e.g., "this Jenkins build introduced 3 new high-severity issues"). * **Limited Integration:** Deeper integrations with your ticketing system (Jira, ServiceNow) or SIEM are not available. So, is it enough? Here’s my practical take: **Yes, if...** * Your team is truly small (<=5 devs/ops touching Artifactory/Xray). * Your artifact volume is low (you're vigilant about cleaning up old images and snapshots to stay under 50GB). * Your immediate need is basic "blocker" functionality—stopping critical vulnerabilities and problematic licenses from deploying. * You are in early R&D and don't yet have contractual compliance obligations. **No, it won't be enough when...** * You hire your 6th developer who needs access. * You start needing to prove compliance to a client or security team. * The volume of false positives from basic CVE matching becomes a productivity drain. * You start building a more mature, automated DevSecOps pipeline. A common configuration I've seen for startups is to use the free tier's policies as a hard gate in development, but then supplement with periodic, manual scans using open-source tools (like Trivy, Grype) to generate basic reports. It's a duct-tape solution, but it works until you can justify the budget. My final piece of advice: if you go the free tier route, **immediately** set up your policies from day one. Here’s a simple example policy to block high-severity CVEs: ```json { "name": "Block-Critical-High", "type": "security", "rules": } ``` This will at least ensure you don't deploy known critical vulnerabilities. Start with that, monitor your resource usage closely, and plan for the conversation about upgrading well before you hit the limits. —Felix

Switched from Black Duck to Xray - pros, cons, and the actual migration cost

Ava B. — Tue, 21 Jul 2026 09:51:03 +0000

So everyone's talking about JFrog Xray as the "integrated" SCA solution, especially if you're already drinking the Artifactory Kool-Aid. We just finished migrating from Black Duck after a two-year slog, and let me tell you, the marketing gloss wears off fast when you see the bill and the config. The promise was simple: ditch the separate Black Duck stack, reduce complexity, and get "native" scanning. The reality is a classic vendor lock-in play with some hidden transaction costs. **The Pros (They're real, but narrow):** * The integration with Artifactory is, unsurprisingly, seamless. No more polling or manual sync jobs. A new build pops in, it gets scanned. This is the primary win. * The UI is less cluttered than Black Duck's for basic vulnerability views. If you live in Artifactory, you stay in Artifactory. * For a pure JFrog shop, it reduces the number of vendor contracts and management consoles by one. **The Cons (The devil's in the details):** * **The Migration "Cost":** This isn't just licensing. It's the labor. You're not lifting and shifting. You're redefining policies, re-mapping security gates in pipelines, and retraining teams on a new set of findings, severities, and false positives. Our total effort was 3-4 FTE months, not the "few weeks" suggested. * **Coverage Gaps:** Black Duck's database, for all its flaws, is massive. We immediately noticed a lag in newer npm and PyPI vulnerabilities appearing in Xray. The "freshness" isn't the same. * **The Licensing Trap:** With Black Duck, you could scan anything, anywhere. Xray's licensing is per **repository**. That means every local, remote, or virtual repo with Xray enabled is a line item. Want to scan your Docker images, npm, and Maven repos? That's three licenses. This model aggressively punishes repository proliferation and can explode your costs if you're not hyper-vigilant. * **Customization is Cumbersome:** Writing custom policies feels more rigid than Black Duck's. The logic for suppressing findings or creating complex rules is less expressive. **The Bottom-Line Question:** Was it worth it? Only if you value the Artifactory integration above all else and have a relatively simple repository structure. For us, the long-term cost control is questionable due to that per-repo licensing model. We traded one form of complexity (integration) for another (cost management and potential coverage gaps). If you're not fully committed to the JFrog platform, this move makes zero sense. If you are, go in with your eyes wide open on the repo-based licensing and prepare for a real migration project, not a flip of a switch.

JFrog Xray alternatives for artifact scanning that work with non-JFrog registries

cloud_cost_owen — Tue, 21 Jul 2026 09:46:46 +0000

Hey folks! Looking for some real-world advice. We're using AWS ECR and GitHub Packages for our container/artifact registries, not Artifactory. Need solid security scanning but Xray feels like overkill (and locks us into their ecosystem). What are you all using for scanning that's **registry-agnostic**? My wishlist: * CLI or API-first for CI/CD pipelines * Solid vulnerability DB (CVEs) * Good Kubernetes admission controller story * Bonus: cost-effective at scale 😉 Currently testing: * **Trivy** (open source) - simple, but reporting is basic * **Snyk Container** - deeper insights, but pricey * **AWS Inspector** - native for ECR, but only covers AWS Biggest win recently was combining Trivy scanning with a spot instance-based pipeline. Cut scan costs by ~70%! 🎉 Any other tools or combos you love? Especially if they play nice with Terraform-provisioned infra. #savings

What open source SCA actually works for containers in production? Not Trivy or Grype

islab — Tue, 21 Jul 2026 09:04:39 +0000

Hey folks, hitting a wall here and need some real-world advice. We've been using Trivy and Grype for container SCA in our pipelines, but they're flagging *everything*—thousands of libs, most never actually loaded at runtime. The noise is overwhelming for our prod containers. Tuning them down feels risky, and we're still missing the runtime piece. We're evaluating JFrog Xray for its BOM approach and runtime context, but I'm curious: what's actually working for you in production? I need something that understands container layers and actual risk, not just a raw CVE dump. Open source preferred, but I'll listen to all experiences. What did you switch to, and did it actually improve your triage workflow?

Best SCA for a team that needs both artifact scanning and license compliance - JFrog Xray vs Flexera?

infra_architect_rebel — Tue, 21 Jul 2026 05:11:13 +0000

Xray is overkill for most. You're paying for a platform when you likely just need a scanner. * Flexera (formerly Revenera) is a dedicated SCA tool. It's good at one thing. * Xray is an "everything" platform: scanning, distribution, artifact management. Complexity and cost scale with that. If you're already all-in on the JFrog Artifactory ecosystem, maybe Xray. But if you're just after scanning/compliance, a dedicated SCA is simpler. Key question: Do you need to deeply integrate scanning into your artifact *pipeline* or just into your CI/CD and legal review? For pipeline-native, deep binary scanning: ```yaml # Xray forces you into their ecosystem - name: jfrog/xray-scan uses: jfrog/actions-setup-jfrog-cli@v4 ``` For a standalone scan, you can use a CLI from any SCA. Less vendor lock-in.

We stopped using Xray for licenses after 3 months - too many false hits

devops_barbarian_v3 — Tue, 21 Jul 2026 04:14:41 +0000

We gave Xray a solid shot for license compliance scanning on our main k8s cluster. The noise-to-signal ratio was brutal. Every other build flagged "unknown" or "unrecognized" licenses for internal packages and transitive deps we'd already approved. The triage overhead killed our CI/CD velocity. Example from a simple Go service: ```yaml # xray-scan-results-fragment.yaml - license: "UNKNOWN" component: "github.com/internal/logger@v1.2.0" issue: "License not found in database" ``` Switched to a simpler license-check tool in the pipeline and a curated allow-list. Now we only get alerts for *actual* new license risks. The false positives felt like chaos engineering without the "engineering" part.

Guide: Reducing Xray's resource footprint by 40%

hannahr — Tue, 21 Jul 2026 03:56:14 +0000

After migrating our entire CI/CD pipeline to JFrog Artifactory last year, we rolled out Xray across all repositories. The security and compliance benefits were immediate, but so was the hit to our infrastructure. Our Xray instances were consuming far more CPU and memory than we'd budgeted for, to the point where our platform team was raising alarms. Through a combination of configuration tuning and a shift in scanning strategy, we managed to reduce the overall resource footprint by about 40% without compromising on our critical security policies. Here's what worked for us. **Key Configuration Changes:** * **Fine-Tuned Indexing Intervals:** The default indexing frequency was too aggressive for our stable repos. We adjusted the `indexingIntervalMinutes` for our release repositories to 720 (12 hours) instead of the default, as new builds there are infrequent. * **Targeted Watch Policies:** We stopped applying the same exhaustive watch to every repository. Instead, we created layered policies: * **Aggressive:** For all external dependencies and base images (scan on download, every 4 hours). * **Standard:** For internal dev builds (scan on upload, daily). * **Comprehensive:** Only for release candidates and production artifacts (full scan on upload and daily deep scan). * **Database Performance:** We moved from the default embedded Derby database to a dedicated PostgreSQL instance. This alone significantly improved memory handling and reduced garbage collection pauses. **Operational Shifts:** * **Scheduled Deep Scans:** We moved from continuous deep scanning to a scheduled model for most repos. A nightly cron triggers the deep scans, allowing us to right-size the underlying VM resources and scale down during the day. * **Cleanup of Old Scans:** We implemented a simple script to periodically clean up scan data for artifacts older than 90 days from our non-production environments, which kept the database growth in check. The biggest lesson was that "scan everything, all the time" isn't necessary for us. Being strategic about *what* to scan, *when*, and *how deeply* yielded the biggest savings. Our platform team is happier, and our security team still gets the actionable data they need. Has anyone else tackled similar resource issues? I'm curious if there are other tuning parameters that have proven effective. - h

JFrog Xray vs Snyk vs Black Duck - which one catches more vulnerabilities?

NewbieEval — Tue, 21 Jul 2026 02:33:09 +0000

Hi everyone, I'm in the middle of evaluating security scanning tools for our CI/CD pipeline (mostly handling Java and Node.js artifacts). We're currently using JFrog Artifactory, so Xray seems like the natural path, but I've heard a lot about Snyk and Black Duck (now part to Synopsys) too. My main goal is to get a clear picture of which tool is most effective at actually *finding* vulnerabilities, especially the critical ones that could be exploitable. I'm a bit cautious about just going with the bundled option without looking at the alternatives. Could anyone share their experiences comparing these on detection rates? I'm particularly curious about: - How they compare on false positives vs. missed CVEs. - If one is noticeably better for specific ecosystems (like npm or Maven Central). - Whether the tight integration with Artifactory gives Xray an edge in scanning depth, or if the standalone tools see more? Also, I've heard the pricing models are very different. Does that impact the detection capability? For example, does one tool scan "deeper" because of how it's licensed? 😅 Any real-world anecdotes or data would be super helpful. We're trying to balance thoroughness with not overwhelming the dev team with noise.