Snyk PR Checks in your Pull Request/Merge Request

Before diving into how the Pull Request Checks (PR Checks) feature works, let’s first see how and where the PR Checks feature is best used as part of a workflow. In some systems, Pull Requests (PRs) are also known as Merge Requests (MRs), but the functionality is similar. This lesson will use the PR Check terminology.

• In this example, Snyk PR Checks show failed source code vulnerability findings and passed open source & license vulnerability checks.

PR checks allow code to be tested and potentially blocked at the PR stage, and thus preventing it from being merged if security or license violations are detected. It acts as a security gate, and comes, often hours or days, after work has started. What this feature does is provide the status, while the relevant code management system is the one that decides what to do with that information, for example when protected branches would prevent merging.

Via another feature - Inline Comments, Snyk can also show additional information in the PR, in order to help users understand the vulnerability and code issues while they review the PR check.

While this security gate helps the business ensure vulnerabilities aren't added to the code base, it is reactive and is found after the developer considers the code to be complete. We will discuss this further in the section titled "Using the IDE in addition to PR Checks".

Summary of PR Check Types

• security/snyk – Open Source vulnerabilities
• license/snyk – License compliance issues
• code/snyk – Code vulnerabilities

Early Access Features

New capabilities that summarizes and provide details on the issues to the developers directly from within the SCM:

• PR Issue Summary Comment provides developers using Snyk PR Checks with a summary count of security, license, and code checks directly within their pull requests, categorized by severity (Critical, High, Medium, Low). This empowers developers to identify and address issues early, with detailed links provided for deeper investigation.
• High-Context Inline Comments display each SAST security finding alongside key information such as CWE (Common Weakness Enumeration) and priority score, data flow and a Snyk Learn link for further guidance—helping developers remediate issues faster without leaving their SCM.

To ensure you meet your security goals, in addition to having fixed gates like the PR Check, Snyk recommends using the IDE plugin extension in addition to the PR. This not only improves the coding experience, but it enables you to find issues earlier and fix the issues faster. Though you can use the PR Check as a standalone, primary testing capability, in order to help an organization be more secure, Snyk believes in treating application security as a workflow with purpose-built capabilities, where different stakeholders have different needs at various stages.

PR checks often represent a compliance check, but in order to build better software, to improve the experience, and help developers find issues as they are writing, the Snyk IDE plugins/extensions are recommended to assist the developer to find issues and quickly resolve them while coding.

Similarly, when an issue is found in a PR, the information about the issue is provided inline in the PR. By providing the developer with the IDE and testing capabilities, it allows them to validate the code without having to resubmit the PR. In fact, the Snyk IDE plugins come with filters that you can set to match your PR check strategy in Snyk, so that only the issues that are flagged by the PR Check would be displayed.

Below are the features you can set in the IDE:

• In Settings:
  • Enable the Snyk products that you are required to check (i.e Snyk Open Source and/or Snyk Code)
  • Ensure the checkboxes corresponding to the severities are set, which are commonly High & Critical , to filter the results to what you may be responsible for or "must fix".
• Use the Net New vulnerabilites filter, by clicking the option to see "New" issues in the interface or settings. This allows the IDE to filter to only new issues you've introduced.
• Ensure the Organization that is set in the IDE Organization settings corresponds to the one the PR is being committed against in Snyk. This allows applicable ignore and policy settings to be applied.

When configuring the PR feature, an administrator can set various rules for the PR, such as:

• Only fail on new issues (default)
• For open source, if the issues are fixable, fail the check
• Only fail on critical severity (for open source) or on high severity (for issues related to open source and code)

Discuss with your administrator to find out the rules that have been set for the PR check.

In this lesson, we'll take the example of looking at someone working on a vulnerable application, Juiceshop, in their IDE. Although they could have scanned the application, they didn't, because they either did not have the IDE plugin, or was in a rush and pushed it forward. Or maybe a researcher identified an Open Source vulnerability with a package you used, between the time the developer checked and submitted the code. We will now review how the issue was introduced, the PR Check that found it, and how the issue was ultimately resolved.

Video: 4m47s

Topics covered in this video presentation:

• How the combination of PR Check and DeepCode AI in the IDE can quickly resolve an issue. To see how open-source issues can be quickly resolved, see the Issue Management section of the Snyk IDE plugins/extensions

Snyk's goal is to accelerate development and provide guardrails, where possible, as defined by the security team. Whenever introducing gates and for situations when the tooling is incorrect or the business needs require to override those controls, it’s important to have a process in place.

A Snyk administrator can review the issue and override the failed status by clicking View details and then clicking Mark as successful in SCM in the PR results. This will change the status with a note that it was overridden.

Clicking Mark as successful in SCM results in the status being overridden and information about who overrode it is presented.

Snyk recommends the development team(s) be aware an administrator can override the status, and that an exception process be in place, which includes who to contact and under which conditions this may be used.

Video: 1m14s

Topics covered in this video presentation:

• Using the Mark as successful in SCM button to override a Snyk check