> 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/prevent/pr-guardrails/building-guardrails/recommended-and-quick-start-guardrails.md).

# Recommended and Quick-Start Guardrails

Start from Heeler's recommended set, then tune it to your environment.

The fastest way to get value is to start from Heeler's **recommended set** — a small group of high-signal dependency guardrails that most teams should run. When you choose **Create Guardrail**, these are offered as one-click starting points (and Heeler will also [proactively suggest](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails/building-guardrails/ai-guardrail-assistant.md#suggested-guardrails) the ones you're missing).

<figure><img src="https://414480750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FXP3dp2kecwKA2KvYkntz%2Fuploads%2Fgit-blob-dd1c36893c0da248d97bd43574cdf41267a63a15%2Fcc-guardrails-list.png?alt=media" alt="The Guardrails list, each row with an enable toggle, success rate, module executions over the last 30 days, and violation and pull-request counts — including Block Compromised Dependencies, Minimum dependency age, and Warn on unapproved licenses."><figcaption><p>The <strong>Guardrails</strong> list — each guardrail's enable toggle, success rate, and the pull requests and violations it has produced.</p></figcaption></figure>

## The recommended set

| Guardrail                                | What it does                                                                                                                                               | Suggested action |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| **Compromised Dependencies**             | Blocks packages matching Heeler's malicious-package intelligence.                                                                                          | Block            |
| **Dependency with Known Active Exploit** | Blocks vulnerabilities under active exploitation. Pair with **Fix Version Available** so you only block when there's a way forward.                        | Block            |
| **Minimum Dependency Age**               | Enforces a cooldown so brand-new releases can't land immediately — a defense against fresh-package supply-chain attacks. Recommended **2 days**.           | Block or Warn    |
| **Risky & Unmaintained Dependency**      | Combines the **OSSF Unmaintained** signal with vulnerabilities that have **No Fix Available**, to flag dependencies that are both risky and going nowhere. | Warn             |
| **Unapproved License**                   | Flags dependencies whose license falls outside your policy.                                                                                                | Warn             |

{% hint style="success" %}
**Always pair vulnerability guardrails with&#x20;*****Fix Version Available*****.** For any Warn or Block guardrail built on vulnerability rules, add the **Vulnerability – Fix Version Available** rule so you only gate PRs when a fix actually exists — otherwise you block work no one can unblock.
{% endhint %}

## Reading the OSSF "unmaintained" score

The **Unmaintained Dependency (OSSF)** rule scores maintenance activity 0–10 — lower is riskier:

| Score  | Meaning                            |
| ------ | ---------------------------------- |
| **0**  | No activity in the last 90+ days.  |
| **3**  | Only external contributors active. |
| **5**  | Collaborator or owner activity.    |
| **10** | Frequent commits and releases.     |

Set the threshold to match how strict you want to be (e.g. flag anything at or below 3).

## Rolling it out

{% hint style="info" %}
Save each new guardrail in **Observe**, review the **Pull Requests** and **Violations** tabs to gauge volume, then promote to **Warn** and finally **Block** — and remember [Block only holds if it's enforced on the SCM side](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails.md#the-three-actions).
{% endhint %}

To tailor any of these, open [Creating and Scoping a Guardrail](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails/building-guardrails/creating-and-scoping-a-guardrail.md); to generate one from a sentence, use the [AI Guardrail Assistant](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails/building-guardrails/ai-guardrail-assistant.md).


---

# 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/prevent/pr-guardrails/building-guardrails/recommended-and-quick-start-guardrails.md?ask=<question>&goal=<endgoal>
```

`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.
