You're correct to worry about alert fatigue. For a typical Spring Boot app with a lot of dependencies, Xray *will* drown you if you don't configure it aggressively from day one. The backlog becomes background noise within weeks, and then you miss the one critical, actionable CVE in a core library because it's buried.
You need to decide on a policy for what actually breaks the build. We treat any finding in a direct production dependency as a blocker. For transitive or test-scoped dependencies, we log them to a dashboard but don't gate the pipeline. That's the only way to manage it.
On the flip side, the risk from libraries is often overstated for internally-facing services. A Checkmarx finding in your auth logic is a direct, immediate hole. A library CVE might require a specific, often unlikely, exploitation path through your app. Cover your own code first, because you can actually fix it.
Show me the benchmarks.
You're already getting the right advice about them being different layers, but let me put some concrete numbers to it from a pipeline I just tuned.
For a typical Spring Boot service with 150 direct dependencies, Xray flagged 87 CVEs last month. Of those, we could actually fix 4. The rest were in transitive dependencies locked by Spring Boot BOM versions, or in test scopes where we decided the risk was acceptable. Checkmarx flagged 12 issues in our code, and we fixed 9 before the next release.
The "catches more actionable issues" metric depends entirely on your team's authority to change dependencies versus your own code. If you can't force a library upgrade without a six-month governance process, Xray's findings are just a depressing report. The Checkmarx finding about your service leaking PII in an error message? That's in your git repo, and you can have a PR merged by tomorrow.
They don't consistently miss things the other finds; they're designed for completely different attack surfaces. The real problem is when Xray misses a vulnerability because it's using a stale CVE database, or Checkmarx doesn't understand your custom framework. That's where you need to look at update frequency and language support, not just volume.
You're framing this in a way that misdirects your pipeline's purpose. The question "which catches more actionable issues?" implies a single tool competition, but the synergy, or more critically the performance overhead and pipeline latency, is what you should be measuring.
For your Spring Boot/JS stack, you'll get more raw *findings* from Xray, but most are non-blockers in transitive dependencies. Checkmarx will give you fewer, higher-fidelity alerts in your business logic. The real metric isn't count, it's **mean time to remediate**, and for issues your team directly owns, Checkmarx wins because the fix path is a code commit, not a vendor library upgrade blocked on other teams.
From a pipeline performance perspective, running both serially adds significant latency. We saw a 4-7 minute increase per build stage. The actionable yield per minute of pipeline delay heavily favored Checkmarx for our services, as the Xray scan often ran just to confirm we were still vulnerable to library CVEs we couldn't immediately patch.
If you must choose one, choose based on which layer you have the most immediate control over. For most teams, that's their own code.
--perf