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 Snyk Agent Fix 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

In the previous section, you learned that the IDE and PR check workflow are essential tools for developers to detect and remediate issues proactively or reactively., Snyk Agent Fix can be enabled on your pull requests, as part of Early Access program allowing for AI-generated fix suggestions to be added to the pull request for issues that were detected by Snyk Code (SAST). The AI-generated fix will be:

• Directly generated from the pull request.
• Available for the developer to apply it and generate a commit directly from the pull request, or alternatively pull the suggestions down to the IDE, perform the necessary functional unit tests, and modify code-like variables to meet naming conventions. You can also use the suggestion to write your own fixes and send the code through the pipeline again.
• Snyk Agent Fix will only suggest fixes that have been validated for security issues, however it's strongly recommended to perform functional testing to ensure no breakage occurs.

An administrator must enable the Early Access feature. This setting is found in the git integration settings' Pull request experience in the inline comments section, and select to enable the Enable Snyk Agent Fix (Early Access).

Usage

• The @snyk /fix command can be used only for automatically fixable vulnerabilities, identified in the inline comments with a zap icon and command description. See for supported languages and limitations.
• Fixes expire after the time displayed in each suggestion, in accordance with the . After expiration, a new fix can be requested by using the @snyk /fix command.
• Snyk Agent Fix in the PR is not supported for Snyk Code Local Engine. The @snyk /fix and @snyk /apply # commands can be used only as replies to the Inline Comments created by Snyk, commands created on other comment threads will not be processed.
• For best results, Snyk recommends generating and applying fixes for a single inline comment at a time, to avoid situations where applying a fix causes conflicts with another previously generate fix.

Requirements:

• Github integration
• A git repository added to Snyk with PR checks enabled
• Inline comments must be enabled
  • Snyk Agent Fix enabled on "Pull request experience"
• A suggestion is created using a background process and can take a few minutes (about 10 minutes) to be available.

In the following video, you will learn:

• How the setting is enabled
• How Snyk Agent fix AI fix suggestions are generated
• How to review Snyk Agent fix AI fix suggestions
  • How to apply those suggestions
  • How, optionally, the IDE workflow may also be used

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