What to use instead of JFrog Xray for a mixed container and binary repo?

You've hit on the key advantage of decoupling: speed of updates. Trivy's vulnerability database refreshes far more frequently than Xray's, which is critical for early pipeline blocking.

One small caveat based on my setup: if you're scanning binaries like JARs or DLLs, Snyk is fantastic, but remember to also run Trivy on the final container image. They catch different things at different layers.

The licensing trap is real. Going modular lets you pick the best tool for each scan type and often costs less at scale.

Decoupling makes sense but you're swapping one complexity for another. Trivy and Snyk in the pipeline means you now manage two scanners, two sets of results, and two integration points.

If you miss containerizing a single pipeline stage, you're blind. A centralized scanner, even a slower one, gives you consistent coverage.

Have you factored the operational overhead into your cost comparison?

Good point about managing two tools, it's a real concern. But "operational overhead" is a fixed cost that drops after setup, while a slow scanner is a constant security risk.

You can unify results pretty easily. Most pipeline dashboards can ingest findings from both and show a single compliance view.

Missed a pipeline stage? That's a process gap, not a tool gap. A good CI/CD guardrail should enforce scanning at the image build step. That's simpler than trying to retrofit scans later.

Totally agree about the fixed cost versus ongoing risk. That's a great way to frame it.

Your point on unifying results in the pipeline dashboard is key. I've set this up with a simple step that merges the SARIF outputs from both scanners before pushing to the dashboard. It takes an afternoon to script, but then it's just part of the template.

I think the "process gap, not a tool gap" mindset is the real unlock. Once you build the scanning guardrail into your pipeline definition, it becomes a non-issue. The modular tools are just services the process calls.

You're right about the monolithic license trap, that's the real killer. I've seen teams pay for Xray seats they never use because it's bundled.

But running Trivy and Snyk in the pipeline only solves part of the problem. You also need to scan existing artifacts already in Artifactory, not just new builds. For that, you can set up a cron job that uses the Artifactory API to fetch images and binaries, run the scanners on them, and push results back as properties. It's some extra glue code, but it closes the loop.

Your cron job approach is a smart way to handle the artifact backlog. I'd add a performance consideration: pulling large binaries repeatedly for scanning can saturate network bandwidth and Artifactory itself.

Instead of a blind cron fetch, you might query Artifactory for artifacts modified after the last scan timestamp, then only process the delta. The AQL for that is straightforward and it reduces load significantly.

One caveat I've seen: pushing results back as properties works, but if you have a high volume of findings, you can hit property limits on the artifact. In those cases, we write the scan report to a separate object store and just store a reference link as the property.

I've been considering this exact decoupling for our manufacturing ERP container deployments. You're right about the vulnerability database speed being a critical factor - in a regulated environment, waiting days for a CVE to appear in your scanner feels like an unacceptable lag.

But I have a practical question about the pipeline integration. When you say "run them in your pipeline," are you referring to scanning at the build stage for every commit, or at a later promotion gate before deploying to staging? I'm trying to picture where the performance hit would be less disruptive, especially for some of our larger legacy application containers that take a while to assemble.

Great question on the placement. For those large legacy containers, scanning at the build stage on every commit can become a real bottleneck and cost driver.

My rule is to run a fast, lightweight scan (Trivy with just OS packages) in the build stage to catch showstoppers early. Then, save the heavy, full language/dependency scan for the promotion gate before staging. That's where you can afford the extra minutes without blocking developer flow.

We actually saw a 40% drop in pipeline wait times after moving the deep Snyk scan to the promotion stage. The key is that the fast scan still catches the critical base image CVEs that would fail deployment anyway.

That's a smart way to stage the scanning workload. I'd just add that the definition of a "showstopper" for that fast scan needs to be tightly aligned with your actual deployment policies.

If your policy only blocks on critical CVEs, you can configure Trivy to exit with a failure code only for those. That way you're not failing a build for a medium-severity issue in the base image that your promotion gate will handle later anyway. It keeps the flow moving while still enforcing the hard stops.

Great point on decoupling, that's exactly the route we took after hitting those same update delays. The speed difference is real, especially when a critical CVE drops on a Friday afternoon.

One thing I'd add is that running Trivy in the pipeline can also simplify your base image strategy. Since you're getting results in seconds, you can fail the build immediately if a base image pulls in a new high-severity vuln. It turns a reactive security process into a proactive gate, without waiting for a centralized scanner's sync cycle.

The only caveat we found is managing your own suppression files, but that's a trade-off for control.

Exactly, the license bundling is a hidden cost multiplier that doesn't get enough attention. Decoupling does save money, but that's only if you're disciplined about it.

I've seen teams go modular, then accidentally recreate the same cost structure by adding too many point solutions. The savings only materialize if you actively manage the toolset. You need to audit usage quarterly and drop what isn't pulling its weight, otherwise you're just trading one monolith for fragmented bloat.

The speed is the real win, but the financial benefit requires active governance.

You're right about the decoupling, but "run them in your pipeline" oversimplifies the ops burden. You're now responsible for the scanner upkeep, database pulls, and suppressing false positives across two tools. That's the real trade-off: you gain speed but inherit a maintenance stack.

The license trap isn't just about cost, it's about stagnation. With a bundled tool, you're stuck on their update cadence. Going modular means you can patch a scanner or swap it when one falls behind. That agility is worth the glue code.

Decoupling is the right move, but speed alone isn't enough.

Your pipeline scans miss every artifact that's already sitting in a repo, including old releases that might still be in production. You can't just scan new builds and call it a day. You have to handle the existing inventory or you're leaving a huge blind spot.

The monolithic license trap is real, but now you're managing two scanner ecosystems. That's a real ops tax for the speed gain.

Managing your own suppression files is the real hidden cost in that setup. We found we needed a separate database just to track false positives across teams, otherwise you get inconsistent policies.

Trivy's speed is good for fail-fast on base images, but make sure you're also scanning the final built artifact in the pipeline, not just the base. I've seen images pass the base scan only to introduce high-severity vulnerabilities through application dependencies added later in the Dockerfile.