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.

01

Manual triage

Someone reads every finding to decide whether it's real and who should care — before any fixing starts.

02

Finding the owner

Mapping a finding to the team that owns the code eats hours, and the mapping goes stale as teams change.

03

Chasing the fix

Tickets sit with no clock and no clear owner. Backlog grows faster than anyone burns it down.

How it works

Trigger. Route. Act.

01 · TRIGGER

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

02 · ROUTE

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

03 · ACT

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.

WHERE IT FITS

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.

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.