Checkmarx vs Xray: which catches more vulnerabilities in CI?

That's a really good point about maintenance. I've seen similar scripts get abandoned and then you're back to drowning in alerts.

But could you build that triage logic into the tool itself? I know some SCA tools have policy rules, but maybe they could automatically tag findings based on dependency ownership. That way it wouldn't depend on one person's custom script.

It still doesn't solve the upgrade cascade problem, though. How do you even estimate that refactor risk early on?

Yes, Xray will absolutely flag those, and the upgrade problem is real, especially with `spring-boot-starter-*` BOMs. The library CVE you can't immediately fix is the default state.

But that's not a reason to avoid SCA. The real step is to configure your policies. You should set Xray to fail builds only for high-severity CVEs in *direct* dependencies you declare in your pom.xml or package.json. Everything else gets a warning. This turns the flood into a manageable list of issues you actually own and can prioritize.

For react-scripts, the chain is often longer and the fixes are more disruptive. You'll get CVEs in transitive dev dependencies you'll never patch because it would require moving off an entire toolchain version. That's noise. Filter it out from the start. The actionable finding might be a vulnerable version of `webpack-dev-server` you directly added, which is a different and rarer case.

The answers you're getting are good, but they're missing a key point about your core question. It's not "which catches more," it's "which tool catches the *type* of vulnerability you can actually fix."

Checkmarx finds flaws in the code you write. A SQL injection in your Spring Boot controller is something your team can fix tomorrow.

Xray finds flaws in the libraries you use. A CVE in a transitive Jackson dependency three levels deep might be impossible to patch without a major framework upgrade.

For actionable issues, Checkmarx wins by default because its findings are 100% owned by your dev team. Xray's findings are often owned by someone else, or are in libraries you can't feasibly change.

For your stack, expect Checkmarx to be strong on Spring Boot logic flaws and Xray to light up your node_modules folder. They catch fundamentally different things. If you can only pick one, go with the tool that finds bugs in *your* code first. You can always add an SCA policy later for critical direct dependencies.

You're spot on about pipeline latency. That 4-7 minute increase is the hidden cost of "coverage."

Our team tried the same parallel scan setup. We ended up dropping the Xray CI-blocking step and running it nightly as a separate, async report. It still finds the library CVEs, but it doesn't hold up the build. Checkmarx runs in-CI because those findings demand immediate attention and a fix is usually a 30-minute code change.

The performance tax is only worth it if the tool's findings are actionable within the same pipeline run. Otherwise you're just adding friction for a report no one looks at until the quarterly audit.

That "hidden cost" you mention is the whole ballgame. Parallel scans double your compute minutes. If you're on AWS CodeBuild, that's a direct 2x multiplier on your bill for every commit.

Running nightly async reports instead of blocking the build is smart. But you still have to pay for the compute time. And if no one acts on those nightly reports, you're just burning money to generate ignored data.

Checkmarx being fast enough for inline CI makes it the cheaper option, even before you count the value of actual fixes.

You're focusing on the compute bill but missing the human cost. We already pay for the nightly scans, but the ignored reports create a culture of alert fatigue. Devs start skipping the Checkmarx findings too because it's all "security noise."

Cheaper compute time is pointless if your team is trained to ignore the results. At least with Xray's noisy library CVEs you can filter and prioritize. If Checkmarx is fast but your devs treat it like a nuisance, you're still not fixing anything.

Everyone's missing your actual question. You asked which catches more.

It's Checkmarx, by volume. But half those findings will be "Potential XSS" in code that never touches user input because their data flow analysis gets lost in modern JS frameworks.

Xray catches fewer total issues but they're almost always real CVEs. You just can't fix most of them.

So you're trading a flood of maybe-problems in your code for a list of real-problems in code you don't own. Pick your poison.

You're comparing apples to oranges. Checkmarx finds bugs in your code. Xray finds bugs in other people's code.

For Spring Boot, Checkmarx will catch your custom logic flaws. Xray will light up your pom.xml.

If you want *actionable*, you need both, but run them differently. Put Checkmarx in your PR gate. It's fast enough and your team can fix those findings. Run Xray nightly and filter to high-severity direct dependencies only. Otherwise the noise will drown you.

They don't overlap. Checkmarx misses library CVEs. Xray misses your custom vulnerable code.

Exactly. The ownership angle is critical for prioritization. A team can fix their own SQL injection in a sprint. They can't fix a transitive library CVE if the fix depends on an upstream framework release.

But there's a gap in that logic: some findings are in code you *do* own but Checkmarx might miss. For instance, a custom insecure deserialization method in a shared internal library. It's your code, but if your scan only covers the main app, it's invisible. That's where dependency scanning for *your own artifacts* gets tricky.

You hit on something important with alert fatigue. We saw the same pattern, and it forced us to actually tune the tools instead of just running them.

>Cheaper compute time is pointless if your team is trained to ignore the results.

Exactly. A fast, ignored scan is worse than a slow, actionable one. We fixed this by creating "starter" policy templates for both tools - Checkmarx rules that focus on critical/high in new code only, and Xray rules that flag direct deps. The initial flood stops, and the remaining findings feel like legit tickets, not noise.

It's a configuration and expectation problem first, a tool problem second.

I've run this exact combo for a Spring Boot and React pipeline, so I can share what we saw.

The actionable findings were almost entirely from Checkmarx, but with a big caveat. The "SQL injection in your controller" example is spot-on. Those are quick wins. For JavaScript frameworks, Checkmarx gave us a lot of "Potential XSS" flags in our React components, but about half were in code paths that never actually rendered user input - still, the other half pointed us to real validation gaps.

Xray lit up our dependencies, but as others said, most were in transitive libraries we couldn't patch. The actionable bits from Xray were the few high-severity CVEs in our *direct* dependencies, which we could upgrade. So in practice, Checkmarx gave us 10x more tickets, but we could fix 8 of them. Xray gave us fewer tickets, but we could only fix 1 or 2.

They truly don't overlap much. You need both views, but you have to route the findings to different teams.

Everyone's focusing on volume, but you should be asking about precision. Checkmarx will bury you in "Potential XSS" warnings for your React code, most of which are dead ends because it can't track state through hooks properly. Xray's findings are concrete CVEs, but good luck getting a business case to refactor a core library for a medium-severity issue.

You want to catch more *real* vulns? You'll get more from Checkmarx, but only if you have the patience to sift through a mountain of false positives. The real question is whether your team will actually do that, or just start ignoring the scanner entirely.

You've put your finger on the core of the problem: actionable control. The distinction between "your code" and "their code" dictates the entire workflow.

Your example of fixing a config file exposure the same day is perfect. That's a direct productivity win because the authority and the fix are in the same hands. The library CVEs flagged by Xray, especially in dev dependencies, often belong to someone else's roadmap.

But there's a middle ground you can influence. Even with libraries you "can't change," you can sometimes implement compensating controls or adjust your usage of the vulnerable function. That turns an unactionable Xray finding into something you can address, though it requires more security expertise than a simple version bump.

That point about compensating controls for library vulnerabilities is a key one, but it shifts the workflow burden. It moves the fix from a developer's quick version bump to a security architect's design review, which is a much heavier lift.

So while an Xray finding can sometimes be made actionable, it's a different kind of action - one that often stalls because it requires coordination and specialized knowledge, not just a ticket assignment.

"Cheaper option" assumes the findings are good. If Checkmarx's speed just means your team learns to ignore the flood of maybe-fixes faster, you're paying to train people to ignore security. A slow, expensive scan that gets fixed is cheaper than a fast one that trains apathy.