Checkmarx documentation is organized around products rather than tasks, so the fastest way to use it is to identify which Checkmarx product you are running first, then drill into that product's scanning, integration, and API sections rather than searching the whole docs site blindly. Developers usually hit the Checkmarx documentation at an awkward moment, mid-pipeline-failure or mid-integration, and the sprawl can eat an afternoon if you do not know how it is structured. This guide is a map, not a replacement, so you can get to the page you actually need.
Note upfront: product names and console URLs change across Checkmarx releases, so treat any specific menu label here as a pointer to a concept, not a permanent string.
Know which product you are documenting for
The single biggest time-saver is knowing your product line before you read anything. Checkmarx has shipped its static analysis under more than one product name and platform generation, and the docs are split accordingly. A guide written for one platform's console will reference menus and endpoints that do not exist in another.
Figure out whether you are on the current cloud platform or an older self-managed server product, and note your exact version. Almost every "the docs do not match my screen" complaint traces back to reading the wrong product's or wrong version's pages. Once you have pinned that down, the rest of the documentation navigates cleanly.
The sections you will actually use
Across Checkmarx products, the documentation clusters into a handful of areas. Knowing which one answers which question saves the search box a lot of work.
- Getting started and administration covers installation, tenant setup, user and role management, and licensing. Go here for access problems and initial configuration.
- Scanning and results explains how to run a scan, interpret findings, mark false positives, and manage result states. This is where you spend time tuning signal-to-noise.
- Integrations documents the plugins and connectors for CI systems, IDEs, and source control. Most pipeline questions live here.
- APIs covers programmatic access, which is the section this guide treats separately below because it is where automation lives.
- Queries and presets describes the query language and scan configurations that control what the scanner looks for.
When a page does not answer your question, the answer is usually one section over, not deeper in the same one.
Checkmarx API documentation
If you are automating anything, the Checkmarx API documentation is where you will live. Modern Checkmarx platforms expose REST APIs, and the docs typically publish an OpenAPI or Swagger reference you can read interactively.
Three things to establish before you write a line of client code.
- Authentication. Determine the auth model your platform uses, commonly an OAuth token flow. Get a token working with a manual request before you build anything around it.
- Base URL and versioning. API paths are region- and version-specific. Copy the base URL from your own tenant rather than from a generic example.
- Rate and scope. Understand which token scopes grant which endpoints so you request least privilege.
# Smoke-test auth and connectivity before building a client
curl -s -H "Authorization: Bearer $CX_TOKEN" \
"$CX_BASE_URL/api/projects" | jq '.[0]'
Getting one authenticated call to return real data is the checkpoint that tells you the auth and base-URL pieces are correct. Build outward from there.
Reading the CI/CD integration docs
Pipeline integration is the most common reason developers open the Checkmarx documentation, and the integration pages assume you have already sorted authentication. Before wiring a scan into CI, have your credentials stored as pipeline secrets, your project identifier known, and your scan configuration chosen.
The recurring failure mode is credentials handling. Do not paste tokens into a pipeline file. Use your CI system's secret store and reference the secret, so the token never lands in version control or build logs. The integration docs will show the plugin invocation; the secret hygiene is on you, and it is worth getting right because a leaked scanner token can expose your source and findings.
Where the docs stop and your own policy begins
Documentation tells you how the tool behaves, not how your team should act on it. Two decisions the Checkmarx docs deliberately leave to you: which severities break the build, and how you triage findings the scanner cannot resolve on its own. A SAST tool reports potential issues; deciding your gate thresholds and your false-positive workflow is policy, and it belongs in your own runbook alongside the vendor docs.
This is also where SAST and software composition analysis divide the work. Static analysis examines your first-party code, while your dependencies need composition analysis to catch known-vulnerable packages. If you are mapping your coverage, our SAST versus SCA comparison lays out where each fits, and a tool such as Safeguard covers the dependency side that SAST does not.
Getting unstuck faster
When the documentation does not answer a question, a few habits shorten the loop. Match your product and version to the page before trusting it. Use the interactive API reference to test an endpoint rather than reading the prose about it. And when a scan or integration fails, read the tool's own error output first, since Checkmarx error messages usually name the missing scope, wrong URL, or auth failure directly, which is faster than searching the docs for a symptom.
FAQ
How is Checkmarx documentation organized?
It is organized by product and version, then by area: getting started and administration, scanning and results, integrations, APIs, and queries and presets. Identify your exact product and version first, because pages written for one platform generation will not match another.
Where is the Checkmarx API documentation?
Modern Checkmarx platforms publish a REST API reference, usually as an interactive OpenAPI or Swagger page within the docs site. Establish the authentication flow, your tenant-specific base URL, and required token scopes before building a client.
Why does the Checkmarx documentation not match my console?
Almost always because you are reading pages for a different product line or version. Checkmarx has shipped static analysis under multiple product names and platform generations, so confirm which one you run before following any step-by-step guide.
Does Checkmarx documentation cover dependency scanning?
Checkmarx documents its own product coverage. Static analysis focuses on your first-party code, so for known-vulnerable dependencies you rely on software composition analysis. Confirm which capability your license includes and cover the gap with a dedicated SCA tool.