How would you automate a Checkmarx policy gate in payments-api's CI/CD pipeline so it blocks merges on new critical findings without also blocking on pre-existing technical debt that predates the gate?

Introducing a strict security gate into an established codebase is like a city suddenly enforcing a new building code retroactively on every existing structure — if every building built before the new code has to be brought into full compliance before anyone can pull a permit for anything, construction across the entire city grinds to a halt on day one, even for perfectly reasonable new projects that have nothing to do with the old buildings' problems. The sensible approach cities actually take is grandfathering: the new code applies in full to new construction and any building undergoing major renovation, while existing structures are handled through a separate, planned remediation timeline rather than an instant, blanket freeze. A Checkmarx policy gate needs exactly this same grandfathering design, or it becomes an organizational non-starter the moment someone realizes turning it on immediately blocks every single merge across a codebase that's accumulated years of pre-existing findings.

This baseline-then-gate-on-new-only approach exists because the alternative — gating on total open finding count from day one — creates a perverse, predictable outcome: teams facing an instantly-blocked pipeline either revolt against the security gate entirely and get it disabled, or they burn enormous effort on an emergency backlog-clearing sprint that displaces actual planned work, or worst of all, they mass-suppress the entire existing backlog just to get the gate to pass, which defeats the purpose of having accurate finding data at all. None of these outcomes are what the security team actually wanted when they introduced the gate — the goal was preventing new risk from entering the codebase, not an ultimatum to fix years of debt overnight.

Step by step, implementing this correctly: first, run a baseline scan against the current state of the target branch (main) before the gate becomes enforcing, and treat every finding present at that baseline scan as accepted, pre-existing technical debt — tracked and visible, but explicitly not blocking. Second, configure subsequent scans (on pull requests or merge commits) to diff their findings against that baseline using each finding's similarity ID (a stable identifier Checkmarx computes based on the code location and pattern, which persists across scans even as line numbers shift from unrelated code changes elsewhere in the file) rather than comparing raw finding counts, since raw counts can't distinguish 'a pre-existing finding that just moved because of an unrelated edit two lines above it' from 'a genuinely new finding introduced by this specific change.' Third, the actual policy gate logic checks only the delta — any similarity ID present in the new scan but absent from the baseline is treated as newly introduced, and it's this delta set, not the total open-finding count, that the merge-blocking threshold evaluates against.

At production scale, this pattern also needs an explicit plan for the pre-existing backlog, or grandfathering silently becomes permanent amnesty — the baseline findings should still appear on a tracked, visible backlog with their own remediation targets and periodic review cadence, just decoupled from the immediate, hard-blocking merge gate, so the team gets both outcomes: a strict, enforced gate against new risk starting immediately, and a realistic, non-disruptive path to gradually working down the existing debt without an artificial fire-drill deadline forcing rushed, corner-cutting fixes.

The gotcha: similarity-ID matching, while far better than raw counts, isn't perfectly stable across every kind of code change — a sufficiently large refactor (renaming a function, restructuring a class, moving code between files) can change a finding's computed similarity ID even though the underlying vulnerable pattern itself didn't meaningfully change, which makes an old, pre-existing finding look 'new' to the diff and unexpectedly triggers the gate on a change that didn't actually introduce new risk. Teams that don't anticipate this occasionally hit a confusing false gate-failure right after a large but security-neutral refactor, and the fix isn't disabling the gate, it's recognizing the specific finding as a baseline-carryover during triage and explicitly re-associating it with the original baseline entry rather than treating it as newly introduced.