> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/reference/glossary.md). # Glossary Definitions of the terms you'll meet across Heeler. Definitions of the terms you'll meet across Heeler. ## Findings and analysis * **Finding** — anything Heeler detects across your software — a dependency vulnerability (SCA), a code weakness (SAST), an infrastructure misconfiguration (IaC), an exposed secret, or a risky agent file — scored by the real-world context of where and how your code runs and tracked through the [finding lifecycle](/mrecEO40m5D6bt7Pq5pE/findings.md). * **SCA (Open Source)** — analysis of your open-source dependencies for known vulnerabilities and supply-chain risk. * **SAST (Code Security)** — static analysis of your own source code for weaknesses (injection, taint data-flows, insecure configuration, …). * **IaC (Infrastructure as Code)** — analysis of the infrastructure definitions in your repositories — Terraform, OpenTofu, CloudFormation, Pulumi, Kubernetes — for misconfigurations. See [Infrastructure as Code (IaC)](/mrecEO40m5D6bt7Pq5pE/findings/iac.md). * **Resource type** — the concrete resource an IaC finding evaluated (an S3 bucket, a security group, a Kubernetes deployment), recorded on the finding and available as a filter. * **Secret** — an exposed credential detected in source or git history; see [Supported Secret Types](/mrecEO40m5D6bt7Pq5pE/reference/supported-secret-types.md). * **Agent file** — an AI-agent instruction file, skill, subagent, hook script, or config that Heeler inventories and scores for risk; see [Agent Files](/mrecEO40m5D6bt7Pq5pE/findings/agentic-supply-chain-agent-files.md). * **Safety Score** — the **0–100** score Heeler assigns each agent file (**higher is safer**); anything **below 70** is flagged **At Risk**. It rolls up Static, LLM, and External risk, and an assessed intent of **Suspicious** or **Malicious** caps it into the at-risk band. * **License violation** — a dependency using a license your [policy](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/license-policy.md) denies. * **Compromised / malicious package** — a package that is itself the threat: known-malicious, or a legitimate project whose release was compromised. Heeler treats it as a supply-chain finding, not a routine CVE. * **Dependency (direct / transitive)** — a third-party package your code relies on. **Direct** — declared in your manifest; **transitive** — pulled in indirectly by another dependency. * **Finding lifecycle** — **Active → Fixed → Deployed**. **Active** (open, not yet fixed) → **Fixed** (merged in code, not yet confirmed running everywhere) → **Deployed** (rolled out to *all* running deployments, confirmed from runtime). Only **Deployed** means the fix reached every deployment that ran the vulnerable code. * **First Seen** — when Heeler first detected a finding (statically or at runtime). It starts the [SLO](/mrecEO40m5D6bt7Pq5pE/operate/service-level-objectives-slos.md) clock and never moves, even when a policy changes. ## Prioritization * **Heeler Risk** — a finding's real-world risk, combining **Business**, **Environment**, and **Threat** impact. For SCA, SAST, and IaC it lands on the **Urgent / Plan / Defer** bands. See [Prioritize (Heeler Risk)](/mrecEO40m5D6bt7Pq5pE/fix/prioritize-heeler-risk.md). * **Urgent / Plan / Defer** — the three risk bands: fix now / schedule / track. A *sequencing* signal — nothing drops off the list, it just waits its turn. * **Business Impact** — impact from the affected service's **tier** and deployment **environment**. * **Environment Impact** — impact from current exposure: reachability, internet accessibility, chaining to other systems, CVSS impact, and any mitigation. * **Threat** — real-world exploitation signals: CISA/VulnCheck **KEV**, **EPSS**, malicious/compromised packages, ransomware association, and weakness intelligence. * **Reachability** — whether your code reaches the vulnerable function (**code reachability** — call-graph tracing across Go, Java, Python, JavaScript/TypeScript, Rust, and Ruby) and whether it's loaded in a running deployment (**runtime reachability**). A vulnerable but unreachable library is not exploitable. * **Internet accessibility** — whether a service, deployment, or endpoint is reachable from the public internet — a major input to Environment Impact. * **Exploit Threat** — a finding's rolled-up exploitation likelihood: **Confirmed · Probable · Unlikely**. * **EPSS** — Exploit Prediction Scoring System: a 0–1 probability that a vulnerability will be exploited. Heeler treats **≥ 0.40** as a high signal. * **KEV** — Known Exploited Vulnerabilities: the CISA and VulnCheck catalogs of vulnerabilities confirmed exploited in the wild — a strong Threat signal. * **Exploitability** — reachable **and** running **and** not mitigated. * **Fixability** — how straightforward a remediation is: Easy / Medium / Hard / Unknown. * **Auto-Fixable** — a finding Heeler can generate and validate a fix for. * **Tier** — a service's business criticality, **1 (most critical) to 4**, that you assign; it drives Business Impact. A shared dependency inherits the **highest tier** of any service that uses it. * **SLO** — a remediation deadline for a finding, set by risk or severity; see [Service Level Objectives (SLOs)](/mrecEO40m5D6bt7Pq5pE/operate/service-level-objectives-slos.md). * **SLO Override** — a per-finding exception to the tenant-wide SLO — extend or set a due date, with a reason. Recorded and reviewable. * **Risk Override** — an auditable adjustment to a finding's calculated Heeler Risk when your context differs from Heeler's assessment. ## Model and catalog * **Context engine** — Heeler's approach: it builds a live model and reasons over it, rather than emitting raw scanner output. See [The Context Model](/mrecEO40m5D6bt7Pq5pE/overview/the-context-model.md). * **Six dimensions of context** — the inputs Heeler weaves into its model: **Agent, Code, Cloud, Business, Ownership,** and **Threat**. * **ProductDNA** — the connected model those dimensions form — repositories, services, deployments, and applications — that every finding is scored against. It is why the *same* vulnerability can be **Urgent** on one service and **Defer** on another. Both stay open and both carry an SLO. * **Code-to-cloud correlation** — linking running deployments back to the source code that produced them, so a finding is tied to where it actually runs and a fix can be tracked all the way to **Deployed**. * **Catalog** — the inventory Heeler builds automatically from your connections (repositories, dependencies, endpoints, services, deployments, infrastructure, contributors, and files). See [Catalog](/mrecEO40m5D6bt7Pq5pE/catalog.md). * **Repository** — a monitored source-code repository, the top-level unit Heeler analyzes; it may contain several modules. * **Module / code root** — a build or service boundary *within* a repository — a distinct application, microservice, or component. The **code root** is the manifest/lockfile path that defines it (e.g. `engine/requirements.txt`), and it's the scope for analysis, prioritization, and remediation — essential for monorepos. * **Service** — a runtime service Heeler maps from cloud back to the code that produced it; the unit that carries tier, exposure, and the code-to-cloud model graph. See [Services](/mrecEO40m5D6bt7Pq5pE/catalog/services.md). * **Application** — a business-level grouping of repositories and services that deliver an outcome; ownership and tier propagate to its members. See [Applications](/mrecEO40m5D6bt7Pq5pE/catalog/applications.md). * **Deployment** — a running instance of a service in a given environment, with its changeset, exposure, and runtime SBOM; it's what confirms a fix reached **Deployed**. See [Deployments](/mrecEO40m5D6bt7Pq5pE/catalog/deployments.md). * **Environment** — the boundary that classifies where code runs — **Production, Corporate, Staging, Development, Test, Sandbox,** and more — grouped into **High / Low** business impact that feeds prioritization. See [Environments](/mrecEO40m5D6bt7Pq5pE/get-started/map-your-organization/environments.md). * **Team** — an ownership grouping of repositories, synced from GitHub, GitLab, or Port.io; it drives access, security visibility, and ticket routing. See [Teams](/mrecEO40m5D6bt7Pq5pE/get-started/map-your-organization/teams.md). * **Broker** — a Heeler-provided component you run in your environment to analyze **on-premise artifact registries** and collect **Kubernetes inventory**, without that data leaving your network. (Self-hosted source control connects directly, not via the broker.) See [On-Premises Broker](/mrecEO40m5D6bt7Pq5pE/get-started/registries-and-artifacts/on-premises-broker.md). ## Prevent, Fix and Operate * **Guardrail** — a policy enforced on a pull request as a native status check, with an action of **Observe / Warn / Block**. See [PR Guardrails](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails.md). * **Observe / Warn / Block** — the three guardrail actions: silently record / surface a warning (merge allowed) / fail the check (merge blocked). A natural rollout path — start at Observe, tighten to Block. * **Guardrail entity types** — the checks a guardrail can enforce: **Dependency Vulnerabilities, Dependency Hygiene, Source Code (SAST), IaC Misconfigurations, Malicious Files (IOC), Secrets, SLO Violations, Agent File Static Findings,** and **Agent File Change**. See [Guardrail Types](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails/guardrail-types.md). * **Remediation** — an upgrade recommendation that resolves one or more findings, grouped per package per place it's used (a fix unit). * **Agentic remediation (Fix with Heeler Agent)** — Heeler's agent generating a fix, validating it through your build/tests, and opening a pull request. * **Validated / Merge-Ready** — a fix Heeler has proven before you review it — built and validated in an isolated sandbox *before* the PR, then driven through your own CI *after* it. See [Validate and Merge-Ready](/mrecEO40m5D6bt7Pq5pE/fix/validate-and-merge-ready.md). * **CI Testing Loop** — the phase after the fix PR opens where Heeler listens for your CI results, reads any failing logs, and pushes follow-up commits until checks are green — up to **5 attempts** before it hands off with an explanation. * **Workflow** — a standing **trigger → conditions → actions** automation (one trigger, conditions AND-ed, up to three actions) that runs the response side of the lifecycle — routing, ticketing, messaging, extending SLOs, or fixing. See [Workflows](/mrecEO40m5D6bt7Pq5pE/operate/workflows.md). * **CLI (`heelercli`)** — Heeler's command-line tool for running checks locally and in CI. * **MCP server / Agent Skills** — ways to bring Heeler into an AI coding agent; see [MCP Server](/mrecEO40m5D6bt7Pq5pE/prevent/mcp.md) and [Agent Skills](/mrecEO40m5D6bt7Pq5pE/prevent/agent-skills.md). * **SBOM** — a CycloneDX software bill of materials Heeler can generate for a repository, service, or deployment. ## Access * **Roles** — **Team viewer · Team contributor · Organization viewer · Organization contributor · Administrator (read-only) · Administrator**; see [Roles and Permissions](/mrecEO40m5D6bt7Pq5pE/get-started/users-and-access/roles-and-permissions.md). * **SSO / SCIM** — SAML 2.0 single sign-on and SCIM 2.0 provisioning. {% hint style="info" %} Looking for concept-level explanations rather than definitions? See the [Overview](/mrecEO40m5D6bt7Pq5pE/overview.md). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/reference/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.