.svg)
AI writes the code. Heeler decides what to fix first.
Coding agents generate findings faster than any team can triage. Heeler ranks each by what's genuinely exploitable in your environment — reachability, runtime exposure, business criticality, and active exploitation, not what CVSS guesses in the abstract — and the top of that queue flows straight into automated fixes, PR guardrails, and owner-routed workflows.
AI-speed findings, human-speed triage
Coding agents produce code — and findings — faster than any team can work them. Triaging by severity, the old playbook, never catches up. And severity was never risk: most “critical” findings sit in unreachable code, unused dependencies, sandboxed services, or expired secrets.
- Every CVE with CVSS ≥ 7.0
- Every SAST finding tagged “high”
- Every dependency ever declared in a lockfile
- Every secret ever pushed — valid or not
- Findings on code paths that execute in production
- Services exposed to the internet, or on a business-critical tier
- Packages loaded at runtime — not just declared
- Secrets that still authenticate to something live
The Context Engine does the math
Six dimensions of context, continuously assembled from your running system — then reduced to one risk model. No CVSS guesswork. No sensors, no tagging, no build modification.
Where the finding actually lives
Reachability, call graphs, framework awareness, and change history — across every repo and every branch.
Where the code actually runs
Deployed artifacts, network exposure, and service-to-service reachability — mapped without agents.
What the service is for
Customer-facing vs. internal, revenue-critical vs. experimental, regulated vs. sandboxed. Risk without business impact is theater.
Who owns and can fix it
Team, on-call, code owners, deploy cadence. Findings route to the right engineer at PR time — not to a stale queue.
What attackers are actually doing
Active exploitation, CISA KEV, malicious package activity, and threat intel — refreshed continuously.
What the AI is producing
The agent-instruction files, skills, and MCP configs in your repos — inventoried and scored for prompt injection and unsafe behavior, so a malicious skill surfaces as its own signal.
One graph. Six dimensions. Every prioritization, guardrail, and fix reads from the same shared model — updated continuously.
HEELER RISK
Every SCA and SAST finding lands on one of three levels.
Heeler scores dependency and code findings on three dimensions of context — business impact, runtime environment, and threat — and reduces them to a single action. (Secrets use live-validation status; Agent Skills use a 0–100 safety score.)
Reachable and internet-exposed on a high-tier service — or actively exploited (KEV). The runtime gate is open and attackers are moving.
Real risk, but not immediate — partial exposure or exploitability, or a lower service tier. Fix within its SLO window.
Not currently exploitable — unreachable, undeployed, mitigated, or sandboxed. Watched, and re-scored automatically if that changes.
Levels aren't static: a Defer becomes Urgent the moment a service goes internet-facing or an exploit lands — no rescan required.
ONE MODEL, FOUR SIGNALS
Prioritization that works across SCA, SAST, Secrets, and Agent Skills
Most vendors bolt separate scoring onto each finding type. Heeler runs every signal through the same runtime-anchored approach — exposure and reachability first, business and threat context always. Each ends in the scale that fits it: Heeler Risk for SCA and SAST, live-validation status for Secrets, a 0–100 safety score for Agent Skills. Here are the specific factors each one contributes.
Open Source (SCA)
Every dependency vulnerability scored on business impact, environment impact, and threat.
Business impact
- Service tier 1–4 — you set it to reflect what matters (data sensitivity, compliance scope, revenue); highest-tier-wins across shared repos
- Environment — production and corporate raise impact; staging, dev, and sandbox lower it
Environment impact (exploitability)
- Reachable library — loaded in a running deployment, and for Go reached in your call graph down to the vulnerable function
- Internet-accessible service
- Compromise — CVSS confidentiality / integrity / availability impact
- Chaining — can reach datastores and services
- Mitigation — overrides and sanitizers gate exploitability off
Threat
- CISA & VulnCheck KEV (known exploited)
- EPSS at or above 0.40
- Malicious / compromised packages
- Ransomware association
Code (SAST)
Heeler's own taint engine performs cross-function, cross-file analysis — confirming a real source-to-sink path and showing the dataflow — before a finding is scored.
Business impact
- Service tier 1–4
- Environment (production vs non-production)
Environment impact
- Internet accessibility — is the tainted entry point network-facing
- Authentication — internet-facing and unauthenticated is always High
- Chaining — can reach datastores and services
Threat
- CWE-class threat intelligence
- Weakness category & CAPEC likelihood
- Ransomware & active-campaign association
Findings are framework-aware (Express, Flask, Django, Spring, FastAPI, Lambda, Next.js and more) and carry the resolved HTTP route. Sanitizers, suppressions, and false-positive verdicts lower severity; findings showing active-compromise indicators bypass the matrix straight to Urgent.
Read about SAST →Secrets
Two questions, combined: how likely is this a real secret based on how it looks, and is it active right now?
Detection — confidence
- Provider-specific (High / Medium) — known formats such as AWS, Stripe, GitHub, via pattern matching, checksum validation where supported, and entropy thresholds
- Generic (Low) — client_secret, api_key, secret_key via broad patterns, with Shannon entropy filtering out low-entropy values like PASSWORD=password
Validation — is it live
- Checksum-aware (offline) — verify a token's internal checksum and reject structurally invalid credentials with no API call
- Active external — call the live provider (AWS, Azure, Google Cloud), test database connectivity, verify tokens against endpoints
Priority = confidence × validation
Agent Skills
Every agent-instruction file, skill, command, hook, and MCP config gets a deterministic 0–100 safety score (lower is riskier), flagged At Risk below 70. Score = 100 − Total Risk — same file, same version, same number, no stochasticity.
Score breakdown
- Static Risk — deterministic pattern matches in the file
- LLM Risk — the judge's categorized semantic findings
- External Risk — external hosts referenced, tiered by reputation
- Total = the three combined, or the verdict's risk floor if higher
Deterministic static analysis
LLM-assisted analysis
Every signal maps to MITRE ATLAS and the OWASP LLM Top 10. Trusted developer infrastructure can be allowlisted to reduce external-system noise — allowlisting never suppresses other findings.
Read about Agent Skills →SLO MANAGEMENT
Set the clock. Then let it run itself.
An SLO — service level objective — is the deadline a finding must be resolved by. You set the policy; Heeler enforces it, watches it, and automates the busywork around it.
Set day budgets per level and choose the basis: SCA SLOs by Heeler Risk (Urgent / Plan / Defer) or by CVSS severity; SAST SLOs by Heeler Risk or by rule severity.
An SLO guardrail warns or blocks pull requests while the repository has findings past their SLO — so new work doesn't stack on top of overdue risk.
Workflows manage the clock for you: when a new SCA finding has no fix available, auto-extend its SLO with a documented reason; when the fix ships, reset it to the policy deadline — no standing spreadsheet of exceptions.
EXCEPTIONS
Exceptions that expire, not exceptions that pile up.
Every program needs exceptions — the problem is that they become permanent. Heeler splits them into two audited controls, and time-boxes the one that matters.
When one finding's deadline is wrong — no upstream fix yet, or a major-version migration — move that finding's due date with a reason: No Fix Available, Fix Complexity, or Not a Priority. The original deadline is preserved beside the new one for audit. It doesn't lower the risk score or hide the finding.
When a finding isn't worth fixing — not reachable, false positive, mitigated by the environment — accept the risk and Heeler recomputes its priority down, out of the active queue. Acceptance is time-boxed: set an expiry, and when it lapses Heeler reverses the override, restores the original risk, and re-opens the finding for triage.
Every set, extend, and reset is written to the finding's history — who, when, why, and the before/after values. SAST adds triage states and severity recast; license exceptions are a separate, equally time-boxed surface.
Prioritization that ends in a fix
When every finding carries reachability, ownership, and a fix path, the top of the queue doesn't just get seen — it gets fixed, fast enough to keep up with AI-generated code.
The highest-risk findings flow straight into deterministic remediation — validated, merge-ready pull requests. Prioritization ends in a fix, not a ticket.
Scoring is automatic and re-runs as code ships, services deploy, and threats shift — so the queue stays correct without an analyst re-triaging by hand.
Diff-only guardrails and owner-routed workflows put the few findings that matter in front of the right engineer at the right moment — not 47 that don't.
Prevent. Fix. Audit.
Prioritization is the connective tissue. Every other Heeler capability reads from the same Context Engine — so a finding scored high here becomes a fix, a guardrail, or a policy elsewhere.
Deterministic Agentic Remediation
Prioritized findings become validated, merge-ready PRs — automatically. Fixes, not tickets.
PreventPR Guardrails
Block, warn, and observe at merge time — based on real risk, not policy theater.
PreventMCP & Agent Skills
Push prioritized policy directly into Claude Code, Cursor, and GitHub Copilot at generation time.
FoundationThe Context Engine
The six-dimension model behind every prioritization decision — continuously updated.
Common questions
How is this different from CVSS-based prioritization?
CVSS scores the vulnerability in isolation. Heeler scores your specific exposure: is the vulnerable code reachable, is the service exposed to the internet, how business-critical is the service, is anyone actively exploiting it. The same CVE can be a P0 in one service and irrelevant in another.
Does Heeler need agents, sensors, or build changes?
No. The Context Engine assembles all six dimensions from the systems you already run — SCM, CI, cloud APIs, IDP, threat intel — without touching your build pipeline or deploying anything inside your services.
How does prioritization stay current as cloud and code change?
The Context Engine refreshes continuously. When a service goes from internal to internet-facing, or a package upgrade removes a vulnerable code path, every dependent finding is re-scored automatically — without a rescan.
See prioritization done correctly
A 30-minute walkthrough with your own repos and cloud. No sensor install. No build changes. Just the Context Engine, running against your code.
Book a demo
