Snyk SCM integration: deployment recommendations

You can integrate Snyk with your Source Control Manager (SCM) to quickly and easily gain visibility across all your projects.
The Snyk SCM integrations allow you to:
Continuously perform security scanning across all integrated repositories
Detect vulnerabilities in your open source components
Provide automated fixes.
Recommended deployment order
To ensure a smooth deployment for your team, follow the stages outlined below for each integration.
If you try to implement all the SCM integration features at the same time, you risk causing friction in your software development life cycle (SDLC), which in turn leads to a poor developer experience.
Deployment Stages
Configurations
Outcome
​
​Stage 1​
Set up your SCM integration
For more information, see the configuration documentation for each SCM integration​
A configured integration, ready to import projects
​Stage 2​
Import all of the projects from your SCM.
• Test both public and private repos
• Disable all user notifications
• Disable Snyk PR checks
• Disable Auto-fix PRs
• Disable Failing PR checks
• Disable Automatic dependency upgrades
A complete Software Bill of Materials that enables you to assess risk across your applications.
​Stage 3​
Developer and Security teams use Snyk prioritization reporting capabilities to build a fix plan.
Watch this video to learn more about Snyk prioritization reporting.
Alignment between Developers and Security on what should be fixed and when streamlines the fix process.
​Stage 4​
Alert developers to issues in real-time, and educate them on available fixes.
• Enable Snyk PR checks and fail PRs if they contain High severity issues with available fixes
• Enable Auto-fix PRs
Improve your organization’s mean-time-to-fix (MTTF).
​Stage 5​
Prevent developers from introducing any new vulnerabilities
• Enable Failing PR checks, for ANY High severity issues (fix or no fix)
‘Secure by Design’ methodology achieved.
​Stage 6​
Reduce technical security debt
• Enable Automatic dependency upgrades​
Reduce future design headaches, and hot fixes, which can be time-consuming to research & address.
Stage 1: Set up your SCM Integration
Snyk has pre-built integrations for SCMs including GitHub, GitHub Enterprise, Bitbucket Cloud and others. See GIT repository (SCM) integrations for a full list.
To check if an SCM is already configured for your Org, navigate to the Integrations tab. The relevant SCMs are labeled Configured.
If your SCM is already configured, go to the next stage.
Example: GitHub
Below is an example of how you would set up your integration for Github.com
1.In the Integrations tab, click GitHub.
2.Choose whether you'd like to give Snyk access to both public and private repositories or only to public repositories:
3.Click Authorize Snyk to provide Snyk with access to your repositories.
SCM permissions on repositories
Operations triggered using the Snyk UI (such as opening a Fix PR or retesting a project) are performed for the acting user. So to perform these operation, you must connect your own SCM user or service account. This gives Snyk the required permissions for the repositories for where you would like to perform these operations.
For example, in GitHub, the accounts connected to Snyk need the following access on the target repositories:
Action
Purpose
Required permissions on the repository
Daily / weekly tests
Used for reading manifest files in private repos
Write or higher
Snyk tests on pull requests
Used for sending pull request status checks when a new PR is created or an existing PR is updated
​
Opening fix and upgrade pull requests
Used for sending fix or upgrade PRs in the monitored repos
​
Snyk tests on pull requests - initial configuration
Used for adding Snyk webhooks to the imported repos, to notify Snyk when pull requests are created or updated and enable Snyk to trigger a scan
Admin
Change notification settings
By default, Snyk emails every Org user when a new issue or fix in a project’s dependencies is found, and provides them with a weekly update of the security status across your organization. If you plan to import many projects to an Org, to avoid sending multiple email notifications sent to users, consider disabling all the notifications for that Org.
To customize the emails your Org users receive, navigate to the Organization Settings 
 > Notifications. The changes you make here will affect all of your organization’s members, although Org users can override these default settings in their user-level account settings.
To disable notifications for all the users in an Org ahead of your import, deselect the appropriate notification boxes.
See Notification management for more information.
Stage 2: Import Projects
1.Navigate to the Projects page in the Snyk UI, select Add projects, select the repos to import to Snyk, and click Add selected repositories. 
Snyk starts scanning the selected repos for dependency files (for example, package.json) in the entire directory tree and imports these files as projects.
Snyk evaluates root folders and any custom file locations defined. If no manifest or configuration files are found, Snyk alerts you that no files can be imported.
Snyk detects the manifest files (projects), tests them, then displays the results. 
Imported projects appear underneath the repository name. 
After a project is imported, it is  continuously checked for vulnerabilities.
2.To confirm that a project was imported, navigate to the Add project import page for the integration. 
Imported projects are indicated by a ✔ next to the repo name: 
​
Stage 3: Enable Snyk test on PRs
PR Test Settings & Workflows
By default, Snyk scans every pull request submitted on your monitored repositories and displays the results and recommendations grouped together in a single security check and a single license check.
Status details
Click the Details link to display the status of the Snyk check. The status options are: 
Success: no issues were identified and all checks passed
Processing: this status is displayed until the Snyk test is completed
Failure: identified issues that must be fixed for the check to pass 
Error: indicates that one of the following issues may have occurred:
Your manifest file may be out of sync
Snyk couldn't read the manifest file
Snyk couldn't find the manifest file
Manage PR test settings
An administrator can manage settings for Snyk PR tests for each SCM integration at the organization level and apply them to all the projects for that integration, or select specific projects to apply the PR tests. You can configure whether this feature is on (enabled by default) and set fail conditions to define when Snyk should fail your PR checks.
Manage the default PR test settings per organization
To configure the PR test settings for your organization:
1.For the relevant organization, navigate to 
 (Organization Settings) > Integrations, select the relevant integration, and click Edit Settings.
