> 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 ## Use PR Checks to introduce gating [Snyk Pull Request(PR)/Merge Request (MR) Checks](/scan-fix-and-prevent/prevent/pull-request-checks.md) allow you to prevent new security issues from entering your codebase, by automatically scanning code changes when you submit a pull request (PR). PR Checks are available for open-source vulnerabilities, license compliance issues, and your own code issues. If you import Projects through a source control integration, then Snyk Open Source and Snyk Code PR Checks is a good place to start introducing gating. {% hint style="info" %} Snyk recommendes announcing the changes prior to rolling out the changes. See [Announce prevention measures](/implementation-guides/enterprise-implementation-guide/automate-prevention-measures.md#announce-prevention-measures) for examples of how to message your developers. {% endhint %} ### Implementing Open Source PR Checks There are a number of different features available that can be used to help you gradually introduce the feature to avoid friction with your development teams: * Fail conditions: You can control whether the test will "fail" if the PR itself is adding a dependency with issues (most common) or if the repository as a whole has any issues. The criteria of what constitutes a "failed test" can also be customized. By default, the test does not filter based on severity or fixability, which can mean that PR tests will regularly fail. For Snyk Open Source you can customize what the criteria are 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 suggests ticking both of these boxes so that a test would fail if a **High or Critical** and **fixable** issue is found. In this case, you would want to encourage to developer to fix the issue before proceeding. These PR tests are optional by default, meaning that even if the test fails, the developer may be able to continue and merge the PR. Controlling whether a PR test is optional or blocking is configured within your source control management platform, such as GitHub’s branch protection rules. ### Implementing Code PR Checks When enabling static analysis of code changes and therefore new vulnerabilities, you can select the fail criteria to be **High** (the highest severity). When you first enable this feature, Snyk suggests selecting **High** if an issue is found. In this case, you would want to encourage developers to fix the issue before proceeding. As your code base stabilizes and you have worked through the backlog, you can change the fail criteria to lower the severity (to either **Medium** or **Low)** in order to address broader issues or to match your internal policies. ### Using PR Checks for a phased rollout It is common to have a phased rollout of these features. Using PR checks as an example: * You may initially run Snyk tests and set, via your source control settings, as optional checks. 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 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 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.snyk.io/implementation-guides/team-implementation-guide/phase-5-rolling-out-the-prevention-stage/enable-and-configure-snyk-on-prs.md?ask=&goal= ``` `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.