.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, SAST, and IaC finding lands on one of three levels.
Heeler scores dependency, code, and infrastructure 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.
EVERY FINDING TYPE, ITS OWN INPUTS
One decision model, different evidence.
Most vendors bolt one severity score onto everything and call it prioritization. Heeler asks the same three questions of every finding — what is it worth, how exposed is it, what's happening in the wild — but the evidence that answers them is specific to the finding type, and all of it comes from your own code and cloud. Each ends in the scale that fits it: Heeler Risk for SCA, SAST and IaC, live-validation status for Secrets, a 0–100 safety score for Agent Skills.
Open Source (SCA)
A dependency vulnerability has to clear a three-part exploitability gate before it can be anything but Defer: the library is loaded in a running deployment and your call graph actually reaches the vulnerable function; the service is internet-exposed; and no mitigation applies. Fail any one and it drops to Defer, whatever the CVSS says.
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 — loaded in a running deployment and reached in your call graph down to the vulnerable function. Both checks must agree
- 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)
Your own code runs by definition, so the question isn't whether it executes — it's how exposed the vulnerable path is. Heeler's taint engine traces cross-function and cross-file from source to sink, then judges exposure from that real path, plus authentication, sensitive data on the path, and whether an attacker could pivot from there.
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 →Infrastructure (IaC)
A misconfiguration is a property of a declaration — there's no taint path to trace. So Heeler scores what the definition actually builds: every finding is tied to the exact resource it configures, then scored by the same three-factor model as code findings — with exposure read from the cloud deployment graph of the service standing it up, not guessed from the template.
Business impact
- Service tier 1–4
- Environment — production raises impact; staging, dev, and sandbox drop straight to Defer
Environment impact
- Internet accessibility — read from the deployment graph of the service the definition builds
- Not deployed means not exposed — a definition nothing runs scores down, whatever the file says
- Chaining — can the standing service reach datastores and other services
Threat
- CWE-class threat intelligence — known-exploited weakness classes rank High
- Weakness category & CAPEC likelihood
- Active campaigns targeting a weakness class promote it
Coverage spans Terraform, OpenTofu, CloudFormation, Pulumi, and Kubernetes manifests. Every finding records the resource it evaluated — the bucket, the security group, the deployment — so "a Terraform file has a High finding" becomes "this bucket is public." Bands re-score as your cloud changes, a dedicated IaC guardrail catches new misconfigurations at the PR, and workflows route findings by resource type or framework.
Read about IaC →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, subagent, hook and MCP config gets a 0–100 safety score — higher is safer — and anything below 70 is flagged At Risk. The rollup is deterministic: the same file content produces the same score every time, with no stochasticity to argue about.
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
An assessed intent of Suspicious or Malicious caps the score into the At Risk band regardless of what the individual factors total. Trusted developer infrastructure can be allowlisted to reduce external-system noise — allowlisting never suppresses other findings.
Read about Agent Skills →DEPENDENCY FINDINGS · EXPLOITABILITY
For dependencies, exploitability is a gate.
A dependency vulnerability has to clear three checks before it can be anything other than Defer, and all three must hold. Fail any one and environment impact drops to Low and the finding is deferred — whatever its CVSS score says. This is the single biggest reason a Heeler queue is shorter than a scanner's.
Reachability, proven two ways
The library has to be loaded in a running deployment, and your call graph has to actually reach the vulnerable function. Both must agree. A library can ship in an image, run in production, and still be safely unreachable because nothing you wrote calls the vulnerable code.
Internet exposure, read from your cloud
An active deployment of the affected service has to run on compute that is reachable from the internet — taken from your connected cloud and runtime, not inferred. The identical CVE on an internal-only service pulls impact down.
Nothing already mitigating it
A sanitizer detected in the data path, a "no reachable vulnerable functions" result from the call-graph analysis, or a risk override you recorded yourself — any of these flips exploitability off.
Only then: how much damage
Findings that clear the gate get graded further. CVSS confidentiality and integrity impact decide total versus partial compromise, and whether the deployment can reach datastores, secrets or a Tier-1 service decides whether it escalates.
Threat is observed, not predicted
Confirmed exploitation on CISA KEV or VulnCheck KEV — or a malicious package — sets threat High. An EPSS score at or above 0.40 sets it Medium. KEV membership alone isn't enough: provisional entries don't count.
Shared libraries inherit the worst case
One library usually lives in many repositories, so Heeler applies the highest tier of any active service using it. A package shared between a sandbox and your payments service is treated as payments-critical.
CODE FINDINGS · EXPOSURE
For code, exposure is judged from the path.
Code is asked a different question. A dependency has to clear the exploitability gate above — is the vulnerable function actually called, is the library actually loaded. Your own code runs by definition, so the question becomes whether an attacker can reach the vulnerable line. Heeler answers that from two independent signals: whether the deployed infrastructure is reachable from the internet, and whether the traced data flow starts at an inbound network entry point.
Confirmed
Exposed infrastructure and a path that traces back to an inbound network entry point. The strongest signal available: someone outside can reach this code.
Infrastructure
The infrastructure is exposed but the flow's origin isn't established yet. Treated as accessible on purpose — where the evidence is incomplete, Heeler errs toward caution rather than quietly discounting it.
Not accessible
Either the infrastructure isn't exposed, or the origin is known and isn't a network entry point at all.
A public service isn't a reachable path
A weakness fed by a file, a scheduled job or a config value is Not accessible even on internet-facing infrastructure. Because the verdict keys off the traced flow, "the service is public" never gets to stand in for "an attacker can reach this line".
Sensitive data on the path
Credentials, PII, PHI, auth context or financial data on the vulnerable path raises the level — including a SELECT * against a sensitive table like users, accounts or payments. Worth more to an attacker, so it ranks higher for you.
One thing overrides the whole model
A finding in the indicator-of-compromise lane is pinned to Urgent — exposure and threat both forced High — regardless of service tier. Evidence of active compromise should never be deferred because it happened to land on something low-value.
Never warned about an impossible weakness
Heeler drops weakness classes that can't manifest in the finding's language — no memory-safety warnings on memory-safe code. And a weakness class an active campaign is targeting gets promoted a level.
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. Record one decision across a whole rule, module, or triage session by selecting the findings it covers, then review every live exception in one register: what's been accepted, who accepted it, and what's about to lapse. SAST adds triage states and severity recast; license exceptions are a separate, equally time-boxed surface.
OUTCOMES
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.
Top of the queue → merge-ready PRs
The highest-risk findings flow straight into deterministic remediation — validated, merge-ready pull requests. Prioritization ends in a fix, not a ticket.
Keeps pace with AI-generated code
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.
Developers see only what's real
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.
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
