A Checkmarx scan performs static application security testing (SAST) by parsing source code into an abstract syntax tree and tracing data flow through it, without executing the program, to find patterns like injection flaws, insecure deserialization, and hardcoded secrets before the code ever runs. Checkmarx has been one of the longer-standing names in the SAST category, and understanding exactly what its scan engine looks at, and what it doesn't, matters for deciding whether it covers your whole application security surface or needs to be paired with other testing types.
What does the scan actually trace through your code?
The engine builds a data-flow graph for each function and traces how untrusted input, a request parameter, a form field, a file upload, moves through the code toward a sensitive operation, a database query, a shell command, an HTML output, flagging paths where that input reaches a dangerous sink without being sanitized along the way. This is what separates real static analysis from simple pattern matching: a checkmarx finding for SQL injection isn't just "this file contains a SQL query," it's "this specific execution path carries unsanitized input from this specific entry point to this specific query." The depth of that cross-function tracing is what determines both the tool's true-positive rate and its false-positive rate; shallower engines that don't trace across function or file boundaries tend to either miss real vulnerabilities or over-flag safe code.
What vulnerability classes does a Checkmarx scan cover well?
The scan covers the classic static-analysis-friendly categories well: SQL and command injection, cross-site scripting, insecure deserialization, hardcoded credentials, and weak cryptographic usage, all of which manifest as identifiable patterns in source code that a data-flow engine can trace. These categories overlap heavily with the OWASP Top 10 and represent the bulk of what static analysis is good at finding in general, not specific to any one vendor. Coverage depth varies by language; mature, widely used languages (Java, C#, JavaScript) tend to have the most refined rule sets, since that's where the vendor and the broader static-analysis research community have invested the most engineering effort over the years.
What does a Checkmarx scan not see?
Being purely static, the scan cannot observe runtime behavior: it won't catch a misconfigured security header, a broken authentication flow that only manifests when the app is actually running, or a vulnerability that only exists because of how the application is deployed and configured in a specific environment. It also generally doesn't assess whether a vulnerable open-source dependency is reachable or exploitable in the context of your specific application, that's the domain of software composition analysis, a separate testing type. Teams that rely on Checkmarx scan output alone as their complete application security testing program have a structural gap in exactly these two areas, runtime behavior and dependency risk, regardless of how good the static engine itself is.
How do teams typically fill that gap?
Most mature programs pair static analysis with dynamic testing (DAST) for runtime behavior and dedicated software composition analysis for dependency risk, rather than expecting one SAST engine to cover all three testing types. Safeguard's SAST/DAST module is built around exactly this pairing, code-level static analysis and runtime dynamic testing sharing a single findings model, so a static finding and its runtime confirmation correlate into one ticket instead of two disconnected alerts across separate tools. Similarly, SCA coverage handles the dependency layer a pure SAST tool like Checkmarx doesn't reach, with reachability analysis determining whether a flagged dependency is actually invoked by your application.
How does a Checkmarx scan compare to newer SAST tools on noise?
Older-generation SAST engines, Checkmarx included in its earlier iterations, have historically had a reputation for high false-positive rates, since rule-based data-flow analysis without additional context tends to flag technically-possible-but-practically-safe paths as findings. Checkmarx has invested in reducing this over time, and newer entrants to the category have generally competed on the same axis: reachability context, better sanitizer recognition, and risk-based prioritization to cut the volume of findings an engineer actually has to review. When comparing SAST tools, ask specifically about the true-positive rate on your own codebase during a proof of value, not a vendor's general marketing claim, since noise levels vary a lot by language and codebase pattern.
FAQ
Does a Checkmarx scan replace the need for manual code review?
No. Static analysis catches pattern-based vulnerabilities efficiently at scale, but manual review still catches business-logic flaws and architectural issues that don't manifest as a recognizable code pattern a scanner is built to detect.
How long does a Checkmarx scan typically take to run?
It depends heavily on codebase size and language; large monorepos can take significantly longer than small services. Most CI-integrated SAST setups run incremental scans on changed files for pull requests and full scans on a schedule to manage this tradeoff.
Is Checkmarx only for large enterprises?
Historically it has skewed toward larger enterprise deployments given its licensing model and depth of configuration options, which is part of why newer, more developer-first SAST tools have gained traction with smaller and mid-sized engineering teams.
Can a Checkmarx scan be run directly in a pull request?
Yes, most modern SAST tools including Checkmarx support CI/CD integration that surfaces findings as pull request comments or checks, which is the setup that gets the fastest developer feedback loop compared to a separate, disconnected scanning dashboard.