Interesting question! As someone also looking at setting this up, I'm curious if the "noise" people mention is mostly about JavaScript scans. For Spring Boot, does Checkmarx still generate a ton of false positives, or is it more precise there?
Great question on the frameworks, because that's where the experience really diverges.
For Spring Boot, Checkmarx is noticeably more precise in my testing. The data flow analysis understands the framework's patterns better, so the findings for things like command injection or path traversal are often spot-on and quick to verify. You'll still get some noise around validation, but it's manageable.
Xray's value for Spring Boot is almost entirely in the dependency tree. It'll catch a vulnerable Log4j or Jackson version that Checkmarx wouldn't flag as a code issue. So they're genuinely complementary there, not overlapping.
What's your team's tolerance for tuning? Because that's the real decider for JavaScript noise.
Interesting you ask about actionable issues, since that's the key. For us, Checkmarx finds the vulns we can actually fix quickly, like a misconfigured endpoint. Xray tells us we have a vulnerable library, but then we're stuck waiting on an upstream update.
For modern JavaScript, Checkmarx's noise is real, but we found tuning it to only flag high confidence findings on new code helped a lot. It's not a set-and-forget tool.
Do you have a process for triaging false positives already, or would this be starting from scratch?
>an unfixable CVE in a third-party library isn't a "real" vulnerability
That's the exact mindset that leads to the next Log4Shell. The vulnerability is very real; the friction is just higher. The operational difference you're highlighting is between direct control and indirect influence.
Where I see teams falter isn't in the classification, but in the next step after the Xray finding. If your only action is "wait for a patch," then yes, it's noise. But there are other levers: risk acceptance with documented compensating controls, isolating the vulnerable component, or even forking and patching it yourself for critical issues. Calling it unfixable prematurely is a process failure, not a scanner failure.
The actionable difference, therefore, comes down to your team's willingness to operate beyond the low-hanging fruit.
Less spend, more headroom.
You're framing the comparison incorrectly by asking which catches more. They target fundamentally different layers of the software supply chain, so they are complementary, not competitive. The "actionable" question is the right lens, but actionability is a function of your team's authority and your pipeline's gate design.
For your Spring Boot apps, you need both. Checkmarx will find flawed logic in your custom controllers and service layers, while Xray will flag the vulnerable `spring-core` or `commons-text` dependency you imported. Neither tool can see the other's domain.
The noise problem with JavaScript and Checkmarx is largely about its static analysis struggling with dynamic imports and framework-specific data flow. It requires significant tuning of the query suite to reduce false positives, which becomes an ongoing operational tax. Xray's findings on `node_modules` are more binary, but as others noted, the actionability is often blocked upstream.
The integration complexity is the real hidden cost. A mature setup uses Xray to fail the build on critical CVEs in direct dependencies, and uses Checkmarx findings as mandatory review items, not automatic gates, due to the false positive rate.