What Checkmarx scan metrics should an AppSec team track to know if developers are actually fixing vulnerabilities versus just suppressing or ignoring findings?

This is like a hospital tracking whether patients are actually getting treated versus just being discharged with their symptoms marked 'resolved' on paper without ever receiving care — a dashboard that only counts open-case numbers going down looks identical whether patients are recovering or whether staff are simply closing charts to hit a target. An AppSec program has exactly this same blind spot if it only measures the count of open findings trending downward, without distinguishing whether that decline came from developers actually patching vulnerable code or from findings being marked 'false positive' or 'risk accepted' by whoever's under the most deadline pressure that sprint.

This distinction matters because the two paths — genuine remediation and suppression — produce identically improving numbers on a naive open-findings dashboard while representing completely opposite security outcomes, and the incentive structure around a hard CI/CD policy gate can quietly push teams toward the easier path. If a pipeline blocks merges on any open high-severity finding, and a developer under deadline pressure has two options — spend hours actually fixing the underlying code, or click 'mark as not exploitable' and unblock the merge in thirty seconds — a purely count-based metric can't tell you which option is actually being chosen at scale across an organization, even though the security posture implications are entirely different.

Step by step, the metrics that actually separate these two outcomes: first, track the disposition breakdown of closed findings specifically — what fraction were closed because the underlying code was actually changed (verifiable, since a genuine fix means the finding disappears on a *rescan* of changed code, not just a manual status flip) versus closed via a manual triage action like 'not exploitable' or 'risk accepted' with no corresponding code change. Second, track mean time to remediation specifically for findings that were closed via actual code fixes, separate from the time-to-close for findings resolved via suppression, since blending these two very different processes into one aggregate 'time to resolve' number hides whether real fixes are happening promptly or slowly. Third, track suppression rate per team or repository as its own explicit metric, and specifically its trend over time — a team whose suppression rate is stable and low is likely triaging genuinely non-exploitable findings correctly, while a team whose suppression rate is climbing sharply is very plausibly using suppression as a pressure-relief valve against the CI gate rather than as a considered security judgment.

At production scale, mature AppSec teams pair this metric tracking with a lightweight audit process — periodically sampling a percentage of findings marked 'not exploitable' or 'risk accepted' for independent re-review by someone other than the developer who made that original call, specifically because self-triage under deadline pressure has an obvious, well-understood incentive problem, and a random-sample audit is far cheaper than reviewing every single suppression while still catching a team whose suppression judgment has drifted from genuine security assessment toward pipeline-unblocking convenience.

The gotcha: a team's suppression rate can look completely reasonable in isolation — say, 15% of findings marked not-exploitable, which sounds plausible for a mature codebase with genuinely low false-positive noise — while still representing a serious, hidden problem if that 15% disproportionately includes the small number of findings that were actually the most severe and exploitable ones, since raw suppression *rate* alone doesn't tell you anything about the *severity distribution* of what's being suppressed. An AppSec program that tracks suppression rate as a flat aggregate percentage without breaking it down by severity can completely miss a team that's diligently fixing every minor finding while consistently suppressing the rare, genuinely critical ones — the overall number looks healthy while the actual residual risk profile is inverted from what the dashboard implies.