> For the complete documentation index, see [llms.txt](https://learn.heeler.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.heeler.com/tenant-admin-guide/program/service-level-objectives.md). # Service Level Objectives ## Configuring Service Level Objectives #### Overview The **Service Level Objectives** page is where administrators define the remediation timelines that Heeler enforces against findings. SLOs determine when a finding is considered *on track*, *due soon*, or *overdue*, and they drive the SLO status surfaced throughout the product — including the Remediation Workbench, Priorities dashboard, `/heeler slo` Slack queue, and SLO Guardrails. SLOs are configured separately for **dependency (SCA) findings** and **SAST findings**, since each finding type can use a different prioritization model. Each section lets you pick a strategy and then set the number of days allowed to remediate findings in each bucket. #### How to Access the SLO Settings 1. Open the **Administration** section from the top navigation 2. Select the **Program** tab 3. From the left-hand menu, choose **Service Level Objectives** The URL is: `https://app.heeler.com/administration/program/service_level_objectives` You'll see two configuration cards: **Dependency SLOs** and **SAST SLOs**. Each card has its own strategy tabs and its own **Save** button — settings are saved independently per card. *** ## Dependency SLOs > *Set SLOs for dependency vulnerability findings. Changes will be reflected for all Active findings.* Dependency SLOs apply to findings produced by Heeler's SCA pipeline (open-source library vulnerabilities). Choose one of two strategies: #### Strategy: Heeler Risk **Description (in product):** *"SLOs will be based on the priority assigned to each finding."* With this strategy, the SLO assigned to a finding is determined by the **Heeler Risk priority** Heeler calculates for it — combining technical severity, exploitability, runtime reachability, and business impact. Use this when you want remediation timelines to reflect *real-world risk* rather than raw CVSS score. Buckets and fields: | Bucket | What it represents | | ---------- | --------------------------------------------------------------------- | | **Urgent** | Highest-priority findings — exploitable, reachable, business-critical | | **Plan** | Findings that should be remediated in a normal sprint cadence | | **Defer** | Lower-priority findings that can be addressed on a longer horizon | Each field accepts the number of days allowed to remediate a finding in that bucket. #### Strategy: CVSS Severity **Description (in product):** *"SLOs will be based on the severity derived from the finding's CVSS score."* With this strategy, the SLO assigned to a finding is determined purely by the finding's **CVSS severity rating** (Critical / High / Medium / Low), regardless of exploitability or runtime context. Use this when your security or compliance program (e.g., SOC 2, ISO 27001, FedRAMP, PCI DSS) ties remediation timelines directly to CVSS severity. Buckets and fields: | Bucket | CVSS score range | | ------------ | ---------------- | | **Critical** | 9.0 – 10.0 | | **High** | 7.0 – 8.9 | | **Medium** | 4.0 – 6.9 | | **Low** | 0.1 – 3.9 | Each field accepts the number of days allowed to remediate a finding in that severity bucket. *** ## SAST SLOs > *Set SLOs for SAST findings. Changes will be reflected for all open findings.* SAST SLOs apply to findings produced by Heeler's SAST (source-code) pipeline. Choose one of two strategies: #### Strategy: Heeler Risk **Description (in product):** *"SLOs will be based on the Heeler Risk assigned to each finding by the SAST risk pipeline."* The SLO is determined by the **Heeler Risk priority** the SAST risk pipeline assigns to each finding — incorporating rule severity, exploitability of the affected code path, and business context. Use this when you want SAST remediation timelines to mirror real-world risk rather than the rule's intrinsic severity alone. Buckets and fields: | Bucket | What it represents | | ---------- | ------------------------------ | | **Urgent** | Highest-priority SAST findings | | **Plan** | Standard-priority findings | | **Defer** | Lower-priority findings | Each field accepts the number of days allowed to remediate a finding in that bucket. #### Strategy: Rule Severity **Description (in product):** *"SLOs will be based on the rule's intrinsic severity (CRITICAL, HIGH, MEDIUM, LOW) — this is set by the SAST rule definition, not derived from CVSS. Findings with INFO, NONE, or UNKNOWN severity have no SLO."* The SLO is determined by the **intrinsic severity declared by the SAST rule** that produced the finding. Note that this severity is set by the rule definition itself and is *not* derived from CVSS scoring. Buckets and fields: | Bucket | Source | | ------------ | --------------- | | **Critical** | Rule definition | | **High** | Rule definition | | **Medium** | Rule definition | | **Low** | Rule definition | > **Important:** Findings whose rule severity is **INFO**, **NONE**, or **UNKNOWN** will not have an SLO applied under this strategy. *** ## Saving Changes Each section has its own **Save** button. The button becomes active when there are unsaved changes (a strategy switch or a value edit). Click **Save** to commit your changes — they take effect immediately and will be reflected across all open / active findings. Switching between strategy tabs without saving allows you to compare configurations without altering current behavior. If you leave the page without saving, your changes are discarded. *** ## How SLO Settings Are Applied * **Scope:** SLOs are tenant-wide. There is no per-team or per-service override on this page — for exception handling, use SLO Overrides on individual findings. * **Re-calculation:** When you save a change, Heeler re-calculates SLO due dates for all open findings of the affected type (dependency or SAST). The **First Seen** timestamp is not changed, but each finding's `slo_due_date` will be updated to reflect the new policy. * **SLO start date:** The SLO clock starts when Heeler **first detects** the finding (statically or at runtime). See Terminology for details on `slo_started_at` and related fields. * **SLO completion:** An SLO is considered complete when Heeler observes the finding resolved at runtime. *** ## Related Documentation * [Choosing Your SLO Strategy](/use-cases/choosing-your-slo-strategy.md) — guidance on selecting between Heeler Risk and CVSS / Rule Severity * [Automating SLO Management](/use-cases/automating-slo-management.md) — configuring SLO Guardrails and severity-based overdue thresholds --- # 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: ``` GET https://learn.heeler.com/tenant-admin-guide/program/service-level-objectives.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.