Skip to content
Notifications
Clear all

Checkmarx review: real SAST performance on a large monorepo

2 Posts
2 Users
0 Reactions
0 Views
(@danielh)
Estimable Member
Joined: 3 weeks ago
Posts: 117
Topic starter   [#23237]

So, we've all seen the demos on small, clean repos. But what happens when you point a heavyweight SAST tool like Checkmarx at a *true* monorepo? I'm talking 5+ million lines, multiple languages (Java, Python, JS/TS, Go), and a decade of legacy code. My team just wrapped up a six-month rollout, and the results were... enlightening.

Here’s the raw performance breakdown from our pipeline integration:

**The Good:**
* **Accuracy was solid.** Once tuned, the false positive rate for criticals/highs dropped to a manageable ~15%. The CxQL language is powerful for writing custom rules to catch our specific anti-patterns.
* **Incremental scanning** saved us. Scanning only changed files between commits kept most pipeline runs under 20 minutes. The full scan (weekly) still takes ~4 hours, but that's acceptable.
* **GitHub Actions integration** was smoother than expected. The plugin handles the delta logic and PR comments automatically.

**The Pain Points:**
* **Initial setup was a beast.** The `.cxconfig` file became crucial to exclude generated code, third-party libs, and test directories. Without it, scans were uselessly noisy.
```yaml
# .cxconfig snippet
ExcludeFolders: node_modules, dist, target, *.test.js
Preset: "All"
ProjectVulnerabilityThreshold: {
High: 0,
Medium: 10
}
```
* **Memory hunger.** The scan engine needed a dedicated 32GB RAM runner for our monorepo. Our 16GB nodes kept failing.
* **Custom rules are a double-edged sword.** They're powerful, but you *need* to own the maintenance. Our rule to flag a deprecated internal auth method needed updating twice in six months.

**The Verdict:**
It’s capable, but not plug-and-play for a large, messy codebase. The investment in tuning and infrastructure is significant. If you're in a similar boat, **start with a focused POC on your most critical service first**—don't try to boil the ocean on day one.

Has anyone else run it at this scale? How did you handle the resource scaling, and did you find the ROI justified after the tuning phase?


Keep deploying!


   
Quote
(@ci_cd_crusader_v2)
Reputable Member
Joined: 3 months ago
Posts: 209
 

You buried the lede. "Once tuned" and "incremental scanning saved us" are doing a lot of heavy lifting there. That six-month rollout and the massive `.cxconfig` are the real story. I've seen teams spend more time curating the exclusion list and writing custom CxQL than actually fixing legitimate issues. The tool becomes its own maintenance project.

And a 4-hour full scan weekly? That's a massive resource sink for a self-hosted runner pool. I hope you're not paying per-minute on some cloud offering. The moment your monorepo grows another million lines, that "acceptable" time balloons and you're back re-architecting your entire scanning schedule.


null


   
ReplyQuote