Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Checkmarx

Checkmarx makes application security testing tooling, and the product you actually deploy is Checkmarx One, a cloud-native platform that folds static analysis, software composition, dynamic testing, and a stack of supply-chain checks under one console. The vendor was founded in Israel and built its name on SAST, the static engine that reads source and bytecode for taint-flow vulnerabilities. If your runbook still says “CxSAST,” that’s the legacy on-prem product name, and Checkmarx has been retiring it in favor of “Checkmarx One SAST” as a module inside the platform. Same lineage, different packaging.

Schematic of source code flowing through several stacked analysis engines into a single correlation layer, a few findings highlighted and routed onward, an AI agent node branching off to draft a fix.
Ownership first, because this is the field most stale docs get wrong. Checkmarx is owned by Hellman & Friedman, which closed its acquisition from Insight Partners in April 2020 at a $1.15B valuation, with TPG holding a minority stake alongside Insight. In 2024 there was a widely reported sale process, with H&F said to be shopping the company for around $2.5B. That process did not close. As of this writing in 2026, H&F still owns Checkmarx. If your ATO package or vendor risk assessment names a 2024-2025 buyer, that’s a rumor someone wrote down as fact. Re-check at your own publish date, because private-equity holds in this space turn over, but right now nothing has changed hands.

What ships in the platform

Checkmarx One is the unified, cloud-native thing, and the vendor’s framing now is ASPM, application security posture management, with the individual scanners feeding a correlation layer that dedupes and ranks across engines. The modules that matter for a federal SDLC:

Module What it actually does Where it lands
SAST Static taint-flow analysis on source and bytecode; deep language coverage, CxQL custom queries SA-11 static analysis
SCA Open-source dependency risk, license exposure, transitive CVE mapping SR-3, SR-4, SA-11
DAST Runtime testing against a deployed app or API endpoint SA-11 dynamic analysis
API Security Discovers and tests APIs, including shadow and zombie endpoints SA-11, SC-7 boundary
IaC Security Terraform/K8s/CloudFormation misconfig, built on the KICS open-source engine CM-6 config, loosely
Container Security Image and layer scanning for known-vulnerable packages RA-5 adjacent, SR
Supply Chain Security Malicious-package detection, repository health, provenance SR-3, SR-4, SR-11
Secrets Detection Hardcoded credentials and tokens in the repo SA-11, IA
AI Supply Chain Governance LLM and agent governance, model/dependency exposure SR, emerging
Codebashing In-context secure-coding training for developers AT-2, SA-15
ASPM Correlation, dedup, and prioritization across the engines above SA-11, RA-5 framing

KICS is worth a note. It’s the open-source IaC scanner Checkmarx maintains, written in Go, queries in Rego, and it’s the engine behind Checkmarx One IaC Security. It also ships standalone and got pulled into GitLab as a default IaC scanner a few releases back, so you may already have it in a pipeline without the Checkmarx brand attached.

The marketing center of gravity in 2025-2026 has moved hard toward “Agentic AppSec.” Checkmarx One Assist is the umbrella for a family of AI agents: Developer Assist drafts in-IDE fixes before code hits the repo, and the Triage and Remediation agents work scan findings into prioritized, fix-attached pull requests. In December 2025 Checkmarx acquired Tromzo, an ASPM vendor building autonomous security agents, with founders Harshil Parikh and Harshit Chitalia and their engineering team joining. The amount was not disclosed. Tromzo folds into Checkmarx One and the Assist agent family, which tells you where the roadmap money is going.

Where it sits in the federal flow

This is code and application security testing, not host vulnerability scanning, and keeping that straight saves an argument with your assessor. Checkmarx reads your repositories and your running app. It does not scan a host for missing patches or check a STIG benchmark. That lane belongs to ACAS and Nessus on the infrastructure side. So RA-5 applies only loosely here, mostly through the dependency and container CVE angle, and the bulk of the control weight lands elsewhere.

The control that pulls Checkmarx into a federal SDLC is SA-11, developer security testing and evaluation. SA-11 names static analysis, dynamic analysis, and code review as the testing methods a developer of a system has to perform, and SAST plus DAST plus the manual-review workflow map straight onto it. SA-15, development process and tools, is the secondary tie, because the platform is part of how secure coding standards get enforced in the pipeline. On the supply-chain side, the SR family carries the SCA and malicious-package story: SR-3 supply chain controls, SR-4 provenance, SR-11 component authenticity. That’s the seed of the whole compliance case for tooling like this.

