Checkmarx vs Xray: which catches more vulnerabilities in CI?

I'm a lead DevOps engineer at a mid-sized fintech (~200 devs) running Java Spring Boot and React microservices, and we've had both Checkmarx SAST and Xray (via Artifactory) in our CI pipelines for about two years now.

1. **Primary vulnerability focus.** Checkmarx primarily identifies custom code flaws (OWASP Top 10, business logic, hardcoded secrets), while Xray's core function is scanning dependencies for known library vulnerabilities (CVEs). They are complementary tools covering different risk layers. For a Spring Boot app, Checkmarx finds injection flaws in your controllers; Xray flags a vulnerable `log4j-core` JAR in your final container image.

2. **"Actionable" signal-to-noise ratio.** In our pipeline, Xray generates far fewer false positives for its domain because it's matching dependency hashes against CVE databases. Checkmarx requires significant tuning of its query set; out-of-the-box, it flagged ~30% false positives on our React code (e.g., JSX event-handler XSS findings that were sanitized by the framework). Reducing this to a manageable ~10% took about 80 hours of query tuning per major application.

3. **Integration and operational model.** Xray operates as a sidecar to Artifactory, scanning artifacts post-build. It adds ~45-90 seconds to our pipeline for image scanning. Checkmarx requires a dedicated build agent or container for its engine; a full scan on a medium-sized service (~100k LOC) takes 8-12 minutes, which forced us to move it to a nightly schedule rather than per-commit.

4. **Real cost structure.** Xray's cost is bundled with Artifactory (roughly $20-30/user/month for the full platform in our volume tier). Checkmarx is licensed per-developer seat with an annual scan quota; our last quote was ~$180/developer/year. The significant hidden cost for Checkmarx is the ongoing maintenance of scan configurations and triage, which consumes about 4-5 engineering hours per week across the team.

Given your goal to catch more real vulnerabilities before deployment, I'd recommend Xray first if you lack consistent SCA, as its findings are almost always critical and immediate to patch. If you already have solid SCA, then add Checkmarx for the custom code coverage, but only if you can dedicate the initial ~2 weeks for tuning its rules to your specific frameworks. To make a clean call, tell us if you already have a software composition analysis tool in place and what your team's weekly capacity for tool tuning and alert triage is.

Totally agree on the tuning overhead for Checkmarx. We saw a similar pattern with our Node.js services.

One extra point on Xray: its actionable rate is high, but you're dependent on the freshness of its CVE feeds. We've had cases where a critical vuln was public for days before it showed in our scans. We ended up adding a direct NVD webhook as a backup.

> Reducing this to a manageable ~10% took about 80 hours of query tuning

That's a solid benchmark. For anyone reading, that time isn't just one-off - you'll need to reinvest some hours after major framework updates.

You're asking the wrong question. "Which catches more" assumes they're in the same race. They aren't. It's like asking whether a smoke detector catches more fires than a carbon monoxide sensor. The overlap is minimal.

Checkmarx looks at the code you write. Xray looks at the packages you download. For a typical Spring Boot app, you'll get a handful of meaningful Checkmarx findings after significant tuning (SQLi in a custom repository method, maybe a path traversal in a file upload), and Xray will dump a list of 50 CVEs from your bloated container image, 45 of which are in test scopes or have compensating controls. The "actionable" issues from Xray are only actionable if your development process actually allows you to upgrade a major framework version three days before a release, which is rarely true outside of greenfield startups. Checkmarx findings, when they're real, force you to change your own logic, which is often a harder sell but a more valuable fix.

So no, one doesn't consistently find things the other misses. They operate in completely different layers of your stack. Using only one leaves a massive blind spot, and judging them by raw vulnerability count is a fantastic way to drown your team in noise and paperwork.

You're right to focus on actionable issues, because that's where the real work happens. Everyone else has nailed the SAST vs. SCA difference, so I'll share a tactical angle from our JavaScript setup.

We run both for a React/Node stack. Checkmarx might flag a potential XSS in our form handling, which is great. But Xray catches the vulnerable `lodash` version our design system pulled in, which is often the more urgent, fire-drill fix. They truly don't overlap much.

One thing that helped us: we treat Checkmarx findings as code review items (fix or justify), while Xray vulns with a high CVSS break the build. This separation made the alerts feel more "actionable" for each team. Have you considered setting different pipeline gates for each tool?

Absolutely nailed the analogy. The smoke detector vs CO sensor is spot on.

Where this gets really messy in practice is when you're responsible for a marketing site or landing page repo. My team runs a React-based site with 50+ third party marketing libs (analytics, chatbots, personalization). Xray lights up like a Christmas tree, but *truly* actionable items are near zero because we can't just swap out the Intercom SDK on a whim during Q4 campaign season.

The Checkmarx findings for our custom code, while fewer, actually get fixed because they're isolated to our components. So "actionable" ends up being less about severity and more about... organizational velocity to change a dependency.

