Checkmarx is used primarily for static application security testing (SAST): scanning an application's source code for security vulnerabilities early in the software development lifecycle, before the code ever runs. Its long-standing SAST engine, historically known as CxSAST, analyzes code without executing it and flags issues such as injection flaws, insecure data handling, and compliance problems. This overview explains what Checkmarx does, how development teams put it to work, and where it sits alongside other kinds of security testing.
The core job: static code analysis
Static analysis means reading the code, not running it. Checkmarx parses your source, builds a model of how data flows through the application, and traces paths where untrusted input can reach a sensitive operation without being sanitized. That data-flow tracing is what lets it catch things like SQL injection or cross-site scripting at the point where a value enters the program and follows it to where it is used.
Because the scan works on source, it can run very early, on a developer's branch or in a pull request, long before there is a deployed environment to test. Finding a vulnerability at that stage is far cheaper to fix than finding it in production. Checkmarx supports coverage across many programming languages and frameworks, which is part of why large organizations with mixed stacks adopt it.
What teams actually use it for
In practice, Checkmarx shows up in a few concrete workflows.
Pull-request and CI scanning. Teams wire the scanner into their pipeline so every merge request gets analyzed. Findings appear where developers already work, which is the whole point of shifting security left. Checkmarx integrations connect to source control, CI/CD systems, and issue trackers so a finding can become a ticket automatically.
Compliance and audit evidence. Regulated organizations use SAST results to demonstrate that code is scanned for known weakness classes. The tool maps findings to standards and weakness taxonomies, which supports audits against frameworks that require secure development practices.
Reducing false-positive noise. A recurring complaint about SAST in general is noise. Checkmarx invests in findings analysis and a "best fix location" feature that points at the root cause so one change can resolve many related findings, rather than making developers triage each symptom separately. Checkmarx supports mailing for pre/post scan activities, so scan kickoff and completion can trigger notifications to the right people rather than being polled manually.
Where Checkmarx fits, and where it does not
SAST is one leg of application security, not the whole thing. It is worth being precise about what static analysis can and cannot see.
SAST reads source, so it is strong at finding code-level flaws, insecure patterns, and tainted data flows. It struggles with issues that only appear at runtime: authentication logic that depends on live session state, misconfigured servers, or vulnerabilities in third-party services your app calls. It also does not, by itself, tell you which open-source dependencies carry known CVEs.
That is why mature programs pair SAST with other tools. Dynamic application security testing exercises the running application from the outside, catching runtime and configuration issues static analysis misses. A DAST scan complements SAST rather than duplicating it. Software composition analysis handles the dependency question, cataloging your open-source components and flagging known vulnerabilities in them. Continuous SCA scanning is where you catch a vulnerable library that no amount of source review of your own code would reveal.
SAST versus DAST versus SCA in one line each
- SAST (what Checkmarx is best known for): reads source code, finds code-level flaws early, no running app needed.
- DAST: attacks the running application, finds runtime and configuration issues.
- SCA: inventories dependencies, finds known CVEs in the open-source you did not write.
You want all three because each sees a different part of the risk. Checkmarx has expanded beyond pure SAST over the years, but "static code scanning for vulnerabilities" remains the clearest answer to what it is used for. If you are building out a program from scratch, our security academy walks through how these testing types layer together.
FAQ
What is Checkmarx used for in one sentence?
Checkmarx is used for static application security testing, scanning source code for security vulnerabilities early in development so flaws are caught before the code is deployed.
Is Checkmarx a SAST or DAST tool?
Checkmarx is best known as a SAST tool; its historic CxSAST engine analyzes source code without running it. The company has broadened its platform over time, but static analysis is its core use case, and it is typically paired with separate DAST and SCA capabilities.
Does Checkmarx find vulnerabilities in open-source dependencies?
Static code analysis focuses on the code you write. Identifying known CVEs in third-party libraries is the job of software composition analysis, which is a distinct discipline you run alongside SAST.
When in the SDLC do teams run Checkmarx?
Early and often, typically on pull requests and in CI pipelines. Because SAST works on source code and does not need a deployed environment, it can run on a developer's branch, where fixing a flaw is cheapest.