.svg)
Run the whole loop, not just the alert.
Detection tells you what's wrong. Everything after that — deciding whether it matters, finding who owns it, opening the ticket, writing the fix, validating it, and closing the loop — is the part that consumes your team. Heeler runs that end to end as a standing rule: one trigger, your conditions, and up to three actions that hand off to each other. Automatically, across every repository at once, at machine speed.
Most of AppSec is coordination, not security.
Every finding today means someone triaging it, finding the owner, opening a ticket, and chasing the fix. That coordination work is most of the job — and it doesn't scale with AI-speed code.
Manual triage
Someone reads every finding to decide whether it's real and who should care — before any fixing starts.
Finding the owner
Mapping a finding to the team that owns the code eats hours, and the mapping goes stale as teams change.
Chasing the fix
Tickets sit with no clock and no clear owner. Backlog grows faster than anyone burns it down.
Trigger. Conditions. Actions.
One trigger starts it
A new critical finding appears. A fix becomes available. An override is about to expire. A compromised package lands in a repo. A pull request merges with violations. One event per rule, so you always know why a workflow ran.
- New finding, secret, or malicious dependency detected
- New fix version available for an existing finding
- SLO expiring — 90-day look-ahead
- PR merged with unresolved guardrail violations
Conditions decide what proceeds
Optional filters, combined with AND. No conditions means it fires on everything matching. The workflow list shows matched over total runs, so a wide gap tells you your filters are earning their keep.
- Owning team resolved from CODEOWNERS + module ownership
- Routes to Jira, Linear, GitHub Issues, Slack, Teams, or Google Chat
- Fallback policy handles findings with no mapped owner
Up to three actions, in order
Actions run in sequence and share one context, so a later step can use what an earlier one produced — fix the finding, then announce that pull request, with the real URL in the message. Describe the rule in plain English and Heeler builds it.
- Slack, Teams, Google Chat, email, webhook, or ticket — deduplicated per finding
- Auto-remediation opens a validated dependency-upgrade PR, with an optional review gate
Backlog that burns down on a clock.
Every finding gets a remediation deadline set by its risk and severity — measured from detection to due date. Workflows watch that clock so nothing quietly ages out.
SLOs, measured from detection
An SLO is a remediation deadline derived from Heeler risk and severity. Workflows fire before it expires, escalate, or auto-extend with a documented reason — for both dependency and SAST findings.
Backlog burn-down, unattended
SLO and fix-available triggers fire on pre-existing findings too — auto-opening tickets or dispatching fixes so the backlog shrinks without an engineer starting it.
Guardrails on the automation
Per-tenant rate limits pause a runaway workflow and alert admins; every workflow carries a health state; templates ship as defaults you can override.
ACTIONS
Twelve actions. Three families.
Which actions are available depends on the trigger — a deployment-only action won't offer itself on a secret. Messaging and ticketing route to the owning team by default, so nobody has to look up who that is.
Fix with Heeler Agent
Generates the fix, validates it through your CI, and opens the pull request. It only runs when the finding is auto-fixable and a remediation exists — the condition is locked on for you, so a workflow can't promise a fix it can't deliver.
Ticketing — four trackers
Jira, Linear, GitHub Issues and Shortcut. Tickets de-duplicate on the workflow-and-finding pair, so a flapping finding doesn't spam the backlog. GitHub issue state syncs back to Heeler.
Messaging — four channels
Slack, Microsoft Teams, Google Chat and email, each templated with the finding's real details rather than a generic alert.
Update SLO Override
Extends a due date automatically — useful for findings that genuinely have no fix yet. You set the days, the reason recorded, and whether it counts from the original date or today. Idempotent: matching dates write nothing.
Send Webhook
POSTs the full event payload anywhere. URLs are validated before and after templating, and private, loopback and metadata addresses are rejected — a workflow can't be turned into an internal port scanner.
Generate SBOM
Produces a CycloneDX SBOM for the deployment in context, with nothing to configure — so an SBOM can be a consequence of shipping rather than a quarterly scramble.
WHERE THE HUMAN STAYS
Hands-off is a setting, not an assumption.
Running without a human in the loop is only worth having if you can see what it did and stop it. Every part of the automation is inspectable, reversible, and off by default until you say otherwise.
You decide whether review is skipped
The auto-fix action has exactly one option: skip review and open the pull request automatically. Leave it off and the fix waits for a person. Turn it on and the loop closes on its own. That toggle is the whole difference.
A pull request is still a pull request
Hands-off means Heeler does the work, not that the change bypasses your process. It lands as a PR, against your branch protections, validated by your CI.
The chain waits for the real outcome
When a fix is followed by a notification, the workflow pauses until the pull request reaches an outcome — so the message your team reads carries the actual PR, not an optimistic "started".
Failures stop rather than retry
If a destination errors, Heeler records it, notifies admins, and halts the remaining steps instead of hammering the endpoint. Health is shown per workflow: Unhealthy means something it depends on is broken.
One toggle turns any rule off
Disabling a workflow keeps it configured but stops it firing, and every run is on the record with its execution history and success rate. You can also run a workflow on demand against findings that already exist.
Heeler names the gaps you haven't covered
Suggested workflows call out missing automation using your own numbers — thousands of open findings with no rule watching for new ones — and only appear when they're actually possible for you, so the list stays honest.
One policy. Every layer of prevention.
Heeler runs the same policy everywhere your code moves, read from one model of your environment in the Context Engine. Workflows are the layer after merge — they don't replace the others, they share their policy and their findings.
Inside the AI coding agent, as code is generated.
In the terminal, before commit.
Native status checks on the pull request, server-side.
MCP Server & Agent Skills
Routing, tickets, and fixes after merge.
See the loop run on your findings.
A demo shows the coverage gaps Heeler would flag in your own posture — and what the loop closes without anyone touching it.
