Checkmarx CxCE common mistakes
Checkmarx CxCE · Understand the traps and how to avoid them.
Treating CxSAST as if it compiles and runs the code (dynamic analysis), and answering that it detects runtime or configuration-dependent issues such as authentication bypass at runtime or environment-specific injection.
Candidates conflate SAST with DAST/IAST and assume the engine executes the application; the platform builds a model of the code (via a compiler-like parsing step) and analyzes data and control flow statically, so issues requiring a running instance are out of scope for CxSAST.
What to do instead
Memorize the boundary: CxSAST finds issues visible in source (taint flows, dangerous API use, hardcoded secrets, weak crypto) without execution; runtime/environment issues belong to DAST or IAST. When a stem mentions 'at runtime' or 'when deployed', reject SAST-only answers.
Assuming CxSAST understands every language and framework out of the box and that unsupported constructs are still analyzed correctly, rather than recognizing the language/framework support matrix and the need for the correct compiler/parsing configuration.
The engine requires language-specific parsers and, for some languages, build/compiler settings; unsupported syntax is skipped or partially modeled, so findings can be missing or inaccurate and candidates misattribute this to a query defect.
What to do instead
Check the supported languages and versions for the deployed CxSAST release, ensure the scan is configured with the right language and compiler options, and treat 'no findings' on unsupported syntax as a coverage gap rather than a clean result.
Describing the platform as a single monolith and misplacing components - e.g., claiming the CxSAST scan engine stores results in the database directly, or that the CxSAST Manager and the CxSAST Engine are the same service.
The architecture separates the web/management layer (CxSAST Manager with its database), the scan engines that perform analysis, and the CxSAST (Cx) access control/identity service; candidates who have only used the UI never map the services.
What to do instead
Draw the deployment from memory: Manager (web UI, REST API, results DB), Engines (perform scans, communicate with Manager), CxSAST Access Control (authentication/authorization). Be able to say which component a given failure (login failure, scan stuck in queue, results not appearing) implicates.
Ignoring engine capacity and licensing when planning scans - assuming any number of concurrent scans can run, and not accounting for engine registration, engine pools, or scan queue behavior.
Throughput is bounded by the number of licensed/registered engines and per-engine concurrency; candidates who only configure scans in the UI overlook that a backlog is a capacity problem, not a configuration bug.
What to do instead
Learn how engines register with the Manager, how engine groups/pools route scans, and how license limits cap parallel scans. For 'scans queued for hours' scenarios, check engine availability and license consumption before touching project settings.
Confusing scan presets with query categories and with project-level query tuning - e.g., stating that a preset edits individual query logic, or that changing a preset retroactively alters prior scan results.
Presets are named collections of query categories/severities used at scan time; query editing happens in the query editor with custom queries, and results are snapshots tied to the scan that produced them.
What to do instead
Separate the layers: queries (logic) → query categories/packs → presets (which categories run, at what severity) → project scan configuration (which preset applies). Remember results are per-scan snapshots; re-scanning is required to reflect preset or query changes.
Treating a scan as 'failed' or 'clean' without distinguishing scan status values (e.g., Queued, Running, Completed, Failed, Canceled) and without checking the scan log for partial analysis or engine errors.
Candidates read only the results summary; a scan that completed with engine warnings or skipped files can look clean, and a genuinely failed scan can be mistaken for a zero-finding result.
What to do instead
Always verify scan status and review the scan log for errors, skipped languages, or compilation failures before interpreting results. A completed-with-errors scan is a coverage problem to fix, not evidence of a secure codebase.
Marking findings as 'Not Exploitable' or 'False Positive' by default when the result looks unfamiliar, without tracing the data flow or documenting justification.
Triage pressure and unfamiliar query semantics lead candidates to treat any confusing result as noise; this erodes the audit trail and hides real defects, and the exam tests whether you can distinguish a genuine false positive (query logic or modeling error) from a true positive you do not yet understand.
What to do instead
Walk the result's path (source, propagation nodes, sink), confirm sanitizers/encoders actually neutralize the flow, and only then assign a status with a written justification. Reserve 'False Positive' for query/modeling errors and use 'Not Exploitable'/'Proposed Not Exploitable' for accepted-risk or unreachable cases per workflow.
Writing CxQL that queries only for a dangerous sink method without modeling sources, sanitizers, or the data flow, and expecting it to behave like a taint query.
CxQL is built around the CxSAST data-flow graph; many candidates write SQL-like 'find all calls to X' queries and are surprised by noise or missed flows, and they misuse taint propagation APIs or forget to declare query metadata (severity, CWE, category).
What to do instead
Use the taint-flow pattern: define sources, sinks, and sanitizers, then use the flow/taint APIs to connect them. Declare metadata so results map to severity and categories, and test the query against a known-vulnerable and a known-safe sample before deploying it to a preset.
Assuming plugin/CLI integration is fire-and-forget - not handling authentication (OAuth/credentials), scan thresholds, or asynchronous scan completion in the pipeline, so builds pass on vulnerable code or fail nondeterministically.
CI/CD integrations are asynchronous: the CLI or plugin triggers a scan and must poll or wait for completion, then evaluate results against a threshold policy; missing token/credential configuration or ignoring the exit code produces silent failures or flaky gates.
What to do instead
Configure credentials/tokens as pipeline secrets, use the supported CLI/plugin invocation for the platform version, wait for scan completion, and enforce a threshold (e.g., fail on new high-severity findings). Verify exit codes and publish the report artifact so gate behavior is auditable.
Reporting raw finding counts without severity, exploitability context, or remediation guidance, and conflating SCA (open-source/library) risk with SAST (first-party code) findings in the same remediation plan.
Candidates treat all results as equivalent; SCA findings are driven by dependency versions and CVEs with their own severity and fix versions, while SAST findings require code changes, so a merged count misleads stakeholders and produces wrong remediation advice.
What to do instead
Separate SAST and SCA result sets, prioritize by severity and reachability/exploitability, and give concrete remediation: code-level fix for SAST, upgrade-to-fixed-version or dependency replacement for SCA. Include trend and risk-acceptance records rather than bare counts.