2.Set the the toggle to Enabled and set the Fail conditions as needed:
3.Click Update settings.
Manage the PR test settings per project
1.To configure the pull request test settings for a specific project, navigate to Projects > Projects Settings > Edit Settings.
The project page opens.
2.In the project page, select the Settings tab in the upper right, and the SCM integration option in the left sidebar. 
3.Select and confirm the relevant options in each of the sections. 
Use Snyk License policies to ensure that your Snyk PRs are free of licensing issues. 
See Licenses for more information. 
Initial step: get visibility and set fail conditions
When you first roll out your SCM integration, we recommend that you start with Snyk set up to test your PRs without failing them, so that your developers can get used to seeing the Snyk commit check.
1.Decide to apply PR testing for your integrations at the organization level, or for specific projects.
2.Set the conditions (as described above):
Fail only for Only fail when the PR is adding a dependency with issues.
Check both Only Fail for high severity issues and Only fail when the issues found have a fix available
Stage 4: Enable Blocking PRs
After you’ve embedded Snyk into your software development life cycle (SDLC), and have built good developer awareness, you can start to apply stricter policies to improve your overall security posture. For example:
Low priority projects: you can fail the PR only for new high severity that are fixable.
Medium priority projects: fail the PR only for high severity issues.
High priority projects (PCI/GDPR compliance): fail the PR for any issue.
To align vulnerability severity with your internal policy, use security policies to change the severity of issues and attach them to relevant projects attributes. See Security policies for more details.
Stage 5: Automatic Fix PRs
Snyk scans your projects on either a daily or a weekly basis. When new vulnerabilities are found, Snyk emails you and opens automated PRs with fixes for the repositories.
The example below presents a fix pull request opened by Snyk:
To configure the PR test settings for specific projects, navigate to Org > settings 
 > Integrations > Edit Settings.
We recommend that you exclude patches from the auto fix PRs, if your developers are not familiar with how to use and execute them.
You should ask your developers to consider the merge advice label that appears on the auto fix PRs:
Snyk auto fix PRs are only generated for new issues.
If your SCM is Github and you are not using Snyk Broker, then by default, Snyk rotates every Org user's credentials to open the auto fix PRs. You can change this if needed and set the user credentials to open the auto fix PRs. See Opening fix and upgrade pull requests from a fixed GitHub account for details.
Stage 6 - Dependency Upgrade PRs
When your group is ready to start tackling security technical debt, you can configure Snyk to automatically create pull requests (PRs) on your behalf to upgrade your dependencies.
How Automatic upgrade PRs work
1.Integration is configured and users enable automatic upgrade PRs.
2.Snyk scans your projects as you import them and continues to monitor your projects, scanning on a regular basis.
3.For each scan, when Snyk identifies new versions for your dependencies:
Snyk creates automatic upgrade PRs (frequency based on Snyk project settings)
Snyk does not open a new upgrade PR for a dependency that is already changed (upgraded or patched) in another open Snyk PR.
Snyk opens separate PRs for each dependency.
Snyk does not create upgrade PRs for a repo that has 5 or more Snyk PRs open - if the limit of open PRs is reached, no new ones are created. This number can set to between 1-10 from the Settings. This limit only applies when creating upgrade PRs, but does count fix PRs. Fix PRs are not limited in this way.
By default, Snyk recommends only patch and minor upgrades, but major version upgrade can be enabled in the settings where the feature is enabled.
If the latest eligible version contains vulnerabilities not already found in your project, Snyk does not recommend an upgrade.
Snyk does not recommend upgrades to versions that are less than 21 days old. This is to avoid versions that introduce functional bugs and subsequently get unpublished, or versions that are released from a compromised account (where the account owner has lost control to someone with malicious intent).
Supported languages and repos
Snyk currently supports this feature for npm, Yarn, and Maven-Central projects through GitHub, GitHub Enterprise Server, and BitBucket Cloud, including use of the Snyk Broker. For use with the Broker, your admin should first upgrade to v4.55.0 or later.
Enable automatic dependency upgrade PRs for a specific project
To set PR Settings on the project level and override the PR settings configured at organization level:
1.Open the organization for which you would like to enable automatic upgrade PRs and navigate to the Projects tab.
2.Select and expand the relevant project, select the relevant target, and click the Settings cog:
​
​
3.In the Settings area, in the left panel menu, click the Integration settings to apply unique settings for that specific project.
4.In settings that load, scroll to the Automatic dependency upgrade pull requests and click Disabled.
5.In the options that appear:
1.Snyk creates PRs up to a maximum of 10 open simultaneously - per repo. 
To limit this number further, select the maximum number of PRs from the dropdown list. 
For more information, see Upgrading dependencies with automatic PRs.
2.In the Dependencies to ignore field, enter the exact name of any dependencies that should not be handled as part of the automatic functionality. 
This field accepts only lower case letters.
3.After you click Upgrade dependency settings, each time Snyk scans this project, it will automatically submit upgrade PRs based on the scan results. 
If a newer version is released for an existing Snyk upgrade PR or for an existing fix PR, before Snyk can raise a new PR, the existing PR must be closed or merged.