HEAD-TO-HEAD COMPARISON

Heeler vs Checkmarx.

Agentic Development Security, built for the AI SDLC — versus Checkmarx One, an application-security testing platform. Heeler runs one context engine that unifies code, dependencies, runtime, and cloud as a single model and proves every fix in your CI; Checkmarx scans every layer but borrows its runtime and internet-exposure picture from a third-party CNAPP you connect. Here's where Heeler advances and what native runtime context adds.

Get a demo →See the Heeler platform

EXECUTIVE SUMMARY

Heeler owns the runtime picture; Checkmarx borrows it.

Heeler runs one context engine that unifies code, dependencies, runtime, and cloud — matching or leading across the detection overlap and pulling 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 aggregates SAST, SCA, DAST, secrets, API security, and supply-chain intelligence in an ASPM; its runtime and internet-exposure context isn't native — it's ingested from a third-party CNAPP (Wiz/AWS/Sysdig) you own and connect.

THE FUNDAMENTAL DIFFERENCE

Heeler is one native engine. Checkmarx is a scanner portfolio with a borrowed runtime feed.

Both detect SAST/SCA/secrets and both discover APIs from source. What sets Heeler apart is a single context engine that unifies code, dependencies, runtime, and cloud — modeling where that code runs, what's exposed, who owns it, and whether a fix took effect in production; Checkmarx knows the code, and — if you connect a CNAPP — a feed of someone else's runtime picture.

CHECKMARX

AppSec testing platform

Scan every layer; aggregate the results.

→No-build SAST (CxQL, ~two dozen languages, Best Fix Location), SCA with static Exploitable Path, source-based API Security (Shadow/Zombie), DAST, and secrets
→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

HEELER

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

VERDICT FRAMEWORK

Side-by-side, with a verdict per row.

Five 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 edge

Both deliver the capability. Checkmarx's implementation leads on a verifiable dimension.

○

Checkmarx advantage

Explicit signal that Checkmarx leads on this row.

Scorecard — 25 capabilities, scoped to code security

Section	● Heeler advantage	◐ Heeler edge	✓ Parity	◑ Checkmarx edge	○ Checkmarx advantage
Prevent	–	2	2	–	–
Fix	4	–	–	–	–
Operate	6	7	3	–	1
Total	10	9	5	–	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 (with live 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 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 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
IaC pull-request guardrails	Heeler evaluates the Infrastructure-as-Code findings introduced by a pull request instead of failing a change because of pre-existing repository debt. It returns a native source-control check controlled by program policy: Observe records the violations and the decision that would have been made, Warn reports them without preventing merge, and Block fails the check so repository rules can require it. The same policy can move from observation to enforcement without creating separate rules or CI logic.	Checkmarx One policies can evaluate KICS Infrastructure-as-Code results and enforce policy actions in development workflows.	✓Parity
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
Policy-managed remediation memories	Heeler stores administrator-approved remediation guidance as memories in program policy and scopes each memory to an organization or repository. On later remediation runs, the Remediation Agent retrieves the applicable memories and applies the repository’s conventions and constraints when generating a fix. The guidance is centrally governed and reusable; it is not a one-off prompt, a triage-suppression rule, or generic model memory.	No documented capability.	●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 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 broad 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 your manifests and lockfiles — using a committed lockfile when present, without requiring one, and with 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 many ecosystems 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. 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 — across AWS, GCP, Azure, Kubernetes, and Vercel, with 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 the owning team (Tech Lead / Security Lead) — 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	Heeler inspects pull-request changes to agent instructions, skill files, hooks, subagents, and MCP configuration, including CLAUDE.md, AGENTS.md, and SKILL.md. It combines deterministic checks, LLM-based intent analysis, and analysis of external references to identify prompt injection, tool poisoning, unsafe command execution, secret access or exfiltration, permission bypass, and related agent-control risks. The evidence and verdict are returned through Observe, Warn, or Block before the changed artifact is trusted by coding agents.	No documented capability.	●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, 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 owner-resolution to the owning team, and no fix-agent, SLO, or SBOM actions inside a workflow.	◐Heeler edge
SLOs & runtime-verified closure	Every tracked finding under an SLO policy carries a per-band (Urgent / Plan / Defer) 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
Infrastructure-as-Code findings	Heeler evaluates Infrastructure-as-Code against policy and creates a persistent finding for each violation. The finding retains the affected file or infrastructure resource and links it to the repository, application, owning team, business criticality, and any connected cloud or runtime object. The same finding is used for prioritization, lifecycle tracking, workflow routing, pull-request guardrails, and remediation instead of remaining a one-time CI scanner result.	Checkmarx KICS includes more than 2,400 queries across more than 18 Infrastructure-as-Code technologies and integrates the resulting findings into Checkmarx One workflows.	✓Parity
GitHub audit-log behavioral checks	Heeler ingests the GitHub organization audit log for each connected organization and evaluates defined patterns across the resulting source-control events. A match creates a native finding that retains the actor, action, affected repository or organization, timestamp, and matching event context. The finding enters Heeler’s ownership, prioritization, investigation, workflow, and lifecycle tracking rather than remaining a searchable or exported log event.	No documented capability.	●Heeler advantage
OpenSSF Scorecard repository health	Heeler records the repository’s OpenSSF Scorecard result and each check outcome on the repository object in the catalog. The same repository view links the signal to applications, ownership, vulnerabilities, dependency health, provenance, deployment, and exposure context. Teams can inspect which Scorecard checks reduced the result and evaluate repository-maintenance risk in relation to the applications that use the repository instead of treating the score as an external badge.	Checkmarx Repository Health uses OpenSSF Scorecard and surfaces repository-health checks inside Checkmarx One.	✓Parity
Sensitive-data inventory	Heeler analyzes application source to identify the sensitive data types handled by the code and records them in the application catalog. Each data type is connected to the repositories, services, APIs, and owning teams that process it, together with business criticality and available deployment or exposure context. A reviewer can move from a data type to the applications and interfaces that handle it and evaluate that data-handling risk with the same ownership and runtime context used for other application-security findings.	Checkmarx API Security inventories APIs and identifies sensitive parameters, authentication, and API risk. Its documented inventory is API-centered rather than a source-derived catalog of data types linked across applications, repositories, services, owners, and deployment context.	◐Heeler edge

WHERE HEELER ADVANCES

Where a runtime-native engine beats a scanner portfolio.

Each maps back to the one context engine — code to cloud — not another scanner in the portfolio.

Runtime and cloud context that's native, not borrowed from a CNAPP

Checkmarx One scans code and repositories, 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.

Get a demo →See pricing