> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/implementation-guides/team-implementation-guide/phase-5-rolling-out-the-prevention-stage/enable-and-configure-snyk-on-prs.md).

# Enable and configure Snyk on PRs

How to enable and configure Snyk PR and MR Checks to block new vulnerabilities in code changes

[Snyk PR Checks](https://docs.snyk.io/scan-fix-and-prevent/prevent/pull-request-checks) prevent new security issues from entering your codebase by automatically scanning code changes when you submit a pull request (PR) or merge request (MR). PR Checks are available for open-source vulnerabilities, license compliance issues, and vulnerabilities in your own code.

If you import Projects through a source control integration, Snyk Open Source and Snyk Code PR Checks are a good place to start introducing gating.

{% hint style="info" %}
Snyk recommends announcing changes before you roll them out. For examples of how to message your developers, visit [Announce prevention measures](/implementation-guides/enterprise-implementation-guide/automate-prevention-measures.md#announce-prevention-measures).
{% endhint %}

## Implement Snyk Open Source PR Checks

Several features help you introduce PR Checks gradually to avoid friction with your development teams:

* Fail conditions: You can control whether the test fails if the PR itself is adding a dependency with issues (most common) or if the repository as a whole has any issues.

You can also customize what constitutes a "failed test." By default, the test does not filter based on severity or fixability, so PR tests can fail regularly. For Snyk Open Source, you can customize the criteria to fail the test:

* **Only fail for high or critical severity issues**
* **Only fail when the issues found have a fix available**

When you first enable this feature, Snyk recommends selecting both check boxes so that a test fails if Snyk finds an issue that is High or Critical severity and fixable. In this case, encourage the developer to fix the issue before proceeding.

PR tests are optional by default, so even if the test fails, the developer can continue and merge the PR. You configure whether a PR test is optional or blocking in your source control management platform, for example, with branch protection rules in GitHub.

## Implement Snyk Code PR Checks

When you enable static analysis of code changes, you can set the fail criteria to **High** (the highest severity).

When you first enable this feature, Snyk recommends selecting **High**. In this case, encourage developers to fix the issue before proceeding. As your codebase stabilizes and you work through the backlog, you can change the fail criteria to a lower severity (**Medium** or **Low**) to address broader issues or to match your internal policies.

## Use PR Checks for a phased rollout

It is common to have a phased rollout of these features. Using PR Checks as an example:

* Initially, run Snyk tests as optional checks, which you set in your source control settings. The results are displayed, but the developer is not blocked from merging the PR.
* Over time, as developers adapt to seeing these results and begin addressing the high-severity issues proactively, you can choose to start blocking PRs from being merged if there are any new highest severity issues or, in the case of Snyk Open Source, if a fix is available.

This phased rollout helps to decrease friction between your security and development teams.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.snyk.io/implementation-guides/team-implementation-guide/phase-5-rolling-out-the-prevention-stage/enable-and-configure-snyk-on-prs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.