.svg)
Security response, automated.
Heeler Workflows fire the moment a finding, secret, or malicious dependency appears — routing each to the owning team, opening the ticket, and auto-remediating vulnerable dependencies end to end. Event-driven, not campaign-scoped.
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. Route. Act.
An event fires a workflow
Workflows bind to events on a repository — a new dependency vulnerability (new_finding), a secret, a malicious package, or an expiring SLO — and fire the instant the event lands. No schedule, no campaign.
- 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
To the team that owns it
Heeler resolves the owning team from module and repository ownership — the ownership graph — then routes the ticket or alert there. No manual assignment; a fallback policy covers anything unmapped.
- 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
Notify, ticket, or fix
Each workflow runs one or more actions — post to chat, open a deduplicated ticket, adjust an SLO, or dispatch an auto-remediation. For a fixable dependency, the workflow opens the upgrade PR itself, waits for a green result, then notifies.
- 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.
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.
Workflows
Routing, tickets, and fixes after merge.
See Workflows on your findings.
Connect a repo and watch a real finding route to its owner, open a ticket, and — for a dependency — fix itself.
