Checkmarx vs Xray: which catches more vulnerabilities in CI?

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.

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.

That pipeline latency point is crucial and often overlooked. We also saw a big hit when we ran them sequentially. The fix for us was to parallelize the scans. We set up our pipeline so the Checkmarx SAST scan kicks off as soon as the code is built, and the Xray SCA scan runs concurrently against the dependency manifest. It shaved minutes off the critical path.

You're right about "actionable yield per minute of delay." For us, running Xray on every single commit became hard to justify for that exact reason. We moved it to a nightly scan for most branches, keeping it as a gate only for release candidates. The daily digest of library vulns is less noisy, and the pipeline stays fast for developers.

>catch as many real vulnerabilities as possible before deployment

That's the right goal, but from what I'm reading here, maybe the metric needs adjusting. It sounds like "real vulnerabilities" you can actually fix.

For our Node/React apps, Xray flags a lot in dev dependencies that we just can't change. But Checkmarx recently caught a real exposure in a config file that we fixed the same day. So the "more" part depends heavily on what you're allowed to patch.

Do you have more control over your own code or over upgrading libraries quickly? That might answer which one gives you more actionable results.

So for your JS/Spring Boot apps, does Xray flag a lot of CVEs in libraries like `react-scripts` or `spring-boot-starter-*` that you just can't upgrade? I'm new to this and setting up my own pipeline, and that's what I'm worried about with SCA tools.

>catch as many real vulnerabilities as possible before deployment

You're mixing up finding vulnerabilities with fixing them. For my team, an unfixable CVE in a third-party library isn't a "real" vulnerability, it's just noise.

In our Java apps, Checkmarx finds the actual problems we can solve. Xray finds a list of things we can't, often for months. So the one that "catches more actionable issues" is the one where "actionable" means you can actually do something about it today.

You're asking about "more actionable issues" but you're comparing two different layers of a problem. The actionable part depends entirely on who gets blamed when a vulnerability is exploited.

If it's a library flaw, you blame the vendor and pray there's a patch. If it's your own code, you're the one in the meeting explaining the breach. Checkmarx finds the things that get you fired. Xray finds the things you forward to a vendor support ticket that goes unanswered for months.

So for "actionable," count the findings your team has the authority and ability to fix before the next release. For most dev teams, that's your own code, not a library three layers deep in a transitive dependency managed by a framework team you've never met.

Exactly. The blame assignment is the real filter for action.

The one I'd add is when a library CVE *is* your fault. We had a case where Xray flagged a vulnerable logback version. Our own Maven exclusions were pinning it, overriding the safe BOM version. So the ticket came to us, not some upstream framework team. That's a rare case where the SCA finding is both urgent and fully actionable.

But you're right, it's usually a slow, external blame chain. A Checkmarx finding about mis-handled secrets means the meeting is in your calendar for tomorrow morning.

The "direct vs. transitive dependency" policy is the right starting point, but I've seen it backfire when a direct dependency is just a wrapper. You end up blocking a build for a CVE in `spring-cloud-something-bootstrap` that's functionally a transitive dep from a framework choice you can't change.

And that point about internally-facing services is spot on. We wasted weeks chasing library CVEs in admin panels that sit behind three layers of auth and a VPN, while a Checkmarx scan of the same service found we were logging full request bodies to CloudWatch. The noise from Xray completely obscured the actual fire.

Oh, that's a great question to start with, but the replies here are eye-opening.

I'm just learning about this too, and I'm realizing "more" doesn't mean "better" if you can't fix most of it. Like, if Xray flags 50 things in dependencies your team doesn't control, is that helpful or just stress?

For a newbie like me, the idea that Checkmarx might find fewer but more fixable problems in our own code seems way more practical. That makes the choice feel simpler.

Thanks for asking this, it's really helping me think about my own setup.

Totally agree with this breakdown. That "actionable yield" gap is the core of it.

We had the same thing with `spring-boot-starter-test` - Xray flagged a CVE in a nested logging library. The fix was to override the version, which then broke compatibility with another part of the test suite. That's a week of work for a dev dependency no one actually uses in production 😅

Your point about team authority is key. A Checkmarx finding in a controller creates a ticket for *us*. An Xray finding in a transitive dependency creates a ticket we have to send upstream and then wait. The former actually gets closed.

That's a really good example about the Maven exclusions. I'm trying to set up a pipeline now and that exact scenario - where we cause the problem ourselves - is what makes me nervous about ignoring SCA findings entirely.

But how do you practically decide when to act on that kind of finding? In your case with logback, was it just obvious because you saw your own exclusion rule in the POM, or did you need a senior dev to dig into the dependency tree to confirm it was "our fault"?

Great question, because that's the tricky bit in practice. In our logback case, the Xray report actually highlighted the path - it showed the vulnerable version was coming from *our* project's direct dependency, not from a transitive BOM import. That made it obvious we'd overridden it.

But honestly, for less clear-cut cases, we added a simple triage step in the pipeline. If Xray flags a CVE, the script first runs `mvn dependency:tree` for that artifact and checks if it's pulled in by a direct dependency *we* declared. If yes, it's an actionable ticket for us. If it's from some spring-boot-starter-parent three levels up, it gets tagged for review later. Saved us a ton of digging.

It's not perfect, but it helps separate the "our fault" noise from the "framework team's problem" noise.

Ah, the classic "blame it on the BOM" shuffle. Your triage step sounds sensible, but how many places actually enforce it? In my experience, that script gets written, then the person who wrote it leaves, and it quietly breaks on the next JDK update. Then you're back to getting tickets for library CVEs from 2018 in your transitive deps because no one remembers how to fix the triage.

Also, even if you *do* own the direct dependency, you're still often stuck. Upgrading one library to fix a CVE can mean pulling in a cascade of breaking changes across half your service. Then you're debating whether a low-severity CVE in a dev-only tool is worth a two-week refactor. The "actionable" filter gets fuzzy real fast.