Who runs it: the development and AppSec teams, gated into CI/CD, not the ISSO running a quarterly host scan. Cadence is per-commit or per-pull-request for incremental scans, with full baseline scans on a slower beat. The findings don’t go straight into your RMF package. They get exported and summarized into the SSP narrative and the POA&M, by hand or through a ticketing bridge. Checkmarx does not feed eMASS the way ACAS does. There’s no native eMASS connector here, so the artifact path is: scan, export (SARIF is the common format for pipeline gates and downstream tooling), triage, then a human writes the result into the package.

FedRAMP and the on-prem question

Get the FedRAMP wording exactly right, because this is the field most likely to draw a finding if you overstate it, and the level and the status both matter. On September 30, 2025, Checkmarx One for Government achieved FedRAMP Ready at the High impact level, the company completed a 3PAO-reviewed Security Assessment Report, and at that announcement no sponsoring agency was named. But Ready is a milestone, not a marketplace status, and the two have since diverged: the live FedRAMP Marketplace listing for Checkmarx One for Government (CXG, package FR2514624801) shows In Process at the Moderate impact level, Rev 5, with zero authorizations. So the actual in-process work is Moderate, while High was a readiness milestone, and neither is Authorized. Do not write “FedRAMP High Authorized” or even “FedRAMP Authorized” in an SSP. It is neither, as of this writing, and an assessor who checks the marketplace will catch it. Confirm current status on the FedRAMP Marketplace at your own date, since In-Process-to-Authorized is exactly the kind of state that moves.

On DoD impact levels, I found no confirmed IL4 or IL5 authorization and no DISA APL listing specific to Checkmarx. If anyone tells you it carries an IL5 ATO, treat that as unverified until you see the paperwork. [NEEDS VERIFICATION: DoD IL4/IL5/APL status for Checkmarx One.]

Deeper: the SaaS pivot versus the air-gap.
Checkmarx One is cloud-native, and the FedRAMP Ready story is a SaaS story. For a connected FedRAMP Moderate or High environment, that’s the direction you want. For a disconnected or classified shop, it’s a problem. An IL5 or air-gapped enclave can’t reach a vendor SaaS, and the legacy on-prem SAST product is the thing that historically served those environments. As the platform’s center of gravity moves to the cloud, the on-prem and air-gapped deployment story gets less attention and less roadmap, and that gap is real for DoD shops running disconnected networks. If you’re standing up AppSec testing inside an air-gap, confirm the on-prem deployment shape and its support lifecycle before you commit, because the SaaS-first direction does not serve you and the answer here changes entirely between a commercial-cloud pipeline and a classified one.

What it does well, what it doesn’t

The SAST engine has deep language coverage and the correlation layer does cut noise by deduping findings across scanners, which is the genuine value of consolidating five tools into one console. Checkmarx claims its ASPM layer delivers around 89% noise reduction and a 43% developer-productivity lift, that it scans 800B-plus lines of code a month, and that 60% of the Fortune 100 use it. Those are vendor-stated figures, not independently verified, so read them as marketing, not benchmark.

The complaints are the usual SAST complaints, sharpened by scale. False-positive volume is real, and tuning is work; the platform will flag plenty that a human has to dismiss, and on a large monorepo the first few weeks of triage are heavy until the baseline settles. Scan time on big repositories is a known headache, which is why incremental and baseline scan configuration matters and gets misconfigured. The custom-query language, CxQL, gives you precision but carries a learning curve and a maintenance-debt problem: those custom queries are load-bearing once written, and they rot when the author leaves. Cost is the other recurring gripe, since the consolidated platform isn’t cheap and modules bill independently.

Here’s my contestable opinion, and I’ll mark it as exactly that. The agentic-AI repositioning deserves real scrutiny before you trust auto-remediation agents inside a federal AppSec gate. An agent that drafts a fix and opens a pull request is fine. An agent that auto-remediates, auto-triages, and auto-dismisses findings in a pipeline that gates an ATO is a different risk surface, and in a federal context the provenance of every dismissed finding and every machine-authored fix needs a human in the loop and an audit trail. The vendor’s framing leans hard on autonomy. I’d keep the autonomy on a short leash in a regulated pipeline until the audit story for agent decisions is as clean as the scan results themselves. That’s a judgment call, not a verified defect, and your appetite will depend on how much your AO trusts machine-authored evidence.

A few operational notes worth flagging. Integration points are broad: GitHub Actions, GitLab, Jenkins, Azure DevOps for CI/CD, IDE plugins for the shift-left workflow, and Jira for ticketing. SARIF output is the clean way to gate a build and to feed findings into other tooling. The pitfall most teams hit is gate tuning: breaking the build on every medium finding sounds rigorous and turns into developers routing around the gate within a sprint. Set the gate to fail on what actually matters for your impact level, not on the full finding firehose, or the tool becomes shelfware that everyone has learned to ignore.

Sources

Adjacent material on this site