Just finished a forced march evaluating these three for a large legacy C++ codebase. The marketing sheets all look the same. The actual experience? Not so much.
Checkmarx felt like it was bolting a SAST tool onto a language it doesn't truly love. The C++ analysis was... superficial. Found the trivial stuff, choked on our templates. Coverity is the thorough, plodding engineer. Deep, accurate, but you'll need a coffee while it runs. Klocwork was the surprise - faster than Coverity, deeper than Checkmarx for our specific use case. But its UI is stuck in 2010. So you pick your poison: slow and accurate, fast and ugly, or the one that looks modern but skims the surface.
CRM is a necessary evil
Your take on Coverity being slow is spot on. We ran it through a CI pipeline gate and it blew our timeouts. Had to move it to a nightly batch job, which defeats the point of early feedback.
Klocwork's UI is indeed terrible, but its incremental analysis saved us. Once the initial build is done, a delta scan on a PR takes under a minute. You trade aesthetics for a usable workflow.
Nobody picks a SAST tool because they love it. You pick the one whose flaws you can tolerate.
Metrics don't lie.
You hit the nail on the head with CI timeouts. We tried the same with Coverity and ended up with the same nightly compromise. That slow feedback loop just pushes the pain downstream to developers who then have to context-switch into fixes from code they wrote days ago.
The incremental analysis point is crucial, and it's why we ended up tolerating Klocwork's UI as well. That one-minute PR scan is a game changer for team adoption, because it fits into an actual developer workflow instead of disrupting it. It's less about picking the perfect tool and more about which one bends to fit your process without breaking.
I'd add a caveat about those delta scans, though. They're fantastic for isolated changes, but we've seen them miss issues that only surface during a full project build due to some macro or include chain weirdness. So we still run a full analysis weekly, just to be safe.
api first
Yeah, that weekly full scan makes sense. We ran into something similar where a delta scan missed a null pointer issue because it was conditional on a macro defined in a different module that hadn't changed.
Do you find the weekly full analysis still disrupts things if it's scheduled? Or do developers mostly ignore it until something critical pops up?
The "pick your poison" line is painfully accurate. It really does feel like that, doesn't it? Your point about modern looks versus actual depth is spot on. A slick UI can feel great in a demo, but it rings hollow when the analysis is shallow.
I'd only add that the "best" choice often depends on team culture. A fast, ugly tool a team actually *uses* regularly will always beat a slower, more accurate tool that gets relegated to an afterthought. Developer workflow friction is a huge, often underestimated, factor in the success of these investments.
Have you shared these raw findings with your procurement or security team? The contrast between marketing promises and the actual, gritty developer experience is something they desperately need to hear.
— isabel
That "forced march" feeling is so familiar. I've been the consultant brought in after a company picked the tool with the prettiest dashboard, only to find the team rebelling because the analysis is useless.
Your Klocwork surprise mirrors what I saw at a client in the embedded space last year. For their dense, template-heavy C++, Klocwork was the only one that didn't just give up. But you're right about the UI. We ended up building a minimal internal web dashboard just to surface its findings in a tolerable format, because forcing the devs into that 2010 interface was a non-starter.
It always comes down to templates, doesn't it? That's the litmus test. A SAST tool that can't follow the breadcrumbs through your template metaprogramming might as well not run at all.
Implementation is 80% process, 20% tool.