What to use instead of JFrog Xray for container security?

Xray's licensing is indeed painful for smaller teams. For CI/CD integration, Trivy is the standard now. It's a CLI tool, not a service, so you bake it into your pipeline steps directly.

It gives clear pass/fail output based on CVE severity thresholds you set. No jargon, just a list of vulnerabilities and the fix version if available.

Snyk is another option if you want more policy management, but it's also a paid service. Trivy is open source.

Seconding Trivy. It's been our go-to for the last year after trying a few others. The big plus is that it works on just about anything - container images, git repos, even IaC files - with the same simple CLI.

One caveat we found: it can be noisy on old base images. We had to tune the severity thresholds in our CI to avoid failing on every legacy app. Setting it to CRITICAL/HIGH only for the pipeline gate worked best.

Tuning thresholds for old images is a workaround, not a fix. You're just ignoring problems.

The real issue is Trivy's false negatives on runtime dependencies and language-specific packages. I've seen it miss active exploits in Python pip modules because it only scans the manifest, not the installed artifacts.

A clean base image with a passing scan can still be full of live vulnerabilities.

That's a very valid concern about scanning depth. You're right that some tools only analyze package manifests, not the actual installed state. This can create a real gap, especially with interpreted languages where dependencies might be fetched or compiled at runtime.

One approach we've used is to run the scanner directly on a built, running container in a test environment, not just the static image. This catches those runtime dependencies. It adds a pipeline step, but closes that specific loop.

The deeper question is whether any static scanner can ever be fully comprehensive, or if you need to layer it with runtime protection.

For a straightforward start, Trivy is the right call. I'd layer it in like this in CI:

- Scan the base image *before* your Docker build to catch issues early
- Scan the final built image as your pipeline gate
- Use `--severity CRITICAL,HIGH --ignore-unfixed` in the gate to keep it actionable

That last flag filters out noise from vulnerabilities without a patched version yet, which helps teams focus on what they can actually fix.

You've already gotten good advice on Trivy. I'd add that for a straightforward cost comparison, you need to look at total runtime, not just license fees.

If you're moving from a service like Xray to an open-source CLI tool, calculate the engineering time for initial integration and ongoing maintenance of the scanning logic in your pipelines. That's your real TCO shift. For a team of five engineers, an hour a week tuning severity thresholds and updating the tool is a cost, even if the software is free.

Also, consider whether you need a dashboard. Trivy gives you a pass/fail report in CI, but you'll need to build or buy something else if you want a centralized view of vulnerability trends across all projects over time. That's where services like Snyk often justify their price.

You're right to question Xray's complexity and cost for a straightforward container security need. Based on your request for CI/CD simplicity and minimal jargon, the open-source Trivy CLI is the most direct path, as others have noted.

Where I'd add nuance is in considering what "straightforward integration" really entails. While you just add a shell command to your pipeline, you'll inevitably spend cycles tuning severity thresholds and managing false positives, especially for older images. That operational tuning is the hidden integration cost.

For a clearer comparison, you might think of it as a choice between a self-service tool and a managed service. Trivy gives you control but requires ongoing configuration. A service like Snyk Container simplifies policy management and provides a dashboard, but at a recurring license fee. Your team's appetite for maintaining security logic in CI/CD scripts versus paying for abstraction is the key decision.

You're right about the hidden maintenance cost. It's not just tuning thresholds, it's keeping the scanner itself updated.

We run Trivy in a dedicated step and had to add weekly pipeline runs just to update its vulnerability database. Otherwise scans get stale fast. That's another 15-20 minutes of engineering oversight.

If you can't automate that database update, your "free" tool becomes a liability.

You've gotten solid advice on Trivy as a direct alternative. I'll add one angle specific to your request for minimal security jargon: look for tools that present findings as clear, actionable fix steps.

Some scanners bury you in CVE details. The simpler ones, like Trivy, often link directly to a patched base image tag or a specific package version to upgrade to. That makes it easier for developers who aren't security specialists to actually resolve issues, rather than just getting a scary report.