.svg)
HEAD-TO-HEAD COMPARISON
Heeler vs Arnica.
Agentic Development Security, built for the AI SDLC — versus Arnica, an ASPM that scans on every push with no CI pipeline. Heeler runs one context engine that unifies code, dependencies, runtime, and cloud — real-time on every commit and modeling where the code runs, what's exposed, and whether the fix landed; Arnica reasons about the code and the SCM event. Here's where Heeler advances and where the two meet.
EXECUTIVE SUMMARY
Heeler models the running system; Arnica reasons about the repo.
Heeler runs one context engine across code, dependencies, runtime, and cloud — matching or leading across the detection overlap (SAST, SCA, secrets, package reputation) and pulling ahead on everything past the repository: live cloud and runtime context, internet-exposure prioritization, endpoint and API discovery, validated CI-repair remediation, agent-file governance, and operate-to-verified-closure.
Arnica scans on every push with no CI pipeline — on-push feedback, ChatOps, secret block-on-push, AI-rule injection — a code-and-SCM view of risk, with none of the runtime context, CI-proven fixes, or verified closure Heeler computes.
THE FUNDAMENTAL DIFFERENCE
Heeler knows where the code runs and whether the fix landed. Arnica sees the repo and the commit.
Both scan SAST/SCA/secrets on every commit and push feedback to developers in real time. What Heeler adds is the running system — live cloud/runtime context, internet-exposure prioritization, endpoint discovery, fixes proven green in your CI, and closure verified in production — none of which a code-and-SCM tool computes.
ARNICA
ASPM — scans on push, no CI pipeline
Real-time code-risk feedback, straight to developers.
- →Scans on every push and PR with no CI pipeline — SAST (Opengrep + AI SAST), SCA with static reachability and 7-factor reputation, and live-validated secrets
- →Real-time secret block-on-push (“zero new secrets”), ChatOps self-service, and an Agentic Rule Enforcer that writes AI-coding rules into repos
- →A policy engine (trigger → condition → action), enriched CycloneDX SBOM with a “Zero Day” campaign filter, and Jira/ADO ticketing
- →SCM- and code-centric: no live cloud/runtime context, endpoint discovery, internet-exposure prioritization, CI-validated remediation, or runtime-verified closure
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 Arnica leads; honest about parity.
●
Heeler advantage
Heeler delivers a capability Arnica 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.
◑
Arnica edge
Both deliver the capability. Arnica's implementation leads on a verifiable dimension.
○
Arnica advantage
Explicit signal that Arnica leads on this row.
Scorecard — 24 capabilities, scoped to code security
| Section | ● Heeler advantage | ◐ Heeler edge | ✓ Parity | ◑ Arnica edge | ○ Arnica advantage |
|---|---|---|---|---|---|
| Prevent | – | 3 | 1 | – | – |
| Fix | 4 | – | – | – | – |
| Operate | 7 | 4 | 4 | 1 | – |
| Total | 11 | 7 | 5 | 1 | – |
| Capability | Heeler | Arnica | 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. | Arnica's Agentic Rule Enforcer injects security-focused AI-coding rules into the repo (CLAUDE.md, AGENTS.md, .cursor/rules, Copilot instructions) so assistants generate more secure code, and surfaces citation annotations when a rule is followed; on a finding, a BYO-LLM produces an on-demand AI fix suggestion. It steers the agent with rules and suggestions rather than serving live, runtime-aware context or triggering 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. | Arnica is pipelineless and SCM-native: rather than a local CLI, it scans on every push and pull/merge request server-side and returns developer feedback via ChatOps and PR comments, with an optional CI GitHub Action and an API-initiated SBOM scan for complex builds. | ◐Heeler edge |
| 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. | Arnica's real-time policy engine (trigger → condition → action, ~30 conditions incl. CVSS/EPSS/KEV/SLA) gives on-push developer feedback via ChatOps and PR comments and can fail a status check — but it's a soft gate by default (a hard gate needs SCM branch protection), scoped by repo/product/branch rather than runtime exposure, and it doesn't ship the 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. | Arnica evaluates Infrastructure-as-Code changes directly in source-control workflows without requiring a CI pipeline and can enforce hard merge gates. | ✓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. | Arnica offers AI-generated code suggestions in PR comments and on-demand AI fix recommendations on a finding (via your connected LLM); there is no automated SAST-fix PR pipeline 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#. | Arnica recommends upgrade versions with “trenched” (minor vs major) and “calculated effective” mitigation that weighs vulnerabilities fixed against new ones introduced, and can post an AI code suggestion — but it recommends rather than opening and validating a remediation PR, and doesn't build or test the change. | ●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. | Arnica doesn't build, test, or sandbox-validate a fix. “Validation” means it re-scans the branch, observes the risk is gone, marks it Resolved Automatically, and closes the linked ticket — scan-based closure, not a build/test-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. | Arnica runs Opengrep (the Semgrep fork) with a proprietary global rule library and custom-rule authoring, plus a distinct LLM-based “AI SAST” with per-product prompts, on push / PR / routine scan across a broad language set — pattern/dataflow plus an LLM pass rather than a whole-program interprocedural engine. | ◐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 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. | Arnica does lockfile-based SCA across a broad ecosystem set, with transitive-depth modeling, EPSS correlation, dev-dependency auto-downgrade, and KEV awareness, surfaced in real time on push. For most languages it resolves from the committed lockfile (Gemfile.lock, Cargo.lock, composer.lock, poetry.lock, and the like), so a repo or ecosystem without one isn't fully resolved. Its GitHub Actions touch is operational, not analytic — a Dependency Scan GitHub Action to run Arnica in CI, and workflow-file edits via PR — not scanning the Actions supply chain itself. | ◐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). | Arnica scores third-party packages on a 7-factor reputation model (releases, stars, dependents, OpenSSF Scorecard, publish recency, weekly downloads) to flag low-reputation/unmaintained dependencies, and offers a “Zero Day” SBOM campaign search to instantly find repos exposed to an active supply-chain attack. | ✓Parity |
| 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. | Arnica scans full history at ingest with a validated-detector library and live validation (auth, DNS, offline brute-force of encrypted keys → Valid/Invalid/None), and adds real-time mitigation: on push it resets the branch to block a new secret (“zero new secrets”), preserving the developer's work on a masked branch. Historical secrets are detected but not auto-mitigated by design. | ✓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. | Arnica computes static, function-level code reachability for npm, PyPI, uv, and Maven (High / Medium / Partially reachable / Unreachable) focused on high/critical CVEs, alongside EPSS, dev-dependency, and package-depth noise reduction. Static code reachability, not runtime or exposure-based. | ✓Parity |
| IaC / misconfiguration scanning | 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. | Arnica performs real-time Infrastructure-as-Code scanning directly in source-control workflows without requiring a CI pipeline and supports common cloud-configuration formats. | ✓Parity |
| 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. | Arnica prioritizes by severity, CVSS, EPSS, KEV, package reputation, static code reachability, a repo/product “business importance” heuristic (contributor count, activity, config), and SLA status. It has no live cloud, deployment-topology, or internet-exposure signal driving priority. | ●Heeler advantage |
| Cloud, runtime & business context | Heeler builds its own model of where code runs across AWS, GCP, Azure, Kubernetes, and Vercel — 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. Arnica is SCM- and code-centric: it reasons about repositories, commits, and IaC files, with no live cloud inventory, deployment-topology graph, or internet-exposure model. Its “business importance” is a heuristic from repository activity and configuration, not runtime context. | ●Heeler 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. | Not offered. Arnica has no application endpoint or API discovery — its “Applications” view is SBOM-detected components, not an HTTP endpoint or attack-surface inventory. | ●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. | Arnica generates enriched CycloneDX SBOMs (JSON) and CSV across source, container images, and API-uploaded inputs — enriched with license, OpenSSF Scorecard, and reputation — with a “Zero Day” campaign filter, but no runtime SBOM of running services. | ◐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. | Arnica's policy engine is a trigger → condition → action workflow (30 conditions, first-match ordering, product-mapped routing) with ChatOps, PR-comment, fail-status-check, and ticketing (Jira / ADO Boards; ServiceNow coming soon) actions. It fires on SCM/scan events and routes by product, without owner-team resolution or fix-agent / SLO / SBOM actions inside the 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. | Arnica runs a time-based remediation SLA (SLA Start / TTR / Exceeded-SLA on up to ten SLA branches per asset) and auto-resolves a finding when a re-scan of the branch no longer detects it. There is no runtime-verified closure — resolution is confirmed by re-scanning the branch, not by confirming the fix in a running deployment — and no risk-band SLO engine beyond the SLA. | ●Heeler advantage |
| 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. | No documented capability. | ●Heeler advantage |
| 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. | Arnica ingests GitHub audit logs and uses source-control activity in behavioral analysis, permission decisions, application inventory, and access-risk findings. The same source-control security model also supports access-governance and remediation workflows. | ◑Arnica edge |
| 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. | No documented capability. | ●Heeler advantage |
WHERE HEELER ADVANCES
Where a runtime-native engine beats a code-and-SCM ASPM.
Each maps back to the one context engine — code to cloud — not a faster scanner on the repo.
01
Runtime and cloud context a code-and-SCM tool doesn't have
Arnica reasons about repositories, commits, and source files — a code-and-SCM view, but with no live cloud inventory, deployment topology, or internet-exposure model (its “business importance” is a repo-activity heuristic). Heeler builds a sensor-less model of where code actually runs — deployment-to-changeset mapping, service edges, service tier, ownership, and internet-accessibility — and that context is what makes exposure, prioritization, and routing real.
02
Prioritize by runtime exposure, not reputation and severity alone
Arnica ranks by severity, CVSS, EPSS, KEV, reputation, static code reachability, and a business-importance heuristic — but none of those signals says whether the affected service is deployed and internet-facing. Heeler gates a dependency finding on reachable AND internet-exposed AND not-mitigated, and traces SAST exposure from a real internet-facing entry point, so a live, exposed finding outranks a dormant one with the same CVSS.
03
Remediation proven in your CI, not re-scanned for absence
Arnica recommends upgrades and posts AI code suggestions, and marks a finding resolved when a re-scan no longer sees it. 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, opening a draft PR if the build didn't pass. A fix that reduces a scan count isn't the same as one proven to build and pass tests.
04
Operate to a runtime-verified close, with risk-band SLOs
Arnica has a time-based remediation SLA and resolves findings by re-scan. 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 — the difference between “no longer in the branch” and “no longer running anywhere.”
05
Beyond the repo: the attack surface and the agent files themselves
Heeler discovers your endpoint and API attack surface from source (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. Arnica inventories agent files and writes secure-coding rules into them, but doesn't map your API attack surface or vet those files as a risk. 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 Arnica is giving your developers real-time feedback today, we'll show what the runtime context adds on top.
