The foundation · Context Engine

Context is the difference. Heeler gathers it for you.

Many tools hand your code to an LLM and hope it reasons its way to the right answer. Security cannot run on hope: the same finding has to get the same answer every time. Heeler gathers the context itself, from your catalog and ownership to what actually runs, so it can be deterministic wherever security requires it, and use AI where it helps.

ReposDependenciesAPIsReachabilityData flowsApplicationsTiers 1 to 4Shared codeTeamsCODEOWNERSContributorsRoutingPromptsTool callsSkillsMCP serversCommitsKEVEPSSMalwareCampaignsScorecardDeploymentsRuntimeExposureImagesDatastorescodeCodedomainBusinessgroupsOwnershipsmart_toyAgentcrisis_alertThreatcloudCloudContextEngine
Fed by
code
Source control
cloud
Clouds and hosting
inventory_2
Registries
crisis_alert
Threat intelligence
laptop_mac
Workstation sensor
optional
What Heeler inventories

Everything you build and run, in one catalog.

Heeler builds the inventory itself. Source control fills in your code and agent files, the optional workstation sensor adds what agents actually do, and your cloud and registries add everything that runs.

From your code
folder_code
Repositories
view_module
Modules
account_tree
Dependencies
api
API endpoints
description
SBOMs
conversion_path
CI workflows
table
Data entities
key
Secrets
group
Contributors
From your agents
smart_toy
Agent files
extension
Skills and hooks
account_tree
Subagents
lan
MCP configs
forum
Sessions
sensor
chat
Prompts
sensor
terminal
Tool calls
sensor
commit
Agent commits
sensor
From your cloud
hub
Services
rocket_launch
Deployments
cloud
Cloud resources
grid_view
Kubernetes
deployed_code
Running images
public
Exposure
From threat intel
shield
Advisories
crisis_alert
KEV
trending_up
EPSS
coronavirus
Malicious packages
verified
Scorecard
sensor
From the optional workstation sensor. Everything else builds on its own once source control and your cloud are connected.
Automated service modeling
Patent pending

Every finding, linked to what runs, what matters and who owns it.

Heeler models how your code becomes a running service, where it is exposed, how critical it is and who owns it. Autotriage reads that model to decide what comes first. Here are two findings in one service, with two different answers.

EXAMPLE · TWO DEPENDENCY (SCA) FINDINGS IN ONE SERVICEfolder_codeRepositoryacme/paymentsview_moduleModuleservices/checkouthubServicecheckout-apirocket_launchDeploymenta1b2c3 · productionpublicCloud resourceLoad balancer · publicgroupsOwning team@payments-teamCODEOWNERSdomainApplicationPayments · Tier 1business impactdeployed_codeContainer imagecheckout:1.8.2runningbug_reportSCA findingCVE-2025-24813Defernot function reachablein the manifestmemoryRuntime evidencecommons-text loadedfound at runtimebug_reportSCA findingCVE-2022-42889Urgentloaded · public · Tier 1runtime onlydatabaseDatastore reachedorders-db · PIIchaining
What Autotriage reads here
function
Function reachability
memory
Found at runtime
public
Internet accessible
database
Datastore reached
domain
Service tier
crisis_alert
Threat intel: KEV, EPSS
Ownership and routing

Every finding goes to the team that should fix it.

Autotriage decides how urgent it is. Heeler then walks the ownership you already keep, from a rule for one package down to the repository's team, and stops at the first real team. That team gets a ticket, a message and an Auto-fix pull request.

bug_reportSCA findingCVE-2022-22965spring-beans · checkoutAUTOTRIAGEUrgentfix within 14 daysWHO OWNS IT? THE MOST SPECIFIC ANSWER WINS1dependency_owners.jsonrule for this packageNO MATCH2dependency_owners.jsonrule for this manifestNO MATCH3CODEOWNERSlast matching path winsMATCH@payments-team4Module teamset on services/checkoutNOT NEEDED5Repository teamsynced from GitHub, GitLab or PortNOT NEEDEDgroupsPayments teamOwner, fromCODEOWNERSconfirmation_numberTicketPAY project in JiraforumMessage#payments-securitymergeAuto-fix PRvalidated in your CINo team at any levelSkip, or send to a fallbackreportA rule that names a team that no longer exists is skipped and flagged, and the walk goes on.Every level is ownership you already keep. Teams sync every four hours.
Setup

Connect it all. Heeler builds the rest.

Each connection is an app install, a token or a read-only role, with nothing to change in your code or pipelines. Every one you add sharpens how Heeler ranks, routes and fixes.

folder_code
Source control
App or token
GitHub
GitLab
Bitbucket
Azure DevOps
add
Code, dependencies, teams
cloud
Cloud and hosting
Read-only role
AWS
Azure
Google Cloud
Kubernetes
Vercel
add
Deployments, exposure, runtime
inventory_2
Artifact registries
Token
JFrog
Nexus
CodeArtifact
Harbor
Docker Hub
GitHub
GitLab
Google Cloud
add
Images and packages
laptop_mac
Workstation sensor
Workstation install
Prompts
Tool calls
Commits
add
What your coding agents did
confirmation_number
Tickets
App or token
Jira
Linear
GitHub Issues
Shortcut
add
Where work lands
forum
Chat
App install
Slack
Microsoft Teams
Google Chat
add
Where alerts land

Heeler adapts to you, not the other way around

It reads what your teams already use and sends work back to the same places.

groups
Teams in GitHub, GitLab or Port
arrow_forward
Synced every four hours
description
CODEOWNERS and owner files
arrow_forward
Honored, most specific first
domain
Your applications and tiers
arrow_forward
Set in Heeler or synced
account_tree
Your pipelines and builds, as they are
arrow_forward
Nothing to add to CI
lock_open
Repositories without lockfiles
arrow_forward
Versions resolved for you
psychology
How each repository builds and tests
arrow_forward
Remembered by Auto-fix, plus your own notes
confirmation_number
Each team's ticket preferences
arrow_forward
Its own tool, project, issue type and fields
forum
Each team's messaging preferences
arrow_forward
Its own Slack, Teams or Google Chat channel
timer
Your fix timeframes
arrow_forward
Tracked against your SLOs
Not required
block
Pipeline integration
block
CI or build changes
block
Lockfiles in every repo
block
Manual service mapping
block
An owner spreadsheet

Compare approved designs with observed architecture

Use observed services and infrastructure to inform a threat model. Evaluate supported conformance checks against the approved model and retain evidence for code and deployed environments separately.

Design conformance checks
Purpose-built for the AI SDLC

See your context assemble automatically.