Checkmarx CxCE study plan

Map every scan-configuration artifact (project, preset, query, team assignment, schedule) to the platform component that stores and executes it, and draw that data flow on one page.

Configure a project from scratch in a lab instance: assign a team, bind a preset, override two queries, and set a recurring schedule.

Explain how a preset resolves to query groups and severities, and predict which findings disappear when a query is removed from a preset.

Trace one scan from scheduler trigger through engine execution to result storage, naming each service involved and its failure mode.

List the deployment prerequisites (database, engine host sizing, authentication, licensing) and where each is validated during install.

Design three scan configurations (fast incremental, full release gate, scheduled nightly) and justify each preset and query-filter choice against a stated risk tolerance.

Execute scans against a deliberately vulnerable sample application and record how scan settings change result volume and duration.

Classify a set of 25 findings into true positive, false positive, and needs-review using source-to-sink reasoning, writing the justification for each.

Apply the platform's false-positive workflow (comment, severity change, state transition) and document when each is appropriate versus when a query must be fixed instead.

Draft triage acceptance criteria a team could adopt so two reviewers reach the same verdict on the same finding.

Explain incremental versus full scan behavior and predict which findings may be missed or re-reported after a partial scan.

Build a result-review routine that separates exploitable findings from theoretical ones using data flow, sanitizers, and reachability.

Define the secure-coding controls (input validation, output encoding, parameterized queries, safe deserialization) that correspond to the most common finding categories you observed.

Write a false-positive justification template that cites the exact code path and the sanitizer or framework control that neutralizes the flow.

Re-triage 10 previously reviewed findings and measure your agreement rate against your earlier verdicts.

Read and annotate an existing CxQL query line by line, identifying the source, the propagation, the sanitizer check, and the sink.

Write a custom query from scratch that detects a specific unsafe pattern in a small codebase and returns only the intended results.

Add a sanitizer or exclusion to that query and demonstrate the result count changing in the expected direction.

Package the query into a custom query group, attach it to a preset, and confirm it runs in a scan.

Diagnose one failing or over-reporting query by isolating whether the fault is in the source definition, the propagation, or the sanitizer logic.

Install and configure the IDE plugin, run a local scan, and navigate from a finding to the exact line in the editor.

Wire a scan into a CI pipeline using the CLI or plugin so the build fails on a defined severity threshold.

Explain how to pass scan settings (project, team, preset, source location) non-interactively and store credentials safely in pipeline secrets.

Configure one automated post-scan action (ticket creation or notification) and verify it fires on a new finding.

Document the administration tasks that affect pipeline stability: service accounts, role permissions, and scan concurrency limits.

Administer teams, roles, and project access so that a developer sees only their team's results while a reviewer sees all, and verify with two test accounts.

Tune scan performance by adjusting engine concurrency, exclusions, and scan scope, and measure the effect on duration.

Configure and validate a scheduled scan and confirm it runs unattended and reports results to the expected project.

Review audit and logging options and identify what evidence you would need to answer a question about who changed a preset.

Plan a backup and upgrade path for scan configuration and results, naming what must be preserved.

Run an open-source component scan and interpret the risk signals: direct versus transitive dependency, severity, exploitability, and fix availability.

Prioritize a list of open-source findings using reachability and dependency depth rather than severity alone.

Write remediation guidance for three representative findings (an injection flaw, an authentication flaw, and a vulnerable dependency) that a developer could act on without further research.

Produce a report for a mixed audience that separates executive risk summary from developer action items and states residual risk after fixes.

Map each remediation recommendation to a verification step that proves the fix worked in a follow-up scan.

Complete a timed mixed-topic practice set weighted toward the heaviest domains and review every missed item to its root cause.

Re-derive from memory the scan-configuration map, the triage criteria, and the CxQL query structure, then correct gaps against your notes.

Re-run your custom query and pipeline to confirm both still work end to end after the full study period.

Write a one-page decision guide for the questions you most often miss, covering when to fix the query, when to mark false positive, and when to escalate.

List remaining weak areas and assign each a specific follow-up action with a date.