> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chainloop.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# SCM Protection Policies

<Note>
  This feature is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing).
</Note>

While using the Chainloop CLI Enterprise Edition to gather the extended [runner context](/reference/runner-context) Chainloop allows you to define policies that verify the good practices and security configuration related to your CI/CD environment.

## Supported policies

The following policies are supported and can be used with the [runner context](/reference/runner-context) data.

### Branch protection

* **branch-deletion-blocked** - Ensures that branch deletion is blocked to protect important branches from accidental deletion.
* **branch-force-push-blocked** - Ensures that force pushes are blocked on branches to prevent bypassing code review and history integrity.
* **branch-linear-history-required** - Ensures that branches require linear history to prevent merge commits and maintain a clean commit history.
* **repository-rules-change-restricted** - Ensures that repository rules can only be changed by approved teams, protecting against unauthorized modifications to security policies.

### Pull request protection

* **pr-code-owner-review-required** - Ensures that code owner reviews are required for pull requests.
* **pr-conversation-resolution-required** - Ensures that all conversations on pull requests must be resolved before merging.
* **pr-review-required** - Ensures that pull requests require a minimum number of reviewers before merging.
* **pr-stale-reviews-dismissed** - Ensures that stale pull request reviews are automatically dismissed when new commits are pushed.

### Pull request quality

These policies evaluate built-in attestation metadata captured automatically by Chainloop and do not require runner context data.

* **pr-description-required** - Ensures that pull requests have a description providing context about the changes.
* **pr-user-story-linked** - Ensures that pull requests are linked to a user story or issue for traceability.

### Tag protection

* **tag-deletion-blocked** - Ensures that tag deletion is blocked to prevent supply chain attacks via tag manipulation.
* **tag-force-push-blocked** - Ensures that force pushes to tags are blocked to prevent tag history rewriting.
* **tag-rules-change-restricted** - Ensures that tag protection rules can only be changed by authorized actors.

These policies are also available as the **tag-protection** policy group, which bundles all three together:

```yaml theme={"dark"}
policyGroups:
  - ref: tag-protection
    with:
      tags: "v**"
      authorized_bypass: "role:Repository Admin"
```

### Patch management

* **patch-policy-present** - Verifies that automated patch management tooling is configured and actively monitoring third-party dependencies for known vulnerabilities. On GitHub, checks that Dependabot security updates are enabled. On GitLab, checks for the presence of a Renovate configuration file.

This policy evaluates the runner context data and can be added to your existing SCM configuration check contract:

```yaml theme={"dark"}
policies:
  materials:
    - ref: patch-policy-present
```

### Immutable releases

* **immutable-releases-enabled** - Verifies that GitHub Immutable Releases is enabled for the repository. When enabled, published release artifacts and their associated tags cannot be modified or deleted, protecting the integrity of the software supply chain. This is a GitHub-specific feature; the policy skips on GitLab repositories.

```yaml theme={"dark"}
policies:
  materials:
    - ref: immutable-releases-enabled
```

### Bot PR verification

* **pr-bot-author-allowed** - Verifies that a PR/MR was authored by one of the allowed bot accounts. Useful for gating workflows that should only accept PRs from automated tools such as Dependabot or Renovate.

This policy evaluates `CHAINLOOP_PR_INFO` metadata and accepts an optional `allowed_bots` input (comma-separated list of bot login names). If not specified, it defaults to `dependabot[bot]` and `renovate[bot]`.

<Info>
  On GitLab, bot detection relies on the [`author.bot`](https://docs.gitlab.com/api/users.html) field from the Merge Request API. Regular user accounts used for automation (e.g., Renovate with a PAT) will **not** be detected as bots unless provisioned as a [GitLab service account](https://docs.gitlab.com/api/group_service_accounts.html). You can also add the username to the `allowed_bots` input explicitly. See the [Gating Bot-Authored PRs guide](/guides/pr-policies-control-gate#gating-bot-authored-prs) for details.
</Info>

<Tabs>
  <Tab title="GitHub">
    ```yaml theme={"dark"}
    policies:
      materials:
        - ref: pr-bot-author-allowed
          gate: true
          with:
            allowed_bots: "dependabot[bot],github-actions[bot]"
    ```
  </Tab>

  <Tab title="GitLab">
    ```yaml theme={"dark"}
    policies:
      materials:
        - ref: pr-bot-author-allowed
          gate: true
          with:
            allowed_bots: "my-renovate-user"
    ```
  </Tab>
</Tabs>