Heeler vs Checkmarx.
Agentic Development Security — an end-to-end platform that prevents, fixes, and operates on a runtime context engine — versus Checkmarx One, a broad application-security testing platform.
Both detect. Only one owns the runtime picture.
The two overlap heavily on detection — SAST, SCA, secrets, reachability, package reputation, API discovery. Heeler leads or matches across that overlap and pulls ahead on the fix loop and everything past detection: native cloud/runtime and internet-exposure context, runtime-aware prioritization, validated CI-repair remediation, agent-file governance, and operate-to-verified-closure.
Checkmarx One is a broad, mature AppSec testing platform — SAST, SCA, KICS IaC, DAST, container, secrets, API security, and deep supply-chain intelligence, aggregated in an ASPM. Its strength is breadth of scanning across every layer.
The tell is runtime: Checkmarx's runtime and internet-exposure context isn't native — it's ingested from a third-party CNAPP (Wiz/AWS/Sysdig) you own and connect. Scope here is code security.
A broad scanner portfolio with a borrowed runtime feed, or one native engine.
Both detect SAST/SCA/secrets and both discover APIs from source. The difference is what each knows when it acts: Checkmarx knows the code, and — if you connect a CNAPP — a feed of someone else's runtime picture; Heeler builds its own model of where that code runs, what's exposed, who owns it, and whether a fix actually took effect in production. Scope here is code security.
Broad AppSec testing platform
Scan every layer; aggregate the results.
- →Mature no-build SAST (CxQL, ~two dozen languages, Best Fix Location), SCA with static Exploitable Path, KICS IaC, source-based API Security (Shadow/Zombie), DAST, container, and secrets
- →Deep supply-chain intelligence (typosquat / StarJacking / ChainJacking + behavioral sandbox), CycloneDX/SPDX SBOM, and Codebashing developer training
- →ASPM (Application Risk Management) aggregates every scanner plus imported SARIF; prioritization by CVSS/EPSS/KEV/PoC and static Exploitable Path
- →Runtime and internet-exposure only via Cloud Insights ingesting a third-party CNAPP (Wiz/AWS/Sysdig); remediation is advice plus an unvalidated dependency-bump PR; closure by re-scan; no SLO model, no MCP server, no agent-file governance
Modeled around the running service
Prevent, Fix, and Operate on one runtime-aware model.
- →One context engine across six dimensions (code, cloud/runtime, business, ownership, threat, agent), sensor-less and read-only — runtime exposure is a native input
- →Its own detection — SAST, build-graph SCA (14 ecosystems), validated secrets, agent-file governance — plus an MCP server, Agent Skills, and a CLI
- →Prioritizes by runtime reachability and internet exposure; remediation is built in a sandbox and repaired in your CI until green
- →Guardrails gate new risk at the PR; workflows operate to a runtime-verified close with per-finding SLOs
Side-by-side, with a verdict per row.
Four states. Heeler-leaning where Heeler advances; explicit when Checkmarx leads; honest about parity.
Heeler advantage
Heeler delivers a capability Checkmarx doesn't, or in a way that changes outcomes.
Heeler edge
Both deliver the capability. Heeler's implementation is materially better on a verifiable dimension.
Parity
Both products deliver the capability comparably.
Checkmarx advantage
Explicit signal that Checkmarx leads on this row.
| Section | ● Heeler advantage | ◐ Heeler edge | ✓ Parity | ○ Checkmarx advantage |
|---|---|---|---|---|
| Prevent | – | 2 | 1 | – |
| Fix | 3 | – | – | – |
| Operate | 5 | 6 | 1 | 1 |
| Total | 8 | 8 | 2 | 1 |
| Capability | Heeler | Checkmarx | Verdict |
|---|---|---|---|
| Prevent · stop risk before and as it enters | |||
| Security at AI code generation | Heeler's MCP server hands the coding agent its runtime-aware context as it writes — 30+ read-only tools exposing live SAST, SCA, and secrets findings, endpoint exposure, runtime and deployment risk, guardrail status, and SLO pressure, plus named secure-development prompts — and can trigger Heeler's validated remediation with the right scope. Drop-in Agent Skills and the CLI cover the same surface locally, for Claude Code, Cursor, Codex, and VS Code. | Checkmarx's IDE AI Security Champion sends each finding's surrounding code to OpenAI (with your own API key) and returns an exploitability confidence score, an explanation, and a proposed remediation snippet the developer pastes in and re-scans; an AI Secure Coding Assistant and Developer Assist add in-IDE help, an AI Query Builder helps author custom SAST queries, and a separate CheckAI GPT in the ChatGPT store screens AI-generated code for malicious packages. These are IDE- and chat-side assists — there is no MCP server serving the agent live, runtime-aware context, and no assist triggers a validated fix. | ◐Heeler edge |
| CLI / local developer scanning | The heelercli runs local scans across the full surface — SAST, SCA, secrets (offline validation), license, and malicious-package checks — with non-zero exit for pre-commit and CI, SARIF output, and policy-as-code; plus IDE reach through the MCP server. | The Checkmarx One CLI (cx) is a single Go binary that runs every scanner locally — SAST, SCA, IaC/KICS, containers, secrets — wraps the full REST API, imports SARIF, and generates SBOMs, backed by mature plugins for VS Code, JetBrains, Visual Studio, and Eclipse. KICS Realtime and SCA Realtime give free, account-less as-you-code scanning in VS Code. A broad, mature local and IDE surface. | ✓Parity |
| PR guardrails & policy enforcement | Block / Warn / Observe guardrails post a native status check on GitHub, GitLab, Bitbucket, and Azure DevOps and gate PRs on new dependency vulnerabilities, dependency hygiene, SAST, secrets, and SLO breaches — scoped by runtime context (enforce only on Tier-1, production, or internet-facing services) — with a validated fix committed straight into the PR branch. Block relies on SCM branch protection to enforce. | Checkmarx enforces policy in the pipeline: Policy Management sets severity/CVSS/EPSS thresholds and a “Break the build” toggle fails the CI step (exit codes via the CLI or GitHub Action), results post to the GitHub PR overview and upload as SARIF to code scanning, and Feedback Apps open Jira/GitHub/Azure tickets and send Slack/Teams alerts. Enforcement is at the CI exit-code level rather than a native SCM required-status-check merge gate, it isn't scoped by runtime exposure, and it doesn't ship a fix into the PR. | ◐Heeler edge |
| Fix · resolve findings — code and dependencies | |||
| SAST autofix | Deterministic, strategy-matched transforms (Parameterize / Escape / Allowlist / Path-Normalize) anchored to the exact source-to-sink flow, precomputed per finding on every scan, confidence- and effort-scored, and delivered as PRs validated the same way as dependency fixes (sandbox build + CI repair). Findings needing an architectural change get written guidance instead. | Checkmarx points to the fix rather than making it: Best Fix Location highlights the graph node where one change neutralizes multiple data flows, and the IDE AI Security Champion proposes a remediation snippet (via your OpenAI key) that the developer pastes in manually and re-scans. There is no automated SAST-fix PR that opens and validates the change. | ●Heeler advantage |
| SCA autofix (upgrades) | Deterministic, multi-signal upgrade selection over the resolved graph — Heeler picks the version that clears the most risk with the least disruption (no new known vulnerabilities, proven adoption, cleared minimum-age cooldown), and for transitive vulns finds the smallest bump to the direct ancestor you control (npm, Go, Cargo). Every fix is built in a sandbox and repaired through your CI until green before merge. Auto-fixable across Java, Go, JavaScript, Python, and C#. | Checkmarx recommends an “Upgrade to Version” that clears the CVE and estimates effort/impact, and for a direct dependency in a private GitHub repo can open a CxSCA-Remediation pull request that bumps the manifest (npm package.json, Python requirements.txt, .csproj) — direct dependencies only, and the PR is never built, tested, or CI-validated (“the next scan should show fewer vulnerabilities”). Transitive fixes are advice only; an IDE one-click upgrade covers direct npm dependencies. | ●Heeler advantage |
| Validated, merge-ready fixes (build + CI repair) | Heeler validates every fix twice: a real build in an isolated sandbox with your project's toolchain before the PR (mvn/Gradle, npm/pnpm/Yarn, pip/uv/Poetry, go build, dotnet), then — once the PR is open — it runs your CI and repairs its own build/test failures with up to five follow-up commits until green, or hands off with an explanation. Draft PR if the sandbox build didn't pass; human review, no auto-merge. | Checkmarx doesn't build, test, or sandbox-validate a fix. Its one native dependency-bump PR is merged on trust and confirmed only by the next scan showing fewer findings, and finding/ticket closure is likewise re-scan-based. There is no build-and-repair-in-CI loop. | ●Heeler advantage |
| Operate · detect, prioritize, and run the program | |||
| SAST detection | Path-aware, interprocedural source-to-sink taint analysis across functions and files — plus structural (Graphscan) and heuristic methods — from Heeler's own engine, with detection rules adapted per codebase, automatic reachability/exposure triage, and step-by-step data-flow proof. | Checkmarx SAST is a mature, no-build engine: it builds a logical code graph without compiling and runs CxQL queries for source-to-sink data flows across roughly two dozen language environments with deep framework coverage, custom-query authoring, and a Best Fix Location that collapses overlapping flows to a single node. Findings are worked through manual triage states (To Verify / Not Exploitable / Confirmed …) and preset query packs; reachability/exposure triage isn't automatic, and rule packs aren't adapted per codebase. | ◐Heeler edge |
| Dependency vulnerability (CVE) detection | Build-graph SCA across 14 ecosystems that resolves the full direct-and-transitive graph itself, from manifests — no committed lockfile required and no build change — covering first-party and bundled dependencies too, matched with CVSS, EPSS, and known-exploited signals. GitHub Actions and reusable workflows are a first-class dependency ecosystem, scanned like any other. | Checkmarx SCA covers a broad ecosystem set with CVSS, EPSS score and percentile, and KEV / proof-of-concept exploitability signals, and can ingest a CycloneDX or SPDX SBOM. It resolves either from manifests uploaded to the cloud or from SCA Resolver run locally — which needs the matching package managers installed — and several managers require the committed lockfile (npm package-lock.json, Yarn yarn.lock, pnpm-lock.yaml). It has no GitHub Actions / CI-workflow supply-chain scanning. | ◐Heeler edge |
| Supply-chain & package-reputation detection | Heeler flags compromised/malicious and typosquatted packages, unmaintained projects (OSSF Scorecard), too-new versions (minimum-age), unpinned versions, and downgrades — and treats the CI/CD supply chain as first-class, scoring GitHub Actions on pin status, provenance, and integrity checks (impostor commits, typosquats, abandoned sources). | Checkmarx scores packages 0–10 across contributor reputation, package reliability, and behavioral integrity, and detects typosquatting, StarJacking, ChainJacking, and repojacking plus behavioral threats (data exfiltration, crypto-miners) using multi-engine analysis, a dynamic sandbox, and researcher-verified malicious-package intelligence; an OSSF Scorecard scanner adds repository posture. Deep package-level supply-chain intelligence. | ✓Parity |
| Dependency reachability & noise reduction | Heeler treats a dependency vuln as reachable only when two independent checks agree: runtime reachability (the library is loaded in a running deployment) and static call-graph reachability to the vulnerable functions across six ecosystems (Go, Java, Python, JS/TS, Rust, Ruby). Unreachable findings are auto-mitigated; elsewhere it uses runtime reachability and errs toward reachable. | Checkmarx Exploitable Path uses its SAST engine to check statically whether your code actually calls the vulnerable method, drawing the path from your code to the package method and flagging unused packages. It's static call-graph only (no runtime signal of its own), covers Java, C#, JavaScript, and Python, doesn't follow reflection, is opt-in per project, and doesn't refresh on incremental scans or risk recalculation; runtime “used / not-used” comes only from a Sysdig integration. | ◐Heeler edge |
| Secrets detection & validation | First-class secrets: full git-history scanning across all branches with commit attribution, active live validation (read-only calls to the issuing provider; an active secret is weighted as maximal impact), offline structural validation, and 700+ rules across 20+ languages; contained and gated at the PR. | Checkmarx detects secrets with a Secret Detection scanner and the open-source 2ms CLI (built on the gitleaks framework, also covering Slack/Discord/Confluence), plus a TruffleHog-style entropy/regex pass inside SAST that the docs note is high-false-positive. The docs describe rule-based detection but no live validation of whether a secret is active, and history-scanning depth isn't specified. | ●Heeler advantage |
| Dynamic application security testing (DAST) | Not offered as dynamic scanning of a running application. Heeler instead computes the exposed attack surface statically — every endpoint enumerated from source with its authentication posture and internet-accessibility from deployment topology — so the externally reachable, unauthenticated surface is inventoried without a deployed target, credentials, or traffic capture. It does not send live traffic against a running app. | Checkmarx DAST dynamically scans a running web app or API for vulnerabilities. Built on OWASP ZAP, it runs passive and active rules against a configured environment (a Swagger/OpenAPI or Postman definition for APIs), covering injection, XSS, path traversal, and similar classes; hosted scans are time-limited (about 2h45m), with a Docker/pipeline option for longer runs. | ○Checkmarx advantage |
| Endpoint & API attack-surface discovery | Heeler enumerates every endpoint from source — REST, GraphQL, gRPC, SOAP, and WebSocket, plus the MCP tools/resources/prompts and Spring Boot actuator routes your code exposes — capturing each one's authentication posture and computing internet-accessibility from deployment topology, so your externally reachable, unauthenticated surface is inventoried with no runtime agents or traffic capture. | Checkmarx API Security discovers API endpoints from source using SAST queries, builds an inventory, and diffs it against your OpenAPI docs to surface Shadow and Zombie APIs, undocumented and unauthenticated endpoints, and sensitive-data exposure. Discovery covers a limited framework set — Java-Spring, C#/ASP.NET Web API, Python Flask/Django, and Node/Express — with no internet-accessibility signal from deployment topology, and no GraphQL/gRPC/SOAP/WebSocket, MCP, or Spring Boot actuator analysis. | ◐Heeler edge |
| Runtime-aware prioritization | Heeler Risk (Urgent / Plan / Defer) ranks SAST and SCA findings by real exposure. For SCA, a vuln must clear a gate: reachable (runtime-loaded, plus a call-graph path where supported) AND internet-exposed (an active deployment on internet-reachable compute) AND not mitigated — fail any and it Defers, however high the CVSS. For SAST, exposure is path-driven from an internet-facing entry point, behind auth, touching sensitive data. Both are weighted by service tier and threat (KEV/EPSS; CWE class), with a per-finding SLO, re-scored continuously. | Checkmarx prioritizes with static signals — severity, CVSS, EPSS score and percentile, KEV, proof-of-concept, static Exploitable Path, and manual triage predicates. Internet-facing and runtime-usage signals exist only through Cloud Insights, which ingests them from a third-party CNAPP you own and connect (Wiz, AWS, CrowdStrike, Sysdig, Uptycs); without that integration, prioritization is static. There is no Checkmarx-native deployment topology, service-tier, or internet-exposure model. | ●Heeler advantage |
| Cloud, runtime & business context | Heeler builds its own model of where code runs — containers, VMs, and serverless fingerprinted, each deployment mapped to the exact running changeset, internet-accessibility auto-detected, service tier (1–4) and prod/non-prod classified, service-to-service and identity edges resolved, and ownership resolved to a RACI — all read-only and sensor-less. This context is what makes exposure, prioritization, and routing real. | Not offered natively. Checkmarx One is a code- and repo-scanning platform with no cloud connector or runtime sensor of its own; its Cloud Insights feature ingests inventory, internet-exposure, and runtime-usage data from a third-party CNAPP (Wiz, AWS, CrowdStrike, Sysdig, Uptycs) and correlates container images back to repositories. The runtime picture is the CNAPP's, contingent on the customer owning and connecting it — not a model Checkmarx builds. | ●Heeler advantage |
| Agent-file detection & governance | A dedicated repo-level inventory scores every agent instruction/skill/subagent/hook/MCP-config file (CLAUDE.md, AGENTS.md, .claude/skills, .cursor, .mcp.json, .codex) 0–100 across Static, LLM-intent, and External-reference risk, with a Malicious / Suspicious / Benign verdict, across Claude, Cursor, Gemini, Codex, and OpenCode — with a CI-gating API and a workflow trigger. | Not offered. The Checkmarx One documentation describes no detection or risk-scoring of agent-instruction, skill, or MCP-configuration files (CLAUDE.md, AGENTS.md, .mcp.json, and the like). | ●Heeler advantage |
| SBOM & dependency inventory | A live dependency inventory (with OpenSSF hygiene scoring) and CycloneDX SBOMs at five scopes — including runtime SBOMs per running service and per deployment, built from real runtime context — alongside global, application, and repository scopes. | Checkmarx exports CycloneDX (through v1.7 in the UI) and SPDX 2.3 SBOMs, enriched with a properties section carrying vulnerability, license, and suspected-malware data, with scope filters to exclude dev/test or private packages. The SBOMs are static — there is no runtime SBOM of the services actually running. | ◐Heeler edge |
| Automated response workflows & routing | A standing when-this-then-that engine across the whole estate: one trigger (new finding, fix available, compromised dependency, new secret, at-risk agent file, SLO expiring, PR merged with unresolved guardrail violations) → AND-combined conditions → up to three chained actions that share context. Actions span messaging (Slack/Teams/Google Chat/email), ticketing (Jira/Linear/GitHub/Shortcut, de-duplicated), and domain actions (Fix with Heeler Agent, Update SLO Override, Generate SBOM, Webhook), routed to the owning team by RACI, with a plain-English builder. | Checkmarx routes findings through Feedback Apps that auto-open and auto-close tickets (Jira, GitHub Issues, Azure DevOps) and send Slack/Teams/email alerts, with a one-way ServiceNow Vulnerability Response sync. It's event-driven notification and ticketing rather than a trigger → condition → action workflow engine — no RACI owner-resolution, and no fix-agent, SLO, or SBOM actions inside a workflow. | ◐Heeler edge |
| SLOs & runtime-verified closure | Every finding carries a per-band SLO clock; SLO-expiring events trigger workflows, and an Update SLO Override action can extend a due date automatically. Findings run Active → Fixed → Deployed, and closure is runtime-verified — a fix reaches Deployed only once every running deployment confirms the vulnerability is actually gone, not merely merged. | Checkmarx has no SLA/SLO or due-date framework in its documentation, and closure is re-scan-based: a finding or ticket is closed once it no longer appears in the latest scan — the docs even warn this can close a finding that a code change merely hid. There is no confirmation against a running deployment. | ●Heeler advantage |
Where a runtime-native engine beats a broad scanner portfolio.
Each maps back to the context engine — not another scanner in the portfolio.
Runtime and cloud context that's native, not borrowed from a CNAPP
Checkmarx One scans code and repositories well, and its Cloud Insights feature can enrich findings with runtime and internet-exposure data — but only by ingesting it from a third-party CNAPP (Wiz, AWS, Sysdig) that you own and connect. Without that, prioritization falls back to CVSS/EPSS/severity. Heeler builds its own sensor-less model of where code runs — deployment-to-changeset mapping, service-to-service edges, service tier, ownership, and internet-accessibility — so exposure, prioritization, and routing are real out of the box, with no CNAPP to buy and wire up.
Prioritize by runtime exposure, not a static score or a bolted-on feed
Checkmarx ranks by CVSS, EPSS, KEV, PoC, and a static Exploitable Path (four languages), with internet-facing and runtime signals available only when a CNAPP is connected. Heeler gates every dependency finding on reachable AND internet-exposed AND not-mitigated, and traces SAST exposure from a real internet-facing entry point — natively — so a live, exposed finding outranks a dormant one that looks identical on CVSS.
Remediation proven in your CI, not a pointer or an unvalidated bump
Checkmarx points to the fix — Best Fix Location, upgrade-to-version advice, an IDE AI snippet — and its one native PR is a direct-dependency manifest bump that's never built or tested (success is judged by the next scan). Heeler builds every fix in an isolated sandbox and repairs its own CI failures until green — for code and dependencies — before a human merges it. A pointer to the right node, or a bump merged on trust, isn't a fix proven to build and pass tests.
Operate to a runtime-verified close, with risk-band SLOs
Checkmarx has no SLA/SLO model and closes findings by re-scan — which, as its own docs warn, can mark a vulnerability fixed when a code change merely hid it. Heeler runs per-band SLO clocks and moves findings Active to Fixed to Deployed, closing only when the running deployment confirms the vulnerability is actually gone — “no longer in the branch” is not “no longer running anywhere.”
Beyond detection: the agent, the attack surface, and the agent files
Heeler hands the coding agent live, runtime-aware context through an MCP server as it writes, discovers your full endpoint and API attack surface from source (REST/GraphQL/gRPC/SOAP/WebSocket/MCP, with auth posture and internet-accessibility), and governs the agent-instruction files that now steer your code — scoring CLAUDE.md, .mcp.json, and skills 0–100 for malicious intent. Checkmarx offers an IDE AI assistant and source-based API discovery for a few frameworks, but no MCP server, no internet-exposure model, and no agent-file governance. Heeler runs the whole loop, sensor-less, at machine speed for the AI SDLC.
See Heeler on your codebase.
A demo runs Heeler against your real repos and cloud — detection across the surface, the runtime map, the prioritization, the validated remediation PRs, and the agent-file catalog. If Checkmarx is scanning your code today, we'll show what native runtime context adds on top.
