Checkmarx CxCE cheat sheet

SAST analyzes source, bytecode, or binaries without executing the program; it detects dataflow and control-flow defects but cannot observe runtime configuration, so results are potential findings requiring confirmation.

Core dataflow model: Source (untrusted input entry point) → propagation through assignments, calls, and returns → Sink (dangerous operation). A finding requires a path from source to sink with no sanitizer on the path.

Sanitizers must match the sink context: HTML-encoding neutralizes XSS in HTML body context but not in a JavaScript string, URL attribute, or SQL statement; context-mismatched encoding is a false negative.

Taint vs. non-taint queries: taint queries track source-to-sink paths; non-taint (logic/configuration) queries match structural patterns such as hardcoded credentials, weak cipher constants, or missing security headers.

Best-practice vs. high-severity classification: best-practice queries flag maintainability or defensive-coding issues; the severity assigned to a result derives from the query's severity metadata, not from CWE rating alone.

CWE mapping: XSS → CWE-79, SQL injection → CWE-89, path traversal → CWE-22, OS command injection → CWE-78, insecure deserialization → CWE-502, hardcoded credentials → CWE-798.

Incremental analysis compares the current code version to a baseline and reports only newly introduced or changed findings, which is why a first full scan is required before incremental scans produce meaningful deltas.

False-negative risk rises with dynamic dispatch, reflection, dependency injection, and framework magic; verify these areas manually because the engine may not resolve the runtime target of a call.

CxSAST server roles: the CxManager (web front end, REST API, scheduling, results storage on SQL Server) and CxEngine servers (scan workers that run the query pipeline). Engines register with the manager over the configured port.

Scans are queued and dispatched to available engines; concurrency is bounded by engine count and per-engine scan slots, so adding engines increases parallel scan capacity rather than per-scan speed.

CxAudit is the desktop client for writing and testing CxQL queries against a local or remote engine; queries are packaged into CxQL query files and uploaded to the manager to become part of a query set.

Access control uses roles (e.g., admin, manager, auditor, scanner) plus team-based project ownership; a user's effective permissions combine the role with team membership on the project.

Authentication integrates with LDAP/Active Directory or SAML SSO; service accounts used by CI/CD should be dedicated, least-privilege accounts rather than interactive admin users.

Result state model: To Verify, Confirmed, Not Exploitable, Proposed Not Exploitable, and Fixed. States are per-result and survive rescans through result matching, so triage effort is not lost on re-scan.

Upgrades require backing up the CxSAST database and configuration, stopping services in order (engines, then manager), and verifying engine re-registration and query-set compatibility afterward.

CxSCA is a separate service with its own components and its own access URL/credentials; SCA findings are not stored in the same result set as SAST findings and are triaged separately.

A project binds a source location (source-control or uploaded ZIP), a query preset, scan schedule, and team ownership; the preset determines which query groups run and therefore which vulnerability classes can be reported.

Presets are named collections of query groups; the default 'All' preset runs every enabled query and produces maximum coverage with longest scan time, while focused presets reduce noise and duration.

Custom query sets are built by copying a base preset, adding or modifying queries in CxAudit, and uploading; a project can use a custom preset so changes are scoped to that project.

Scheduling options: immediate/on-demand, recurring (interval-based), and scheduled per project; CI/CD-triggered scans bypass the schedule and are launched via API/plugin.

Scan type choice: full scan re-analyzes everything; incremental scan analyzes only changed files since the baseline and is faster but can miss cross-file flows into unchanged code.

Exclusions (folders, files, and file-extension patterns) reduce scan time and noise; over-broad exclusions create false negatives, so exclude generated code and third-party libraries rather than business logic.

Project source settings must match the build: Java projects need compiled binaries or the configured build step so the engine can resolve types; missing dependencies produce unresolved references and missed findings.

Scan priority and queue position can be set for on-demand scans; high-priority scans jump the queue, which matters when a release gate is waiting on results.

Result severity is a property of the query, not of the individual finding; two results from the same query carry the same severity regardless of exploitability context.

Triage decision rule: if a sanitizer exists on the path but the engine did not recognize it, the correct action is a custom query or sanitizer configuration, not a blanket 'Not Exploitable' state.

'Not Exploitable' with a reason code is the documented false-positive path; it is preserved across scans by result matching, whereas deleting a project or changing the query set resets the finding.

Result matching across scans uses a fingerprint of file, line, and query; moving code can break matching and resurface previously triaged results, so verify after large refactors.

Scan comparison view shows new, fixed, and recurring results between two scans; use it to measure remediation progress rather than raw result counts, which fluctuate with code churn.

An attack-path/flow view shows source, propagation steps, and sink; a finding with no complete path is usually a logic/configuration query result and needs manual review rather than path analysis.

