Checkmarx

Picture tracking a rumor as it spreads through an office to see if it ever reaches someone who'd act on it recklessly — you'd trace it person by person: who told whom, who added details, whose retelling actually changed the story enough that it stopped being the same claim. A SAST engine's taint analysis works exactly like tracing that rumor: it marks data as 'tainted' the moment it originates from an untrusted source (a user-submitted form field, a URL parameter, an uploaded file), and then follows that taint through every subsequent variable assignment, function call, and transformation in the code, the same way you'd track whether the original rumor is still recognizably present in what someone repeats three conversations later.

This rumor-tracing model is precisely how static taint analysis was designed to catch injection vulnerabilities without ever running the program: if tainted data flows, unmodified or insufficiently modified, all the way into a dangerous sink — a raw SQL query string, a shell command, an HTML response written without encoding — that's flagged as a potential injection vulnerability, because an attacker who controls the source (the original untrusted input) effectively controls what happens at the sink. The entire value proposition of SAST is catching this class of bug before the code ever runs anywhere, which DAST and manual testing simply cannot do as exhaustively, since they can only observe behavior along paths they actually happen to execute.

Step by step, the engine builds this as a graph: nodes represent variables, function calls, and expressions; edges represent data flowing from one to another. Starting from every known 'source' (a catalog the engine maintains of framework-specific entry points for untrusted data — request parameters, headers, cookies, database read results in some threat models), it performs a reachability analysis across that graph to every known 'sink' (SQL execution calls, command execution calls, raw HTML output). Along the way, if the data passes through a recognized 'sanitizer' (a parameterized query binding, an established escaping function, an allow-list validation the engine's rule set knows about), the taint is cleared and that path is no longer flagged. Crucially, this entire process happens without executing the code — it's purely a graph traversal over the program's structure, which is exactly why it can analyze every possible path through the code, including ones that would be extremely rare or hard to trigger in a live running system, but also exactly why it has no actual runtime context to know for certain whether a given path is truly reachable in practice.

At production scale, the false-positive pattern the question describes — sanitized input still getting flagged — happens because the engine's built-in catalog of 'known sanitizer' functions is necessarily finite and mostly covers common, well-known frameworks. A custom, internal validation utility that a company built in-house (say, a shared InputSanitizer.clean() helper used company-wide) isn't in Checkmarx's default sanitizer catalog, so from the engine's point of view, tainted data going into that function and coming back out is exactly as tainted as it was going in, because the engine has no built-in knowledge that this particular function actually neutralizes the risk — it just sees a function call, not a security control. The data flow through that custom sanitizer looks structurally identical to data flowing through any other unremarkable function, so the engine, erring conservatively (correctly preferring false positives over false negatives for a security tool), keeps the taint alive and flags the eventual sink.

The gotcha, and the actual fix experienced AppSec engineers reach for: Checkmarx supports custom sanitizer definitions specifically to solve this, letting a team explicitly register their in-house validation function as a recognized taint-clearing point, which permanently eliminates this entire class of false positive going forward rather than requiring a human to manually re-triage the same false positive on every single scan, forever, across every service that uses the same shared utility. Teams that never configure custom sanitizers end up in a chronic, compounding state where the same handful of company-wide utility functions generate the same false positives across dozens of services indefinitely, training developers to reflexively dismiss SAST findings as noise — which is the exact security-fatigue failure mode that eventually lets a genuinely new, real finding get rubber-stamped away along with all the familiar false ones.

This is like a building's fire inspection suddenly failing on hundreds of new violations the day after the fire code itself was rewritten, even though nothing about the building changed overnight. The natural, wrong instinct is to assume the building suddenly became unsafe; the actually useful first question is whether the building changed or the rulebook changed, because those require completely different responses — one means real, urgent remediation, the other means understanding and adapting to updated standards, possibly along with recalibrating which of the new rules genuinely apply to your situation versus which are overly broad interpretations that need tuning.

Checkmarx and every SAST vendor periodically ship engine updates that add new detection queries, tighten existing ones, or update their built-in sanitizer and sink catalogs — this is a genuinely necessary process, since new vulnerability classes and attack techniques are discovered continuously and a static tool that never updates its rules becomes stale and increasingly blind to current threats. But the practical consequence is that an engine update can retroactively 'discover' large numbers of new findings in code that hasn't changed at all, simply because the tool now looks for patterns it didn't check for last week — and treating every one of those as an urgent new production risk, at the same priority as a finding introduced by an actual code change, misallocates security team attention.

Step by step: first, establish the timeline precisely — pull the CI pipeline history and confirm whether the code diff between the last passing build and this failing one is trivial or substantial; if the actual application code is nearly unchanged but the Checkmarx CLI or scan engine image version bumped in the same window, that's your leading signal this is a ruleset change, not a code regression. Second, cross-reference the new findings' query names or IDs against the vendor's release notes for that engine version — Checkmarx publishes what queries were added, modified, or had their default severity changed in each release, and a spike concentrated in queries that line up with the release notes confirms the hypothesis directly rather than leaving it as a guess. Third, before bulk-dismissing anything, manually spot-check a representative sample of the new findings' actual data-flow paths — some fraction of a newly-tightened rule's findings are often genuinely real issues the previous, looser version of the rule simply never caught, so a real regression can be hiding inside what's mostly ruleset noise, and blanket-dismissing the whole batch risks missing that real subset. Fourth, decide on an interim strategy: options include temporarily pinning the previous engine version while the team properly triages the new ruleset's findings on its own schedule, or keeping the new engine active but adjusting the pipeline's policy gate threshold specifically for the newly-added query IDs while the backlog gets worked through, rather than blocking every single deploy in the meantime.

At production scale, mature AppSec teams treat scan-engine and ruleset upgrades as a change that itself needs a rollout process, not something that silently takes effect and immediately gates every team's CI pipeline at full strictness — testing an engine upgrade against a representative sample of existing codebases in a non-blocking, report-only mode before promoting it to a hard gate lets the team absorb exactly this kind of finding-count spike deliberately and on their own timeline, rather than discovering it for the first time when it unexpectedly blocks every team's deploys simultaneously.

The gotcha: teams under deploy-pressure often respond to a sudden spike by immediately, blanket-suppressing every new finding just to unblock the pipeline, reasoning that 'it's probably just the new ruleset' without actually verifying that — and this is precisely how a real, newly-introduced vulnerability that happened to land in the same release window as an engine update gets silently waved through as assumed noise, discovered only much later, if ever, when it's actually exploited rather than caught at the gate it was specifically designed to be caught at.

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.

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.

Think of three different building inspectors checking the same house for safety, each using a completely different method. One inspector reads the blueprints without ever stepping inside — they can spot a structural flaw in the design itself, like a load-bearing wall drawn incorrectly, but they'll also flag things that look risky on paper but were actually built correctly and reinforced on-site, something the blueprints alone don't show. A second inspector actually walks through the finished house, opening doors, testing the wiring, checking if anything currently misbehaves — they catch real, live problems, but only in the rooms they actually visit, and won't catch a structural flaw sitting in a wall nobody happened to open that day. A third inspector doesn't look at the house at all — they just check whether any of the prefabricated materials used (specific window brands, electrical panels) are on a public recall list. SAST is the blueprint reader, DAST is the walkthrough inspector, and SCA is the recall-list checker, and a serious safety assessment needs all three because each one catches things categorically invisible to the other two.

Checkmarx (and application security tooling generally) evolved to combine all three specifically because each technique in isolation produces a predictable, well-known failure mode. SAST, because it analyzes code without ever executing it, tends toward high recall but also high false positives — it flags a huge number of *theoretically* dangerous code patterns (like unsanitized input flowing into a SQL query) without knowing whether that pattern is actually reachable by an attacker or whether some other layer of the application already sanitizes the input elsewhere. DAST, because it only tests what it can actually reach and exercise at runtime, has excellent precision (a finding it reports is almost certainly real and exploitable) but poor coverage, since it can only find issues along code paths its scan actually triggers, missing anything behind authentication it wasn't configured to bypass or rare execution branches it never happens to hit. SCA solves an entirely different problem — it doesn't analyze your code's logic at all, it just matches your dependency manifest against CVE (Common Vulnerabilities and Exposures) databases, so it's extremely good at telling you *that* you're using a vulnerable library version, but says nothing about whether your code actually calls the vulnerable function inside that library in an exploitable way.

Step by step, Checkmarx's correlation engine works by building a unified model across all three data sources rather than treating them as three separate reports a human has to manually cross-reference. It takes SAST's data-flow analysis (which traces how untrusted input moves through the code — for example, from an HTTP request parameter through several function calls into a database query) and checks whether that flow passes through a function that SCA has already flagged as belonging to a vulnerable dependency version. It further checks whether DAST's runtime crawl actually reached and exercised that same code path during a live scan. A finding that lines up across all three signals — a data-flow path exists (SAST), it runs through vulnerable dependency code (SCA), and it's confirmed reachable at runtime (DAST) — gets surfaced as high-confidence and exploitable. A SAST finding with no corroborating SCA or DAST signal doesn't get discarded outright, but it gets deprioritized in the triage queue, which is the actual mechanism by which correlation reduces the false-positive burden on security teams without silently dropping potentially real findings.

At production scale, this correlation matters enormously for how AppSec teams actually spend their time: without it, a single codebase easily produces thousands of raw SAST findings, the overwhelming majority of which are either not reachable in practice or already mitigated by controls the static analyzer couldn't see (like a shared input-sanitization middleware applied globally). Security teams that must manually triage that volume burn out fast and start rubber-stamping findings as false positives just to keep pace, which is precisely how a genuinely exploitable vulnerability slips through — buried in thousands of look-alike low-confidence findings. Correlation-based prioritization is what makes SAST results operationally usable at real codebase scale rather than a wall of noise developers learn to ignore.

The gotcha: a finding that correlation marks as *lower* confidence is not the same as a finding that's actually safe to ignore — a data-flow path SAST identifies but DAST never happened to exercise during its crawl (because the DAST scan's configured user role never navigated to that specific page, for instance) will show reduced correlated confidence purely due to a coverage gap in the dynamic scan, not because the underlying code is actually safe. Teams that treat 'lower correlated confidence' as synonymous with 'not a real risk' rather than 'not yet corroborated' can end up deprioritizing a genuinely exploitable finding simply because their DAST scan's crawl configuration never reached that part of the application.