Checkmarx API Security is the API-testing module inside the Checkmarx One platform, and its defining feature is discovering APIs directly from source code — including undocumented shadow and zombie endpoints — rather than relying on you to hand it a spec. If you have ever tried to secure an API estate and found that the OpenAPI documentation covers maybe 60% of what's actually running, that discovery-at-the-source approach is the reason teams evaluate the checkmarx api security offering. This guide walks through what it does, how it differs from a standalone API scanner, and how to think about where it fits.
The problem it targets: you don't know all your APIs
Most API security incidents don't come from the endpoint you carefully threat-modeled. They come from the one nobody remembered. Shadow APIs are endpoints that exist in code but never made it into documentation or the API gateway inventory. Zombie APIs are old versions left running after a supposed deprecation. Both are invisible to a scanner that only tests what a spec file lists.
Checkmarx's approach is to derive the API inventory from the codebase itself. Because the checkmarx api discovery step reads route definitions, controllers, and handlers in source, it surfaces endpoints that have no documentation at all. That inventory is the foundation — you cannot secure what you cannot see, and an incomplete list is the most common reason API programs miss real exposure.
How it fits inside Checkmarx One
Checkmarx API Security is not a separate product you buy and integrate on its own; it is a capability within Checkmarx One, the company's unified application security platform. That platform also includes SAST, DAST, SCA, IaC security, and container security. The practical consequence is that API findings live in the same place as the rest of your AppSec results, so you are not stitching together yet another dashboard.
The tighter integration is with DAST. Checkmarx API Security works natively with Checkmarx DAST so that static findings from source analysis correlate with dynamic findings from runtime testing. When both the static and dynamic sides flag the same endpoint, that correlated finding is elevated — the platform is telling you the vulnerability is not merely present in code but observable at runtime, which is a strong signal it is genuinely exploitable.
Risk prioritization beyond CVSS
A recurring frustration with API scanners is that they treat every endpoint as equally important and rank purely on CVSS. A CVSS 7.5 on an internal health-check endpoint is not the same risk as a CVSS 7.5 on the endpoint that returns customer PII, but a score-only view flattens them.
Checkmarx API Security prioritizes based on business value and risk rather than CVSS alone. In practice that means the tool tries to push the endpoints that matter to the top of the queue so that AppSec teams and developers spend their limited triage time on the handful of issues that carry real consequences, not on a sorted-by-severity list that ignores context. Whether the business-value inputs match your own risk model is worth validating during an evaluation, because "business value" is only as good as the signals feeding it.
Where it sits in your workflow
Checkmarx One integrates into the SDLC through IDE plugins, CI/CD steps, and SCM hooks, and API Security rides on that same plumbing. A typical flow looks like this:
- A scan runs against the repository as part of CI. The discovery step builds or updates the API inventory from source.
- DAST exercises the running application; correlated findings get promoted.
- Results land in Checkmarx One, prioritized, with the shadow and zombie endpoints called out explicitly.
- Developers get findings in-context, ideally with a best-fix-location pointer so a single change addresses the root cause rather than each symptom.
The value of this shape is that API coverage stops being a separate, manual exercise and becomes a byproduct of scans you were already running.
How to evaluate it fairly
If you are comparing the checkmarx api security capability against alternatives, a few concrete questions cut through marketing:
- Discovery accuracy. Point it at a repo where you already know the full endpoint list and see how many shadow and zombie APIs it actually finds versus misses. Discovery is the headline feature, so test it directly.
- Language and framework coverage. Checkmarx's static engine supports a broad set of languages and frameworks; confirm your specific stack is well-covered, because discovery quality varies by how mature the parser is for your framework.
- Correlation signal quality. Look at how many findings actually get the SAST-plus-DAST correlation boost in your codebase. If almost nothing correlates, you are effectively running two independent tools.
- Noise. Count false positives on a real project over a two-week window, not on a demo repo.
No single tool owns API security outright. Checkmarx's strength is discovery-from-source and platform correlation; other vendors lead on traffic-based discovery or specialized runtime protection. The right answer depends on where your gaps actually are.
API security is broader than one tool
API security is not only about scanning endpoints. It also depends on the libraries behind those endpoints — an authentication or serialization dependency with a known vulnerability undermines an otherwise well-tested API. Keeping that dependency layer clean is a software composition analysis job, and a tool such as Safeguard can flag when an API framework or its transitive dependencies ship a known CVE. If you are mapping out an end-to-end program, our DAST product page covers the dynamic-testing side and the Academy has material on API-specific threats like broken object-level authorization.
FAQ
Is Checkmarx API Security a standalone product?
No. It is a module within the Checkmarx One platform, alongside SAST, DAST, SCA, IaC, and container security. Its API discovery and correlation features are designed to work with the rest of that platform, particularly Checkmarx DAST.
What are shadow and zombie APIs?
Shadow APIs are endpoints that exist in your code but are missing from documentation and inventory. Zombie APIs are outdated versions still running after deprecation. Both are common sources of breaches precisely because they escape spec-driven scanners, and discovering them is a core Checkmarx API Security feature.
How is Checkmarx API Security different from an API gateway's built-in security?
A gateway secures traffic for the routes it knows about. Checkmarx derives the API inventory from source, so it can surface endpoints the gateway never had registered — the shadow and zombie ones — which is exactly where gateway-only approaches leave gaps.
Does Checkmarx API Security replace SCA?
No. It tests the API endpoints and application logic. It does not replace software composition analysis, which tracks vulnerabilities and licenses in the open-source dependencies your API is built on. The two are complementary layers.