Bulk state changes apply to selected results in the results grid; they are convenient but bypass per-finding justification, so restrict bulk actions to clearly identical patterns.

Risk acceptance is a governance decision recorded outside the tool or via a documented exception; the tool state 'Not Exploitable' should not be used to hide accepted risk.

CxQL is a SQL-like declarative language over the code model; a query has a metadata header (name, severity, CWE, language, query group) and a SELECT body with FROM/WHERE clauses.

Taint query skeleton: select the source, the sink, and the propagation path, then filter with conditions; the engine computes reachability, so the query describes endpoints and sanitizers rather than the traversal.

Non-taint query skeleton: select a single code element (e.g., a method invocation or a declaration) and constrain it by name, argument value, or annotation.

Common building blocks include function/method name matching, argument position, annotation checks, and sanitizer declarations that tell the engine which calls neutralize taint.

Sanitizer definition in a query prevents false positives for framework-specific escaping; omitting it produces findings on already-safe paths.

Queries are language-scoped: a Java query does not apply to C# code; a project with multiple languages needs queries for each language in the preset.

Test queries in CxAudit against a small known-vulnerable and known-safe code sample before uploading; a query that returns zero results on the vulnerable sample is broken, not clean.

Query performance depends on how broadly the FROM clause matches; anchoring on specific method names or annotations rather than all invocations keeps scan time reasonable.

The CxSAST REST API is the integration surface: authentication returns a token used as a bearer/header credential for subsequent calls; tokens expire and must be refreshed by the automation.

Typical CI/CD flow: create or locate project → upload source (ZIP) → trigger scan → poll scan status → fetch results (XML/JSON report) → fail the build on threshold breach.

Build gating rule: fail on new findings at or above a chosen severity (e.g., High) rather than on total findings, so legacy debt does not block every pipeline.

Incremental scans in CI reduce pipeline time; schedule periodic full scans (e.g., nightly) to catch cross-file flows that incremental analysis misses.

IDE plugins run a local or remote scan of the open project and surface results inline; they rely on the same project/query configuration, so IDE results should match pipeline results for the same preset.

CxSAST and CxSCA have separate APIs, credentials, and report formats; a pipeline that gates on both must call both services and merge the gate logic.

Scan results are asynchronous: the trigger call returns a scan ID, and the pipeline must poll or use a callback; assuming results are available immediately is a common integration bug.

Store credentials in the CI secret store and use a dedicated service account; embedding credentials in pipeline scripts exposes them in logs and repository history.

Remediation priority rule: rank by exploitability (reachable from untrusted input) and severity, then by fix cost; a reachable High outranks an unreachable High.

Fix patterns: parameterized queries for SQL injection, contextual output encoding for XSS, allow-list validation plus canonical path resolution for path traversal, and argument-array process execution for command injection.

Reports available include scan summary, detailed results with paths, and trend/comparison reports; the detailed report is the one that carries source-to-sink evidence needed for developer handoff.

A useful finding write-up contains: query name, CWE, file and line, the source, the sink, the propagation path, and a concrete code fix - not just the severity label.

Re-scan after remediation and confirm the specific result is 'Fixed' rather than relying on a lower total count, which can also result from exclusions or query changes.

Metrics that reflect program health: mean time to remediate by severity, percentage of results triaged, and new-vs-fixed ratio per release; raw open-finding counts are misleading without code-size context.

Report distribution should respect team scoping: a team lead sees their projects, not the whole organization, which is enforced by the role/team model rather than by report filtering alone.

Root-cause reporting groups findings by query/CWE to reveal systemic patterns (e.g., one unsafe helper used everywhere) that a per-file fix would miss.

SCA identifies open-source components and their versions from manifest/lock files (e.g., package.json, pom.xml, packages.config, requirements.txt) and maps them to known vulnerabilities.

Matching depends on accurate version resolution: a lock file gives exact resolved versions, while a manifest range can cause mismatches or missed findings.

CxSCA risk dimensions include vulnerabilities, license risk, and outdated components; a component can be risky on license grounds with no CVE at all.

Transitive dependencies are in scope: a vulnerable library pulled in indirectly is still a finding, and the fix may be to upgrade the direct dependency that brings it in.

Remediation options: upgrade to a fixed version, replace the component, or apply a documented mitigation/exception when no fixed version exists.

Exploitability context (e.g., whether the vulnerable function is actually invoked) distinguishes reachable risk from theoretical risk and should drive priority.

SAST and SCA overlap in scope but not in evidence: SAST reports code-level flows, SCA reports component/version exposure, so the same CVE can appear in both with different remediation paths.

SBOM output lists components and versions for supply-chain tracking; it supports audit and incident response when a new CVE is published for a component already in use.