What is the practical difference between SAST, DAST, and SCA, and how does Checkmarx correlate all three to reduce false positives?

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.