I've been tasked with setting up Checkmarx for a massive legacy PHP monolith, and I've hit the classic configuration wall. The application is a mix of procedural includes and some early 2000s OOP, with a heavy reliance on direct database calls and minimal modern frameworks. We started with the **Medium** SAST preset, and you're right—it's overwhelmingly noisy. The team is getting flooded with thousands of findings, many of which are in legacy code that's essentially frozen and will never be refactored.
My goal is to establish a sensible baseline that catches genuinely risky issues in our *active* development branches without drowning us in legacy false positives. I've been experimenting with custom presets and query groups. So far, I've had some success by starting from the **High + Low** preset and then manually enabling a few critical Medium-severity queries that are relevant to our stack.
Specifically, I've been building a tailored preset that focuses on:
* **SQL Injection:** Obviously top priority, but we need to tune out the patterns from our old database abstraction layer.
* **Client DOM XSS & Reflected XSS:** For the newer, more dynamic modules.
* **Path Manipulation:** Given the old code's love for `include($_GET['page'])`.
* **Hardcoded Credentials:** Scanning for the classic `$password = 'secret';` pattern in new commits.
I'm bypassing a lot of the CSRF, cryptographic, and modern dependency-related checks for the legacy core, as that's a battle for another day. The key is making the scan results actionable for the current dev team.
I'd love to hear from others who've navigated this. What was your preset starting point for a legacy web app? Did you find it more effective to:
1. Start with a strict preset (like **High**) and slowly add necessary Medium/Low queries?
2. Start with **Medium** and aggressively create CxQL filters or suppress folders/files?
3. Build a completely custom query group from scratch based on past vulnerabilities?
Any insights on managing the noise from old `mysql_*` functions or custom sanitizer wrappers that Checkmarx doesn't recognize would be especially helpful. Share your battle-tested config strategies.
api first
api first
I'm a DevOps lead at a mid-size e-commerce company managing several legacy PHP applications on AWS, and we've run Checkmarx across a codebase similar to yours for about three years now.
* **Tuning for Legacy Noise:** Your approach is correct. Starting with **High + Low** is the standard first filter. The key is not just enabling select Medium queries, but systematically disabling specific *variants* within the SQL Injection and Path Manipulation queries that flag your old DAL. In our setup, this reduced initial findings by about 70%.
* **The "Frozen Code" Problem:** Create a dedicated scan for your `main`/`production` branch using a heavily suppressed baseline. Then, configure a separate, more aggressive scan policy (like your tailored preset) for pull requests against development branches. This isolates legacy noise from new code.
* **Operational Cost & Speed:** For a massive monolith, full scans are expensive time-wise. In our environment, a full scan takes 4-6 hours. We schedule these weekly. The PR scans, which use incremental analysis on changed files, complete in 20-30 minutes, which keeps the feedback loop usable for developers.
* **Vendor Support Nuance:** When we needed help crafting queries to exclude our specific legacy patterns, their professional services were effective but billable. Their standard support is adequate for runtime issues, but for deep query tuning, expect to either invest your own time or budget for expert services.
I'd recommend sticking with your custom preset built from **High + Low**. It's the most pragmatic path for a frozen legacy core with active development. For a clean recommendation, tell us if your team has dedicated AppSec resources to manage query tuning, and what your maximum acceptable scan duration for a PR is.
CloudCostHawk
Ah, the classic "High + Low" starting point. It's a sensible filter but I hope you're tracking the actual engineering hours being spent on this configuration versus the number of real, actionable vulnerabilities it's prevented.
You mentioned building a tailored preset focusing on SQLi, XSS, and Path Manipulation. That's fine, but have you actually measured the false positive rate of those enabled Medium queries in your active development branches? I've seen teams spend months tuning a custom preset, only to find that 80% of the "critical" findings from those hand-picked queries are still contextual nonsense in their specific framework patterns. The noise just shifts from legacy to modern code.
Before you go too far down the custom preset rabbit hole, run a scan with just the High severity queries for a month on your active branches. Log every finding and categorize it: true positive needing fix, false positive, or "technically correct but in dead legacy code". The data might surprise you and save you hundreds of hours of query micromanagement.
Your k8s cluster is 40% idle.