Yesss, the organizational velocity point is so real. We see the same with marketing automation tool embeds. Xray flags a CVE in a third-party chat widget's library, but the fix is a full vendor update cycle away.

It forces a weird triage: we mute those Xray alerts for "approved" external scripts, which feels wrong. But you can't have a broken build because of a tracker you don't control.

Makes our handful of custom Checkmarx findings, where we own the fix path, way more valuable.

Totally agree that focusing on actionable issues is the right approach. We're looking at a similar setup with Spring Boot and React, and one thing that's been tricky is that Xray might flag a critical CVE in a library, but it's only actionable if we can actually upgrade it right then. Sometimes a library is locked to an older version by another dependency, so you get the alert but can't fix it for weeks, which feels like the noise you're worried about.

For Checkmarx, we've found it's good at catching the basics in our custom code, but it does require a lot of initial tuning for our specific framework patterns. Did you find one tool was easier to get a "clean" baseline for, without having to mute a ton of false positives from the start?

You're already framing this wrong. "Catches more" is a metric for sales demos, not production pipelines.

The real question isn't about volume, it's about *control*. Checkmarx finds bugs in code you own. You can fix them, or at least argue with the developer who wrote it. Xray finds problems in code you imported, where the fix is often begging a vendor or waiting six months for the next major version.

For Spring Boot, half your "critical" Xray findings will be in transitive test dependencies or libraries you can't upgrade without a full architecture committee review. The Checkmarx finding for a missing authorization check in your new endpoint? That you can patch before lunch.

So the tool that catches more actionable issues is the one whose findings you're actually *allowed* to act on. Usually that's neither, because both get tuned into submission to keep the build green.

That's a really good point about them being different layers. So if you had to choose just one for a new pipeline, maybe because of budget, which layer is more critical to cover first? Our own code, or the dependencies? I'm guessing it depends on the app, but I'm not sure how to decide.

I'm in a similar boat, trying to sort this out for our new pipeline. Everyone's saying they're different tools for different layers, which makes sense, but I'm also confused about the noise part.

For a Spring Boot app with a lot of dependencies, will Xray just drown us in alerts we can't fix right away? I'm worried we'll start ignoring everything. But if Checkmarx only looks at our custom code, are we missing the bigger risk from libraries?

What's been your team's tolerance for that kind of alert backlog? Does it just become background noise?

You're right to be worried about noise, that's the killer with these tools. We run both for a similar Spring Boot/React stack.

> which one actually catches more *actionable* issues

I'd flip that: Xray catches more *issues*, Checkmarx catches more *actionable* ones, at least in our setup. For our custom Spring Boot services, a Checkmarx finding about an insecure direct object reference in a controller is something we can patch in the same sprint. Xray will flag 20 library CVEs, but if half are in a transitive dependency of `spring-boot-starter-test`, we're stuck with them until the next framework upgrade.

The gap is real with JavaScript frameworks too. A vulnerable version of `webpack-dev-server` might get flagged, but swapping it can break half the team's local dev environment. The "actionable" part depends entirely on your team's authority to change dependencies versus owned code.

You nailed the dependency hell with `spring-boot-starter-test`. We ended up creating a separate "build only" policy in Xray for those test and dev scoped dependencies. It still scans them, but findings don't break the build or even alert devs. It's a band-aid, but it cut the noise by about 40% for our Java services.

That "authority to change" point is key though. Our frontend team can't just bump `webpack-dev-server` either. Their actionable findings from Xray are near zero, so they ignore the dashboard. Meanwhile, a single Checkmarx finding about a hardcoded API key in their config gets fixed in hours because they own it.

No tool helps if the org can't, or won't, act on the results.

You're asking the wrong question. Actionable issues are about control, not volume.

For your Spring Boot and JavaScript stack, Xray will flood you with library CVEs you can't fix. A critical in a transitive test dependency isn't actionable. Checkmarx will flag fewer items, but they're in code your team wrote. You can fix a misconfigured Spring Security rule this sprint.

The one that catches more actionable issues is the one where you own the remediation path. That's almost always your own code first.

You're comparing two different types of tools for overlapping, but distinct, problems. Checkmarx is a SAST tool analyzing your source code, while Xray is primarily an SCA tool analyzing your dependencies. The question of which "catches more" actionable issues is fundamentally about your team's remediation control.

For a Spring Boot app, Xray will identify many more total issues, but as others noted, a significant portion will be in transitive dependencies you cannot immediately change. Checkmarx will report fewer issues, but they will be in your custom controllers and services, which your team can fix directly.

Regarding your specific question about one finding things the other misses, that's a guarantee. SAST will miss library vulnerabilities; SCA will miss your custom business logic flaws. They are complementary layers. If you must choose one, the decision hinges on whether you perceive greater risk from your own code or from your dependencies, and which one your organization has the authority and process to actually fix.