> 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/remediations.md). # Remediations ## Configuring How Remediations Are Assigned and Surfaced The **Remediations** page controls three things: how new remediations are assigned to owners, the health of the ownership sources Heeler uses to do that assignment, and a supply-chain safety check that delays surfacing brand-new package versions until they've had time to age. ### Where to find it Administration → **Program** → **Remediations** in the left sidebar. URL: `https://app.heeler.com/administration/program/remediations` ### Quick start 1. Pick an **Automatic Remediation Assignment** strategy (most teams start with *Last Developer to Update the Dependency* or *Dependency Owner*) and click **Save**. 2. Glance at **Ownership Source Drift** to confirm there are no stale team slugs or missing ownership-manifest paths. If drift is reported, fix it in the source — `CODEOWNERS` or `dependency_owners.json` — so routing works. 3. Set **Minimum Package Age** to a value that matches your supply-chain risk tolerance. 0 disables the check; many teams use 7–14 days to avoid recommending packages that may be withdrawn or compromised shortly after publish. ## Reference ### Automatic Remediation Assignment *Automatically add an assignee for remediations discovered in Heeler. Remediations with assigned owners remain unchanged.* Four mutually exclusive options: | Option | What it does | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tech Lead** | Assigns new remediations to the Tech Lead of the associated service, if available. | | **Last Developer to Update the Dependency** | Assigns new remediations to the last developer who updated the dependency, provided they have an identity in Heeler (which they typically do). This aligns with the *Suggested Assignees* value shown on a remediation. | | **Dependency Owner** | Routes new remediations to the **team** that owns the dependency, resolved from your ownership file or `CODEOWNERS`, instead of an individual developer. | | **No Automatic Assignment** | Remediations are not automatically assigned. | Important behavior notes: * **This setting only affects newly discovered remediations.** Remediations with an existing assigned owner are not changed when you switch strategies. * **Tech Lead** depends on tech-lead metadata being populated for the associated service. If it isn't, the remediation falls back to unassigned. * **Dependency Owner** routes to a *team*, not an individual. Pair this with Teams defaults so the team's notifications and ticket destination fire correctly. The **Save** button is disabled until you change the selection. ### Ownership Source Drift *Team slugs in your ownership sources that no longer match a live team, and `dependency_owners.json` manifest paths no longer present in the scanned tree. Resolve these so remediations route to the intended team.* This section is a **diagnostic surface**, not a setting. Heeler continuously checks your ownership sources for two kinds of drift: * **Stale team slugs** — names in your ownership manifest that no longer correspond to any live team in Teams. * **Missing manifest paths** — paths referenced in `dependency_owners.json` that no longer exist in the scanned repository tree. When the section reads **"No ownership-source drift detected"**, your ownership sources are clean. When drift is present, each item is listed with enough context to find and fix it at the source. Cleaning up drift is important because the **Dependency Owner** assignment strategy depends on these sources resolving correctly. There are no controls on this page to "fix" drift directly — repairs happen in the source files (your `CODEOWNERS`, your `dependency_owners.json`) or in Teams. ### Minimum Package Age *Require new package versions to have aged for a minimum number of days before they are surfaced as remediation candidates. Set to 0 to disable.* A single numeric field: | Field | Description | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | **Minimum Package Age (Days)** | Number of days a new package version must have been published before it can be recommended. **0 disables the check.** | When this is set above 0, Heeler will not recommend a package version as a remediation until it has been publicly available for at least the specified number of days. This is a supply-chain safety control: brand-new releases are statistically more likely to be yanked, withdrawn, or revealed to contain malicious content shortly after publish. > **Note:** this is applied on a best-effort basis. Some package ecosystems do not expose reliable publish timestamps, and remediations for those packages may be recommended regardless of this setting. The **Save** button is disabled until you change the value. #### Suggested values * **0** — no age requirement. Useful when you need to remediate urgent CVEs without delay. * **3–7 days** — catches most immediate yank-and-republish patterns without slowing remediation significantly. * **14+ days** — conservative; appropriate for highly regulated environments or after an industry-wide supply-chain incident. ## Related documentation * Service Level Objectives — remediation timelines that work in tandem with assignment * Teams — the teams that *Dependency Owner* assignment routes to * Agent PR Template — controls the body of fix PRs that the remediation agent opens * Auto-Fix (Deterministic Agentic Remediation) * Eliminating Dependency Debt at Scale with Agentic Remediation * Remediation Workbench — the day-to-day remediation view * New Remediation Available — workflow trigger fired when a remediation is ready --- # 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/remediations.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.