Terminology

Below are common terminology used throughout the Heeler product.

Repository A centralized storage location where a project’s source code, history, and related artifacts are maintained under version control

Code Root A logical “entry point” or “service boundary” within a source-code repository. In monorepos (or any multi-service repository), each Code Root identifies a distinct application, microservice, module, or component—along with any configuration parameters it needs in order to build, test, or scan that slice of code in isolation.

Service A repository of code linked to a code root, serving a specific purpose that has been deployed to cloud infrastructure.

Deployment An instance of a service running on cloud infrastructure linked to its environment context.

Environment The runtime environment context of a service deployment:

• Unassigned

• Production

• Corporate

• Disaster Recovery

• Staging

• Test

• Development

• Sandbox

Application One or more services which interact together to solve a larger business problem.

Tier A classification that reflects not only how critical a service or application is to business operations, but also the sensitivity of data it handles, the potential for loss of customer trust, and the impact of downtime on availability.

• Tier 1: Severe Impact

  • Handles highly sensitive or regulated data (e.g., customer PII/PHI, payment information)

  • Any compromise or outage would cause major disruption to core business functions

  • Significant risk of legal or regulatory penalties

  • Loss of customer trust or brand damage would be extensive and immediate

  • Requires highest-level security controls, continuous monitoring, and rapid incident response

• Tier 2: High Impact

  • Processes sensitive data (e.g., internally critical but not fully regulated) or customer-facing functionality

  • An outage or breach would severely degrade business operations or customer experience

  • Elevated risk of reputational harm and erosion of customer confidence

  • Strong security measures and high-availability design are mandatory, with defined recovery-time objectives (RTO)

• Tier 3: Medium Impact

  • Holds moderately sensitive data or supports important but non-mission-critical processes

  • Interruption causes noticeable downtime and workflow inefficiencies, but does not halt core operations

  • Potential for moderate customer frustration and trust erosion if service is unavailable or data is exposed

  • Standard security practices and periodic availability reviews are required, with established but less stringent RTO/RPO targets

• Tier 4: Low (or No) Impact

  • Manages non-sensitive or public data (e.g., internal documentation, peripheral tools)

  • An outage has minimal effect on business continuity and customer perception

  • Very low risk of trust or brand damage Basic security hygiene and routine backups are sufficient; availability expectations are relaxed

Technical Lead The technical owner of an application, typically at a manager or director level, responsible for adherence to Heeler's service-level objectives (SLOs).

Security Lead The security owner who is informed and consulted on material changes and security activities.

Finding Assignee The contributor who is assigned and completes a remediation task.

Service Level Objective (SLO) An internal agreement that defines the timeframe for resolving a heeler finding. The SLO begins when Heeler first finds the issue statically or at runtime. The SLO is completed when Heeler detects the issue is resolved at runtime.

Priority The level of precedence assigned to a finding, often determined by:

• Business Impact: The degree of material or irreversible impact on the business.

• Environment Impact: The exploitability analysis of the finding including, including compromise accessibility and the potential for cascading effects.

• Threat: The likelihood of exploitation.

Lifecycle Status The status of a finding throughout its lifecycle:

• Found: Finding identified in code or at runtime.

• Coded: Fix for the finding is coded.

• Rollout: The fix is in the process of being rolled out.

Vulnerability

• First Seen - date/time when the finding was first detected by Heeler and the date SLO starts. Never before the vulnerability published date or Heeler setup.

• Last Seen - data/time when finding was last detected by Heeler.

• Vulnerable Since - date/time when the root cause of the finding is detected. Can be earlier than the published date. For example when a vulnerability is found on package v1, this would be the date when the package v1 was introduced into the code base (as the vulnerability existed prior to its publishing date).

Remediation A corrective action tied to a specific service or code root. If two code roots or services require the same remediation action, they are considered and listed as two different remediations as they can be implemented individually and can have different priorities and remediation complexities.

Remediation Strategy Defines the set of criteria and selection logic used to choose the optimal open-source package version when guiding customers through vulnerability remediation and automated upgrades.

Guardrail A rule applied to defined scope that is triggered on new changes.