Snyk FAQs

The user generates a unique Azure DevOps personal access token generated for Snyk specifically. Together the username and password constitute a token that Snyk uses. The token authorizes Snyk to access the users repos for only the specific permissions that the user indicates to Azure Repos when generating it.

The user selects projects and repositories for import to Snyk (for testing and monitoring). The user can also enter custom file locations for any manifest files that are not located in the root folders of their repositories.

Snyk evaluates the items that the user selected and imports any that have relevant manifest files in their root folder. Snyk also imports files for which the user entered custom file locations (for any manifest files not located in root folders).

Snyk communicates directly with Azure Repos for each test it runs to determine exactly what code is currently pushed and what dependencies are being used. Each dependency is tested against Snyks vulnerability database to see if it contains any known vulnerabilities.

Based on your configurations, if vulnerabilities are found, Snyk notifies you via email or Slack so that you can take immediate remediation action.

Add projects to Snyk for Azure Repos

Snyk tests and monitors Azure Repos that are in any of our supported languages by evaluating root folders and custom file locations.

Adding projects to Snyk

Go to Projects and click Add projects. Choose the tool from which to import your projects:

Log in

A popup screen opens with all the available repositories under the selected integration:

Select the repos that you would like to import to Snyk to monitor them for security/license issues. To import all repos for a specific organization, checkmark the organization.

Click Add selected repositories. Snyk evaluates root folders and custom file locations. If no manifest files are found on the root level or in the paths you configure, Snyk notifies you that no files can be imported.

Adding custom file location

From the Add custom file location dropdown list, select the relevant repo for which you would like to configure a custom path. The repo must first be selected from the Add Projects view, as described in the previous step.

In the text field, enter the relative path in which the manifest file is located, as demonstrated in the image above.

Note

This field is case sensitive.

Excluding folders from import

To exclude specific folders from being imported, specify the names of the folders that you want to exclude from the search (maximum 9 folders). Separate names with commas.

Note

This field is case sensitive and the pattern applies for all repos.

Next steps

Once repositories are imported, a confirmation appears in green at the top of the screen. The selected files are indicated with a unique icon, they are named by organization/repo, and you can now also filter to view only those projects, as seen in the example below:

This integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages in our Docs.

Configure your integration for Azure Repos

Integration with Azure Repos is available for all of our pricing plans.

Snyk integrates with Microsoft Azure Repos to enable you to import your projects and monitor the source code for your repositories. Snyk tests the projectsyou'veimported for any known security vulnerabilities found in the applications dependencies, testing at a frequency you control.

How to configure your integration

Enable integration between Azure Repos and Snyk, and start managing your vulnerabilities.

Prerequisites

Ensure you have set up your Azure Repos account and your Snyk account.

Steps

Access your Azure Repos account and retrieve a unique personal access token for use by Snyk. For help doing this, see the Azure DevOps documentation.

When prompted in Azure, enable the following permissions for Snyk access as follows:

ExpiryWe recommend choosing an expiration date for this token that is far in the future to avoid breaking integration.

ScopesCustom defined

CodeRead and write

to your Snyk account.

Navigate to Integrations from the menu bar at the top.

From the Integrations page under the Azure Repos logo, click the Connect to Azure Repos button:

From the Settings page in the Integrations area, enter the Azure DevOps URL for the organization that you want to integrate with (https://dev.azure.com/YourDevOpsOrganizationName) and the personal access token that you just generated.

Click Save.

Snyk tests the connection values and the page reloads, now displaying Azure Repos integration information. A confirmation message that the details were saved also appears in green at the top of the screen. In addition, if the connection to Azure failed, a notification appears under the Connected to Azure Repos section.

The user generates a unique Bitbucket app password that they generate for Snyk specifically. Together the users username and password constitute a token that Snyk uses. The token authorizes Snyk to access the users repos for only the specific permissions that the user indicates to Bitbucket Cloud when generating it.

The user selects projects and repositories for import to Snyk (for testing and monitoring). The user can also enter custom file locations for any manifest files that are not located in the root folders of their repositories.

Snyk evaluates the items that the user selected and imports any that have relevant manifest files in their root folder. Snyk also imports files for which the user entered custom file locations (for any manifest files not located in root folders).

Snyk communicates directly with Azure Repos for each test it runs to determine exactly what code is currently pushed and what dependencies are being used. Each dependency is tested against Snyks vulnerability database to see if it contains any known vulnerabilities.

Based on your configurations, if vulnerabilities are found, Snyk notifies you via email or Slack so that you can take immediate remediation action.

Configure your integration for Bitbucket Cloud

Snyk integrates with Bitbucket Cloud to enable you to import your projects and monitors the source code for your repositories. Snyk tests the projectsyou'veimported for any known security vulnerabilities found in the applications dependencies, testing at a frequency you control.

Integration with Bitbucket Cloud is available for all of our pricing plans.

How to configure your BitBucket integration

Enable integration between Bitbucket and Snyk, and start managing your vulnerabilities.

Prerequisites

Ensure you have set up your Bitbucket Cloud account and your Snyk account.

Steps

Access your Bitbucket Cloud account and retrieve a unique app password for Snyk. For help doing this, see the Bitbucket documentation.

When prompted, enable the following permissions for Snyk access as follows:

Accountread and write

Team membershipread

Projectsread

Repositoriesread

Pull requestsread and write

Webhooksread and write

Log in to your Snyk account.

Navigate to Integrations from the menu bar at the top.

From the Integrations page under the Bitbucket Cloud logo, click the Connect to Bitbucket Cloud button:

From the Settings page, enter your Bitbucket Cloud username and the app password that you just generated.

Click Save.

Snyk tests the connection values and the page reloads, now displaying Bitbucket Cloud integration information. A confirmation message that the details were saved also appears in green at the top of the screen. In addition, if the connection to Bitbucket failed, a notification appears under the Connected to Bitbucket Cloud section.

Add Bitbucket Cloud projects to Snyk

Snyk tests and monitors Bitbucket repositories that are in any of our supported languages by evaluating root folders and custom file locations.

Adding projects to Snyk

Go to Projects and click Add projects. Choose the tool from which to import your projects:

A popup screen opens with all the available repositories under the selected integration:

Select the repos that you would like to import to Snyk to monitor them for security/license issues. To import all repos for a specific organization, checkmark the organization.

Click Add selected repositories. Snyk evaluates root folders and custom file locations. If no manifest files are found on the root level or in the paths you configure, Snyk notifies you that no files can be imported.

Adding custom file location

From the Add custom file location dropdown list, select the relevant repo for which you would like to configure a custom path. The repo must first be selected from the Add Projects view, as described in the previous step.

In the text field, enter the relative path in which the manifest file is located, as demonstrated in the image above.

Note

This field is case sensitive.

Excluding folders from import

To exclude specific folders from being imported, specify the names of the folders that you want to exclude from the search (maximum 9 folders). Separate names with commas.

Note

This field is case sensitive and the pattern applies for all repos.

Next steps

Once repositories are imported, a confirmation appears in green at the top of the screen. The selected files are indicated with a unique icon, they are named by organization/repo, and you can now also filter to view only those projects, as seen in the example below:

This integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages in our Docs.

Snyks Bitbucket Server integration lets you monitor the source code of your repos for any known vulnerabilities found in the applications dependencies, testing at a frequency you control.

Caution

This integration only works with Bitbucket Server instances that are publicly reachable (not on a private network) and not for bitbucket.org. For private instances, you will need to set up via Snyks Broker

For each test, Snyk will communicate directly with Bitbucket Server to determine exactly what code is currently pushed and what dependencies are being used. Each dependency will, in turn, be tested against Snyks vulnerability database to see if it contains any known vulnerabilities.

If vulnerabilities are found, you will be alerted (via email or Slack) so that you can take immediate action.

In order to turn on the Bitbucket Server integration youll need to:

Contact [email protected] and ask us to enable Bitbucket Server support

Connect to Bitbucket Server from the Integrations page

Add your Bitbucket Server account credentials to Snyk

Select the projects you want to monitor and click Add to Snyk

Connect Snyk to Bitbucket Server

In order for Snyk to be able to monitor your Bitbucket Server repos, youll first need to contact [email protected] and ask us to enable support on your account.

Then, youll be able to connect Snyk to your Bitbucket Server account. You can do this by navigating to the Integrations page and clicking on Connect to Bitbucket Server.

This will take you to a page where youll be prompted to enter your Bitbucket Server URL, username and password.

Generate your Bitbucket Server credentials

To give Snyk access to your Bitbucket Server account, we recommend setting up a dedicated user with read-only permissions.

You can create a user from the admin panel on your Bitbucket Server.

You can learn more about creating users on the Bitbucket Server documentation.

Bitbucket Server: check your connection status

At any time afteryou'veentered your Bitbucket Server credentials, you can check on the connection status in one of two places.

The first is on your Integration settings page, where youll see your current integrations listed as well as their connection status.

You can also check the status directly on the Bitbucket Server Integration settings page (found by clicking Edit settings on the integration settings page shown above). Ifyou'veentered credentials, youll see a box indicating whether or not Snyk is able to correctly connect to Bitbucket Server.

If you are unable to connect, please re-enter your account credentials to verify that they are correct.

Add Bitbucket Server repositories to Snyk

Onceyou'vesuccessfully connected Snyk to your Bitbucket Server account, you are able to select the repositories that you would like Snyk to monitor. You can do this either using the Add projects button on the integrations page, or directly from the Bitbucket Server integration settings page.

In either case, youll see a list of any available projects on the Bitbucket Server account you connected. Select the ones you want to monitor and click the Add selected repositories to Snyk button.

As soon asyou'veadded the projects to Snyk, Snyk will test them and begin to display a list of all monitored Bitbucket Server repositories in your project dashboard. Youll also see a snapshot of any current vulnerabilities and be able to click through for a more detailed report including any steps to remediate.

Snyk will now continuously monitor each of those repositories for known vulnerabilities. You can add more repositories at any time.

Disabling the Bitbucket Server integration

If you decide to disable this integration for any reason, you can accomplish this from the Integrations page in your Settings.

You need to find the specific integration you wish to deactivate in your list of integrations and click Edit settings. You are taken to a page that shows the current status of your integration, a place to update your credentials, specific to each integration (credentials, API key, Service Principal, or connection details), and a red box at the bottom to disconnect this integration, like in the example seen below:

If you choose to disconnect, your credentials will be removed from Snyk and any integration-specific projects we had been monitoring will be deactivated on Snyk.

If you choose to re-enable this integration at any time, you need to re-enter your credentials and activate your projects.

In this article, find all the information on Snyk tests and automated pull requests.

Snyk test on your pull requests

Snyk tests are visible in pull requests on repos that youre watching with Snyk.

valid manifest file

You can review and adjust the settings for this by going to the Settings for the watched project.

By default, Snyk runs a test when the dependencies in the package.json, requirements.txt, or Gemfile.lock / Gemfile change, and fails the test if the new dependencies have vulnerabilities.

You can change this to fail if the repository has any existing vulnerabilities (so tests will fail even if the current PR is not adding new vulnerable dependencies).

You can choose to fail tests only for high severity vulnerabilities.

You can disable Snyk tests in pull requests.

Fix vulnerabilities with Snyk pull requests

Note

Note: Currently for Node.js and Ruby only

When viewing a Snyk test report for a repo that you own, or when looking at a project that you watch with Snyk, you see two options for fixing a vulnerability:

Open a fix PR link: generate a Snyk pull request with the minimal changes needed to fix the vulnerabilities affecting the repo.

Fix this vulnerability link: generate a Snyk pull request that fixes this specific vulnerability only.

Before opening the pull request on the Open a fix PR page, review the vulnerabilities you want to fix, change your selection, or choose to ignore any vulnerabilities thatdon'thave a fix at this moment.

Note

Patching is only supported for Node.js repos; Ruby vulnerabilities can be fixed with upgrades only.

Snyk fixes your Ruby projects by updating vulnerable dependencies in your Gemfile.lock file. When a fix requires a change to your Gemfile, our fix pull requests propose these changes.

When you open a PR via snyk.io, we give you a heads-up when this is the case:

Heres an example for the pull request:

Get a Snyk pull request for newly disclosed vulnerabilities that affect you

Whenever a vulnerability is disclosed that affects a repo youre watching, Snyk not only sends you an email about it but also generates a Snyk pull request that addresses the vulnerabilities. Youll receive a pull request similar to the example above.

Get a Snyk pull request when new upgrades or patches are available

When no upgrade is available, you can ignore or patch the vulnerability (patching is only available for Node.js projects). When a better remediation option has become available, for example, an upgrade for a vulnerability you previously ignored, Snyk notifies you about this via email, and also generates a pull request with the new fix.

Disable automatic pull requests

You can disable Snyk auto-generated pull requests with fixes in your organization settings, like in the image below:

This will affect all projects in the organization.

Configure your GitHub integration

Here you can find all the information you need on how to get started with your GitHub integration and all the necessary permissions.

How to integrate with GitHub

You can add your Node.js, Ruby, Python, Scala, and Java GitHub repos and quickly test them, or decide which ones youd like to continuously watch with Snyk.

Caution

This integration only works with GitHub and GitHub Enterprise instances that are publicly reachable (not on a private network). For private instances, you might need to set up via Snyks Broker first.

Steps:

Go to the Integrations page and click on GitHub.

You need to grant Snyk additional GitHub permissions. Choose to give access to public and private repositories, grant access to public repositories only, or monitor public repositories only (with limited functionality).

You need to grant Snyk additional GitHub permissions. Choose to give access to public and private repositories, grant access to public repositories only or monitor public repositories only (with limited functionality).

Click on the button at the bottom of the page Add selected repositories to Snyk. The selected repos appear in your projects and are continuously checked for vulnerabilities.

Clicking View report on any project lets you view and fix vulnerabilities right away. You have the ability to review the suggested remediations and create a PR with the required upgrades or patches.

To view your organizations projects in Snyk, you need to have sufficient access to your organizations repositories on GitHub.

Why are write permissions required for GitHub integrations?

Due to the level of granularity offered by GitHub's permissions model, Snyk requires write permissions to provide several key features.

Test new pull requests for new vulnerabilities.

Using GitHub's webhooks to monitor the latest version of the project.

And, last butnotleast... raising pull requests to remediate your vulnerabilities!

Summary of permissions needed for integration with GitHub (when Broker is not implemented)

Action

Minimum permissions required in GitHub per repo

Minimum Snyk role

Initial configuration for integration with the Snyk organization and authentication

Read

Admin

Daily / weekly test - monitoring configuration

Read

Admin

Prevent: Snyk test on pull requests - configuration

Admin in order to add the webhook

Admin

Automatic fix and automatic upgrade pull requests - configuration

Write

Admin

Authentication and integration for any regular user in the Snyk organization

Read

Any member of the organization

Manually trigger Snyk to create a fix pull request

Write

Any

Daily / weekly test - monitoring; Snyk test on pull requests

Read

Any - works automatically in the background once configured by the admin

Re-test - manually triggered

Read

Any

Permissions for configuring a GitHub integration (when Broker is not implemented)

The first user in a Snyk organization (a Snyk admin account user) is asked to authenticate with GitHub and to authorize Snyk as an Authorized OAuth App before they and the other users in their organization add any projects to Snyk. Once the initial admin user authenticates, the Github integration is configured automatically.

Permission for authenticating users when they join the Snyk organization (when Broker is not implemented)

When a second user logs into the same organization in Snyk, they can see the projects that were added by the first user (monitoring).They can also trigger a retest to view the most up-to-date results and to enable monitoring from that new users account, as this uses the credentials of any user that is related to the project that has the correct permissions.

Permissions for ongoing use of Snyk with GitHub (when Broker is not implemented)

In addition to monitoring, all users can also open fix pull requests with the Snyk automated features. To enable this, they should authenticate their integration with Snyk when prompted and they should have write permissions on the repository with which they are working.

GitHub integration management

Here you can find all the information you need to manage your GitHub integration.

Integration features

Watch a Node.js, Ruby, Python, Scala or Java repo to add it as a project to Snyk. This allows you to:

see Snyk tests in your pull requests that check for vulnerabilities.

get email alerts and a Snyk pull request with fixes when new vulnerabilities that affect your repo are disclosed.

get email alerts and a Snyk pull request if a new upgrade or patch is available for a vulnerability that affects you.

trigger a Snyk pull request with fixes yourself from the test report page or the project page for your repo on snyk.io.

Organizations

To test your GitHub organizations repositories with Snyk, you need to have sufficient user permissions. When you authenticate Snyk, GitHub will show you which organizations you can integrate.

If you do not have the correct permissions, you see Access request pending next to the organization name, and you are unable to see this organizations projects in Snyk.

If youd like to integrate this organization, you need to request organizational approval in GitHub.

Disabling the GitHub integration

If youdon'twant to watch a specific repo anymore, you can stop watching this project via the project settings. The project will be set to inactive, and youll no longer get alerts, pull requests, o Snyk test on your pull requests. The webhook that enables the integration for this repo will be removed.

You can restart watching at any time.

GitHub badges

Once youre vulnerability free, you can put a badge on your README showing your package has no known security holes. This will show your users you care about security, and tell them that they should care too.

If there are no vulnerabilities, this is indicated by a green badge.

If vulnerabilities have been found, the red badge will show the number of vulnerabilities.

To show a badge for a given Node.js, Ruby or Java GitHub repository, copy the relevant snippet below and replace {username}/{repo} with the GitHub username and repo you want to test.

HTML:

<*a href="https://snyk.io/test/github/{username}/{repo}">

Markdown:

[](https://snyk.io/test/github/{username}/{repo})

The badge will reflect the vulnerability state of the latest commit on the master branch. To show the vulnerability state of a specific branch, release or tag, simply add its name after the repo name in the URL.

For example, to show a badge for the 4.x branch of the express repo, use the URL https://snyk.io/test/github/expressjs/express/4.x/badge.svg.

Styles

To change the style of the badge, you can add the following query parameters after badge.svg:

?style=flat-square

style=plastic

nmp badges

To show a badge for a given npm package, copy the relevant snippet below and replace {name} with the name of your package.

HTML

<*img src="https://snyk.io/test/npm/{name}/badge.svg" alt="Known Vulnerabilities" data-canonical-src="https://snyk.io/test/npm/{name}" style="max-width:100%;"/>

Markdown

[](https://snyk.io/test/npm/{name})

The badge will reflect the vulnerability state of the latest version of this package. To show the vulnerability state of a specific package, you can specify the specific version in the URL.

For example, to test version 1.2.3 of package name, use the URL https://snyk.io/test/npm/name/1.2.3/badge.svg.

Private packages and repos

Badges currently only work for public npm packages and GitHub repositories, and will fail if pointed at a private repository.To continuously watch for vulnerabilities in your GitHub repositories, both public and private, consider integrating them with Snyk.

Custom manifest file locations

By default, the badge will test against the first it detects in the root of your project.

If your manifest file is in another location other than the root of the repository, or if you have multiple manifest files that you would like to show a badge for, you can pass a targetFile query string parameter to direct the badge to test against another supported manifest file.

HTML:

<*a href="https://snyk.io/test/github/{username}/{repo}">

Markdown:

[](https://snyk.io/test/github/{username}/{repo})

Watch a Node.js, Ruby, Python, Scala or Java GitLab project to add it as a project to Snyk.

Integration features

Watch a Node.js, Ruby, Python, Scala or Java repo to add it as a project to Snyk. This allows you to:

see Snyk tests in your pull requests that check for vulnerabilities.

get email alerts and a Snyk pull request with fixes when new vulnerabilities that affect your repo are disclosed.

get email alerts and a Snyk pull request if a new upgrade or patch is available for a vulnerability that affects you.

trigger a Snyk pull request with fixes yourself from the test report page or the project page for your repo on snyk.io.

Disable the GitLab integration

If youdon'twant to watch a specific repo anymore, you can stop watching this project via the project settings. The project will be set to inactive, and youll no longer get alerts, pull requests, o Snyk test on your pull requests. The webhook that enables the integration for this repo will be removed.

You can restart watching at any time.

Configure your GitLab integration

Here's what you need to know to get started with your GitLab integration.

How to integrate with GitLab

You can add your Node.js, Ruby, Python, Scala and Java GitLab projects and quickly test them, or decide which ones youd like to continuously watch with Snyk.

This integration only works with GitLab instances that are publicly reachable (not on a private network). For private instances, you will need to set up via Snyks Broker first.

Steps:

Generate a Personal Access Token in your GitLab. Youll find this option in your user account settings area, in the Access Tokens section.

Go to Snyks integrations page and click Connect to GitLab.

Add your account credentials and the token you just generated to the GitLab integration settings area in Snyk.

Required permissions and roles

There are two ways to integrate Snyk with GitLab, either via our Broker or directly. Our Broker enables organizations to integrate from within their private network. This article describes the permissions needed for direct integration (when Broker is not implemented).

To integrate with GitLab, as a Snyk admin user or as a member of the organization, generate a personal access token enabling the API scope for access.

This scope enables:

Snyk to authenticate user accounts and to create webhooks, which are necessary for automating fix pull requests and Snyk test on your pull requests

Continuous write access to enable the Snyk organization users to manually trigger the creation of fix pull requests

Continuous read access enabling Snyk to monitor your projects and enabling you and the organizations other members to manually re-trigger tests.

When the first user in a Snyk organization (a Snyk admin account user) sets up an integration with a GitLab personal token, the token is authenticated with GitLab, enabling Snyk access to the repositories in that account. Thereafter, all users in that Snyk organization can add and work with any related projects, while the merge requests themselves will appear in GitLab as having been opened by the original GitLab user (the Snyk admin who set up the configuration)

Fix vulnerabilities with Snyk merge requests in GitLab

Caution

Currently for Node.js and Ruby only.

When viewing a Snyk test report for a project that you own, or when looking at a project that you are watching with Snyk, youll see two options for fixing a vulnerability:

Open a fix Merge Request link: generate a Snyk merge request with the minimal changes needed to fix the vulnerabilities affecting the project.

Fix this vulnerability link: generate a Snyk merge request that fixes only this vulnerability.

You can review the vulnerabilities that will be fixed, change your selection, and choose to ignore any vulnerabilities thatcan'tbe fixed right now before opening the merge request on the Open a fix Merge Request page.

Note

Patching is only supported for Node.js projects; Ruby vulnerabilities can be fixed with upgrades only.

Snyk fixes your Ruby projects by updating vulnerable dependencies in your Gemfile.lock file. When a fix requires a change to your Gemfile, our fix merge requests will propose these changes.

When you open a merge request via snyk.io, we will give you a heads-up when this is the case.

Heres an example for the merge request:

Get a Snyk merge request for newly disclosed vulnerabilities that affect you

Whenever a vulnerability is disclosed that affects a project youre watching, Snyk will not only email you about it, but also generate a Snyk merge request that addresses the vulnerabilities. Youll receive a merge request similar to the example above.

Get a Snyk merge request when new upgrades or patches are available

When no upgrade is available, you can ignore or patch the vulnerability (patching is only available for Node.js projects). When a better remediation option has become available, for example an upgrade for a vulnerability you previously ignored, Snyk notifies you about this via email, and also generates a merge request with the new fix.

Snyk can be configured to use custom package registries under specific conditions, allowing insight into dependencies that are not hosted in canonical registries.

The custom package registry feature currently supports Artifactory with Maven and is available on the Pro and Enterprise plans. Maven analysis can be configured to mirror all requests through a custom package repository, or you can specify additional repositories to use alongside Maven Central.

Note

Custom package registries do not currently work with brokered SCM integrations. If you currently use a brokered SCM integration or need support for other package managers please email [email protected] and we will send you an announcement as soon as support is available.

Setup custom package registries

If authentication is required to access your custom registry you will need to first configure the Artifactory package repository integration.

To configure the Artifactory integration go to Integrations > Artifactory and click Connect to Artifactory and complete the fields - URL to your Artifactory, username, and password.

Once the integration is set up you can configure Maven settings by navigating to Settings > Languages > Java

You can choose whether to use Artifactory as a mirror or as an additional repository where your artifacts will reside. These settings will be very similar to what you have in ~/.m2/settings.xml.

Mirrors

Choose a value for the type, either direct or if using authentication integration. If using direct you will need to complete the URL, repository name and what it is a mirror of.

The mirror of value can either be a * to mirror everything or you can type in a value for example central

If using the integration, you will need to choose an integration type and provide the repository name and mirror of details.

Repositories

Alternatively, you can configure repositories which will be used as additional locations to check for artifacts.

Overview

Snyk enables security across the Microsoft Azure ecosystem, including for Azure Pipelines, automatically finding and fixing application and container vulnerabilities.

Ready-to-use tasks for Azure Pipelines can be quickly inserted directly from the Azure interface, enabling you to customize and automate your pipelines with no extra coding. Amongst the tasks included is the Snyk task.

You can include the Snyk task in your pipeline to test for security vulnerabilities and licensing issues as part of your routine work; in this way, you can test and monitor your application dependencies and container images for security vulnerabilities. Once tested, you can review and work with results directly from the Azure Pipelines output, as well as from the Snyk interface.

Snyk support

Our Snyk Security Scan task is available for all languages supported by Snyk and Azure DevOps.

Azure Pipelines: how it works

Once the Snyk Security Scan task has been added to a pipeline, each time the pipeline runs, the Snyk task does the following:

Scan

Scans application dependencies or container images for vulnerabilities and licensing issues and lists them.

If Snyk finds vulnerabilities, it does one of the following (based on your configuration):

Fails the pipeline

Lets the pipeline complete the build

Monitor

Optionally, if the pipeline continues (the Snyk task completes successfully) and monitorOnBuild is set to true in the task, then Snyk saves a snapshot of the project dependencies on snyk.io, where you can see the dependency tree with all of the issues and be alerted if and when new issues are found in the dependencies.

Install the Snyk extension for your Azure pipelines

To start using our task as part of your pipeline build, first install the extension on your Azure DevOps instance per organization, from the Marketplace.

Prerequisites:

Create a Snyk account.

Ensure you are an owner of or an administrator for this account.

Steps:

Access your Snyk account.

For free plans, go to your General Account Settings and find, copy and save your personal API authentication token on the side.

CLI full reference

For paid plans, navigate to the organization youd like to integrate with, and then go to Settings to create a new service account token. Copy and save it on the side.

Access your Azure DevOps account and navigate to Extensions -> Browse marketplace.

Search for the Snyk Security Scan extension, click Get it free .

Follow the on-screen instructions.

When you click OK, Snyk authenticates with Azure. When authenticated, the connection appears in your connections list, and in the Information tab you can see Connected to service using token.

Double-check installation: ensure Snyk appears in your list of extensions.

Add the Snyk Security Task to your pipelines

Prerequisites

Ensure you have a pipeline within the repository for the code youd like to test.

If you created a pipeline with the Azure Repos wizard, this file is called azure-pipelines.yml.

If this repository has multiple service connections, check with your Snyk admin which to use for your pipeline.

If you want to add your Dockerfile for additional base image data when testing your container, ensure the image has first been built.

Steps:

Add the Snyk Security Scan task when you create your pipeline or while editing an existing one. See the Azure Pipelines documentation for more information Azure Pipelines and tasks.

From Azure, access the pipeline that youd like to scan for vulnerabilities, open it for editing and ensure that a Build step is included just before the point at which youd like to insert the Snyk task.

Open the assistant, search for the Snyk Security Scan task and click it. The configuration panel opens on top of the assistant.

Complete the fields in the configuration. Find full details about the parameters in this article: Snyk Security Scan task parameters and values.

Warning

If the Fail build if Snyk finds issue option is checked, then if the build fails, the pipeline will not be pushed to Snyk even if the Run Snyk monitor after test? option is selected.

If you remove the checkmark from the Fail build if Snyk finds issue option, the Snyk task tests for vulnerabilities, but does not cause the pipeline job to fail.

Tip

When testing a container image, you can specify the path to the Dockerfile with the dockerfilePath property in order to receive additional information about issues in your base image.

To add your Dockerfile for additional base image data when testing your container, ensure the image has first been built.

Place your cursor inside the pipeline, ensuring you place it before a deployment step, such as npm publish or docker push.

Tip

You can have multiple instances of the Snyk Security Scan task within your pipeline. This might be useful, for example, if you have multiple project manifest files you want to test or if you want to test both the application and the container images.

From the configuration panel, click Add. The task is inserted to your pipeline where your cursor was placed, appearing similar to the following:

- task: SnykSecurityScan@0

inputs:

testType: 'app'

monitorOnBuild: true

failOnIssues: true

Once included in your pipeline, the task runs each time the pipeline runs, and the results appear in the Azure Pipelines output view - similar to the following:

Note

If the Snyk task fails the build, an error message appears in the results indicating that the build failed due to snyk test.

Snyk Security Scan task parameters and values

This section describes:

The Snyk task parameters for Azure Pipelines integration, their parallel configuration fields (from the configuration panel in Azure Pipelines) and their valid values

An example of the Snyk task for npm

An example of the Snyk task for a container image

Parameters and values

The Snyk task parameters, their parallel configuration fields (from the configuration panel in Azure Pipelines) and their valid values are as detailed in the following table:

Configuration field

Parameter

Description

Required

Default

Type

Notes

Snyk API token

serviceConnectionEndpoint

The Azure DevOps service connection endpoint where your Snyk API token is defined. Your admin defines this within your Azure DevOps project settings, assigning it with a unique string in order to differentiate between different connections.

The configuration panel displays all available Snyk service connections from a dropdown list like the following:

If multiple Snyk service connections are available from the dropdown list, ask your administrator which to use for the pipeline youre working with.

Yes

none

String / Azure Service Connection Endpoint of type SnykAuth / Snyk Authentication

What do you want to test?

testType

Determines which dynamic fields to display as described in the rest of this table.

Yes

"application"

string: "app" or "container"

Container Image Name

dockerImageName

The name of the container image to test.

Yes, if container image test

none

string

This dynamic field appears when What do you want to test is set to Container Imager

Path to Dockerfile

dockerfilePath

The path to the Dockerfile corresponding to the dockerImageName

Yes, if container image test

none

string

This dynamic field appears when What do you want to test is set to Container Imager

Custom path to manifest file to test

targetFile

Applicable to application type tests only. The path to the manifest file to be used by Snyk. Should only be provided if non-standard.

No

none

string

This dynamic field appears when What do you want to test is set to Application

Testing severity threshold

severityThreshold

The severity-threshold to use when testing. By default, issues of all severity types will be found.

No. If not cofigured, the default severity is set to Low.

"low"

string: "low" or "medium" or "high"

Run Snyk monitor after test?

monitorOnBuild

Whether or not to capture the dependencies of the application / container image and monitor them within Snyk.

Yes

true

boolean

Fail build if Snyk finds issues

failOnIssues

This specifies if builds should be failed or continued based on issues found by Snyk.

Yes

true

boolean

Project name in Snyk

projectName

A custom name for the Snyk project to be created on snyk.io

No

none

string

Organization name (or ID) in Snyk

organization

Name of the Snyk organisation name, under which this project should be tested and monitored

No

none

string

Test (Working) Directory

testDirectory

Alternate working directory. For example, if you want to test a manifest file in a directory other than the root of your repo, you would put in relative path to that directory.

No

none

string

Additional command-line args for Snyk CLI (advanced)

additionalArguments

Additional Snyk CLI arguments to be passed in. Refer to the Snyk CLI help page for information on additional arguments.

No

none

string

Use the Snyk CLI tool option syntax, as described in our .

Example of a Snyk task to test a node.js (npm) based application

This section displays examples of Snyk Security Scan task configurations and [parameters when testing a Node.js (npm) application.

The configuration panel appears as follows:

Click add and it is added to your pipeline as follows:

Simple Application Testing Example

- task: SnykSecurityScan@0

inputs:

serviceConnectionEndpoint: 'mySnykToken'

testType: 'app'

monitorOnBuild: true

failOnIssues: true

Example of a Snyktask for a container image pipeline

The following is an example of the Snyk Security Scan task within the script for a container image pipeline.

When populated with the most common settings, the configuration panel in Azure appears similar to the following:

Following is an example of the same configuration once you've added it to your pipeline.

Simple Container Image Testing Example

- task: SnykSecurityScan@0

inputs:

serviceConnectionEndpoint: 'mySnykAuth'

testType: 'container'

dockerImageName: 'my-container-image-name'

dockerfilePath: 'Dockerfile'

monitorOnBuild: true

failOnIssues: true

Snyk integrates with Bitbucket Pipelines using a Snyk pipe, seamlessly scanning your application dependencies and Docker images for open source security vulnerabilities as part of the continuous integration/continuous delivery (CI/CD) workflow.

Bitbucket Pipes enables users to customize and automate a Bitbucket Pipeline CI/CD workflow with a group of ready-to-use tasks that can be added inside of your pipelines by copying and pasting them from the Bitbucket interface.

With the Snyk pipe, you can quickly add Snyk scanning to your pipelines to test and monitor for vulnerabilities at different points of the CI/CD workflow, based on your configurations. Results are then displayed from the Bitbucket Pipelines output view and can also be monitored from Snyk.io.

Snyk pipe information in Bitbucket

From the build directory, Bitbucket Pipelines displays a list of available pipes customized for you directly, similar to the following image:

Snyk app

From this list, find and click Snyk to view the pipe, examples, parameters, and values:

Language support

Snyk integration with Bitbucket pipes is supported for the following languages:

JavaScript (npm)

.NET (NuGet)

PHP Composer

Ruby

Docker

Bitbucket Pipelines integration: how it works

Once the user has added the pipe to the pipeline, each time the pipeline executes (by any trigger type) the Snyk pipe does the following.

Scan

Scans app dependencies or container images for vulnerabilities or licensing issues, and lists them.

If Snyk finds vulnerabilities, it does one of the following (based on configuration):

Fails the build

Lets the build complete

Monitor

Optionally, if the build completes successfully and MONITOR is set to True in the Snyk step, then Snyk saves a snapshot of the project dependencies from the Snyk app, where you can view the dependency tree displaying all of the issues, and you can receive alerts for new issues found in the existing app version.

Protect (optional)

(For Node.js projects only) Optionally, set PROTECT to True and if a .snyk policy file exists, Snyk applies patches specified in the policy file.

Configure your BItbucket Pipelines integration

To enable Snyk to test and monitor your code as an integral part of your CI/CD workflow in Bitbucket, add the Snyk pipe into your bitbucket-pipelines.yml (YAML) file. The bitbucket-pipelines.yml file should be located in the root of your repository, and it is this file that defines all your build configurations (pipelines for your CI/CD workflow).

How to add a Snyk pipe

Add the Snyk pipe while originally creating your pipeline, or while editing an existing pipeline. See the Bitbucket documentation for more information about pipelines and pipes. When adding the Snyk pipe, follow these guidelines:

Use the Bitbucket pipeline editor to update the .yml file configuration, select the correct language and use the Bitbucket Pipes build directory when adding the Snyk pipe.

Paste the Snyk pipe into the Bitbucket editor interface, after all, build steps. Build steps are commands such as these: npm install / composer install / bundle install / dotnet restore / docker build

Ensure you paste the pipe before a deployment step, such as npm publish or docker push.

Configure the LANGUAGE, choose whether to fail the pipeline on vulnerabilities found with DONT_BREAK_BUILD (you can also use SEVERITY_THRESHOLD), and consider enabling MONITOR and PROTECT (Protect for Node.js projects only). See Snyk pipe parameters and values for more information.

Once included in your pipeline commands, Snyk looks for the manifest files in that repository (package.json, package-lock.json) and performs the scan.

Results appear in the Bitbucket Pipelines output interface, similar to the following:

Note

If the build fails, even if MONITOR is set to True, Snyk does not continue to the Monitor stage (because no projects are deployed until the build succeeds). To enable monitoring on Snyk.io of projects with vulnerabilities, set DONT_BREAK_BUILD to True. You can use SEVERITY_THRESHOLD to tell the pipe the severity threshold from which to fail the pipe at the scanning stage. See Snyk pipe parameters and values for more information.

Prerequisites

For your Bitbucket Pipelines, ensure you have build minutes in your account, which are necessary to enable ongoing CI/CD workflows.

Create a Snyk account and retrieve the Snyk API token from your #Account settings.

For npm projects, if you would like to enable automatic remediation for the CI/CD workflow as well, run the Snyk wizard first.

Bitbucket Pipelines integration:Snyk pipe parameters and values

Following is the Snyk pipe that should be configured as part of a pipeline YAML file in order to include vulnerability scanning as part of your CI/CD workflow:

- pipe: snyk/snyk-scan:0.2.0

variables:

SNYK_TOKEN: '<string>'

LANGUAGE: '<string>'

# IMAGE_NAME: '<string>' # Only required if LANGUAGE set to 'docker'

# DONT_BREAK_BUILD: '<boolean>' # Optional.

# MONITOR: '<boolean>' # Optional.

# SEVERITY_THRESHOLD: '<low|medium|high>' # Optional.

# ORGANIZATION: '<string>' # Optional.

# PROJECT_FOLDER: '<string>' # Optional.

# TARGET_FILE: '<string>' # Optional.

# EXTRA_ARGS: '<string>' # Optional.

# DEBUG: '<boolean>' # Optional.

The following table describes the Snyk pipe parameters.

Parameter

Description

SNYK_TOKEN (*)

Enter the Snyk API token, which you can retrieve from your Snyk Account settings.

To encrypt the token, you can add it as a predefined variable in a separate part of the Bitbucket pipes directory:

From the build directory, click the cog icon, name the parameter token and enter your token as the value.

Click the padlock icon next to the parameter and value and then click Add.

From the YAML file, enter $token as the value for the TOKEN parameter in the Snyk pipe.

See Bitbucket documentation for more information about predefined variables.

LANGUAGE (*)

Configure the package manager of the app (for example, npm, rubygems, composer, nuget or docker).

See Dockerhub for a full list of possible tags.

IMAGE_NAME (*)

For docker language only, configure the image name for which to perform a docker scan.

PROTECT

Supported only for JavaScript (npm) currently.

This parameter applies the patches specified in your .snyk file to the local file system when set to True.

Default: false. Automatic remediation is disabled.

In order to enable automatic remediation, first run the Snyk Wizard, which creates and adds the .snyk file to your project.

DONT_BREAK_BUILD

When set to true, continues the build even when vulnerabilities are discovered.

Default: false. The build fails.

MONITOR

Records a snapshot of the project for the Snyk UI and then continues monitoring the project after the build is run.

If the test succeeds, this records a snapshot of the apps dependencies in the and allows you to see the state of your deployed code, have it monitored and receive alerts when new vulns are found in the code.

Default: false. The project is not monitored after the initial scan.

SEVERITY_THRESHOLD

Reports issues equal to or higher than the configured level. Possible values: low, med, high

Default: low. All vulnerabilities are reported.

ORGANIZATION

Configures the organization from your Snyk account to which to associate the repository.

Default: none.

PROJECT_FOLDER

The folder in which the project resides.

Default: ..

TARGET_FILE

The package file (for example package.json); equivalent to --file= in the CLI.

For Docker enter the Dockerfile as the value.

Default: none.

EXTRA_ARGS

Extra arguments to be passed to the Snyk CLI. Use the parameters and arguments as described here.

Default: none.

DEBUG

Turn on extra debug information.

Default: false

Example of a Snyk pipe for Docker

Following is an example of the Snyk pipe set up for a Docker image:

Example of a Snyk pipe for npm

Following is an example of the Snyk pipe set up for npm:

From the Orbs registry, CircleCI displays a list of available Orbs customized for you directly, similar to the following image:

From this list, find and click the relevant #Snyk line to view the Orb's information with examples, parameters, and values:

The Snyk plugin for Jenkins is maintained and documented from within Jenkins. Regardless of the kinds of projects you mostly manage from Jenkins (freestyle or pipeline), install the Snyk security task on your Jenkins account with these steps. Once complete, the plugin is available for configuration for any of your freestyle projects and pipelines.

Note

Note: steps supported solely by Jenkins are in high-level only. See Jenkins documentation for additional assistance.

How to install the Snyk plugin

Navigate to the Manage Jenkins=>Manage Plugins area of Jenkins to install the Snyk Security plugin for Jenkins. See the Jenkins documentation for additional information.

Jenkins documentation.

Navigate to Manage Jenkins=>Global Tool Configuration and click Snyk installations ... to add a Snyk installation.

Enter a unique name.

Ensure Install automatically is selected.

This ensures your plugin automatically upgrades when there are newer versions available.

From the Install with snyk.io section enter values for these fields:

Install automaticallydefault is selected. This ensures your plugin automatically updates when available.

Versionthe plugin version you would like to install; we recommend leaving the default latest to stay up-to-date with our Snyk CLI changes.

Update policy interval (hours)this is a Jenkins parameter by which Jenkins checks the version of the installed plugin based on the value of this parameter and the frequency of your builds, updating the installation as necessary as part of the Snyk security task step if no other builds have triggered update checks already for that installation during that time interval. We recommend a policy of 24 hour intervals.

Save the changes.

From the Snyk app, retrieve your Snyk API token:

From your Snyk account, navigate to Settings=>General.

If you are a member of an organization, copy the OrganizationAPI key; if yours is a personal account, then copy the Personal access token.

For example:

Return to your Jenkins account. From the Credentials area in Jenkins, enter your Snyk API token to enable Snyk to communicate with Jenkins, accessing your project, scanning and monitoring it.

Use these values:

KindSnyk API token

ScopeGlobalTokenSnyk API token as retrieved from your Snyk account

IDEnter a name for the token

Descriptionoptional free text

For more information about global credentials, see the

For any pipeline project, you can add a Snyk step to your build at any point in your pipeline, to scan the code while you build and to fail the build for vulnerabilities, based on your configurations. Simply generate a Snyk Security task pipe and add it to your Jenkinsfile to get started.

Steps:

From within Jenkins, generate a Snyk Security pipe:

Navigate to the pipeline project you would like to test, and click Pipeline Syntax.

From the Sample Step dropdown, select snykSecurity: Invoke Snyk Security task.

Configure the security task as follows:

When Issues are found:

Fail the build, if severity at or abovefails the build when a single vulnerability of the severity level selected from the dropdown is identified in the project

Let the build continuedisplay vulnerabilities and details, but allow the build to continue

Monitor project on buildpush a snapshot of the project to the Snyk UI. Snyk then continues to monitor your project for newly disclosed vulnerabilities.

Snyk tokenselect the token that you already created from the Jenkins Credentials area.

Target fileindicate the path to the manifest file; if the file is in the root folder, leave blank.

Organizationthe Snyk organization to which this project should be associated.

Project nameenter a unique name by which to identify this project from the Snyk UI. If left blank, Snyk assigns a project name based on the manifest file data.

From the Advanced area, leave the Snyk installation default. Enter any additional valid Snyk CLI arguments and their values in the Arguments box.

Click Generate Pipeline Script. The pipe syntax is generated and displayed in the window below.

Copy the generated pipe syntax.

Navigate to the Configure area of your pipeline and go to the Pipeline part. Paste the Snyk step syntax in your pipeline as part of an existing stage or as a new separate stage.

Note

You can also choose to add the stage to your Jenkinsfile directly from the Git.

Now, every time you run your project build:

Note

If you updated the Jenkinsfile from the Git and external to Jenkins, then when Jenkins fetches that file to run the build, it receives the edited pipeline, now including the newly added Snyk step.

Snyk verifies the plugin installation (if necessary, and as based on your policy configuration).

Snyk runs the snyk test command, analyzing the manifest file of your project to find its direct and transitive dependencies and testing your pipeline against the Snyk vulnerability database for known vulnerabilities.

From the Jenkins Console Output, the test results summary is displayed, indicating the number of known issues and the number of associated dependency paths identified.

Based on the Monitor project on build configuration for this project:

If you did not choose Monitor project on build, then Snyk displays all vulnerability results and details from the Snyk Security Report area of the Build menu.

If a severity threshold was defined for a severity that is assigned to any vulnerability in your project, Jenkins breaks the build.

Otherwise, Jenkins continues to run the build to completion (success or failure) and Snyk activity ends.

If you checkmarked the Monitor project on build option, then Snyk displays all vulnerability results and details from the Snyk Security Report area of the Build menu and also pushes a snapshot for continuous monitoring to the Snyk UI.

When pushed to the Snyk UI, the project is associated with your default organization if you did not specify another org in your arguments, and the project is named according to the package used in your root manifest file.

If a severity threshold was defined for a severity that is assigned to any vulnerability in your project, Jenkins breaks the build.

Otherwise, Jenkins continues to run the build to completion (success or failure) and Snyk activity ends.

From the top of the report, right-click View on Snyk.io to view the snapshot and vulnerability information directly from our app:

For any Freestyle project, you can add Snyk to your build to scan the code while you build and to fail the build for vulnerabilities, based on your configurations.

Steps:

Navigate to any freestyle project from within Jenkins and click Configure.

From the dropdown list in the Build section, add the Invoke Snyk Security task as an additional step in your build.

Configure the security task as follows:

When issues are found:

Fail the build, if severity at or abovefails the build when a single vulnerability of the severity level selected from the dropdown is identified in the project

Let the build continuedisplay vulnerabilities and details, but allow the build to continue

Monitor project on buildpush a snapshot of the project to the Snyk UI. Snyk then continues to monitor your project for newly disclosed vulnerabilities.

Snyk tokenselect the token that you already created from the Jenkins Credentials area.

Target fileindicate the path to the manifest file; if the file is in the root folder, leave blank.

Organizationthe Snyk organization to which this project should be associated.

Project nameenter a unique name by which to identify this project from the Snyk UI. If left blank, Snyk assigns a project name based on the manifest file data.

From the Advanced area: leave the Snyk installation default and enter any additional valid Snyk CLI arguments and their values in the Arguments box.

Snyk checks the CLI version that is installed and automatically installs/upgrades it in the background (if necessary, and as based on your policy configuration).

Save the build and run it.

Snyk checks the CLI version that is installed and automatically installs/upgrades it in the background (if necessary, and as based on your policy configuration).

Snyk runs the snyk test command, analyzing the manifest file of your project to find its direct and transitive dependencies and testing your pipeline against the Snyk vulnerability database for known vulnerabilities.

From the Jenkins Console Output, the test results summary is displayed, indicating the number of known issues and the number of associated dependency paths identified.

Based on the Monitor project on build configuration for this project:

If you did not choose Monitor project on build, then Snyk displays all vulnerability results and details from the Snyk Security Report area of the Build menu. If a severity threshold was defined for a severity that is assigned to any vulnerability in your project, Jenkins breaks the build. Otherwise, Jenkins continues to run the build to completion (success or failure) and Snyk activity ends.

If you checkmarked the Monitor project on build option, then Snyk displays all vulnerability results and details from the Snyk Security Report area of the Build menu and pushes a snapshot for continuous monitoring to the Snyk UI. If a severity threshold was defined for a severity that is assigned to any vulnerability in your project, Jenkins breaks the build. Otherwise, Jenkins continues to run the build to completion (success or failure) and Snyk activity ends.

From the top of the report, click View on Snyk.io to view the snapshot and vulnerability information directly from our app.

For any project, you can add Snyk to your build to scan the code while you build and to fail the build for vulnerabilities, based on your configurations.

We recommend running a build with the Snyk Security step before deployment, to ensure excellent security posture.

For additional information with TeamCity and its features, refer to their documentation.

How to configure your build with a Snyk step

Add the step to a new or existing project:

For new projects, after configuring the Git repo from which to create the build, activate the auto-detect feature to automatically identify relevant steps for your project build.

For existing projects, navigate to edit the project build steps. When complete,Snyk Securityappears in the list of suggested steps and the current test policy appears in theParameters Descriptioncolumn:

Navigate to configure the Snyk Security step as follows:

Click anywhere on theSnyk Securityrow to access the configuration screen, or

for existing projects, clickAdd build stepto access the configuration screen.

Configure the TeamCity fields (Runner type, Step name and Execute Step).

Optionally, clickShow advanced options. Additional Snyk parameters are revealed:

ConfigureSnyk SettingsandSnyk Tool Settings. For more information seeTeamCity configuration parameters.

Once configured, run the build. When the Snyk Security step ends successfully, you can navigate to theSnyk Security Reporttab to view results within TeamCity and to navigate seamlessly to the Snyk UI for further action:

From the top of the report, clickView on Snyk.ioto view the snapshot and vulnerability information directly from our app.

Install or upgrade the Snyk Security plugin with these steps. Once complete, youre all set to add a Snyk step to your projects.

Warning

You must sign up for an account with Snyk before you begin.

How to install the Snyk plugin

Log in to your TeamCity instance to install the Snyk Security plugin. Configure thePlugins listtoPeriodically check for plugin updates, in order to ensure regular automatic upgrades in the background.

Navigate to the JetBrains Plugins Repository, search for Snyk and from theGetdropdown list, select to install the plugin for your TeamCity installation.

When the following prompt appears, clickInstall.

When the installation ends, theAdministration Plugins Listloads, notifying the plugin has been uploaded.

Ensure the plugin is enabled.

Parameters

Description and values

Snyk settings

Severity threshold

Default: low

For the first vulnerability found in your build with the threshold as configured, the build fails.

Monitor project on build

Default: ON

Snyk runs the snyk monitor command during the build, sending a project snapshot to the Snyk app and continuing to monitor the project for vulnerabilities even after this build.

File

Optional.

If the manifest file is not on the root level, enter the relative path to that file.

Organization

Optional.

The ID of the Snyk organization to which this project should be associated when imported to the UI.

Copy theOrganization IDfrom the Snyk UI in theSettingsarea.

Project name

Optional.

Enter any unique name for this project to recognize it when viewing from the Snyk UI.

Additional parameters

Optional.

Enter additional CLI arguments as necessary. See ourCLI documentation and cheat sheetfor additional information.

Snyk tool settings

Snyk API token

From theSettingsarea in the Snyk UI, copy the Org or PersonalAPI tokenor create a service account. This is the token used to authenticate your Snyk account when connecting to TeamCity.

Snyk version

Default: the most recent version

Select the plugin version to be used in your build if you would like an older Snyk CLI version to support the plugin.

We recommend configuring automatic upgrades and using the most recent version.

Use custom build tool path

Specify which tool instance in your local environment is to be used for this build by Snyk.

Otherwise Snyk auto-detects the tool and locates it in your environment based on project type.

To test even earlier in the development lifecycle Snyk has an IntelliJ plugin, allowing you to test your dependencies and get remediation advice during development.

How to install the IntelliJ plugin

Within IntelliJ, open the preferences page

Navigate to Plugins and then browse Repositories and search for snyk:

Install.

Read and accept the privacy notice.

Restart IntelliJ IDEA.

The Snyk plugin can be opened by clicking the tab at the bottom of the right-hand bar:

Install our Snyk Vuln Scanner in your Eclipse workflow to catch vulnerabilities and license issues directly from within your IDE (integrated development environment), before they are merged into your codebase.

Once installed and configured, every time you run the plugin, Snyk scans your projects manifest files and:

analyzes and delivers actionable vulnerability and license issue details

records results per package

displays results directly from the Eclipse UI

The Snyk plugin enables you to track and identify issues that risk your applications security and avoid ever adding those issues to your shared repo.

Note

This plugin supports our Snyk Broker and onprem solutions.

Supported languages and repos

Snyk supports all languages that are supported by both Eclipse and Snyk. Additionally, the Snyk plugin can also be implemented with our Broker and on-prem solutions.

Installing the Eclipse Snyk plugin

Navigate to the Marketplace from within your running Eclipse instance.

Search for Snyk and click Install.

When prompted accept the license agreement and the Snyk Security certificate to complete the installation.

Restart the Eclipse instance and navigate to Eclipse Preferences to ensure Snyk Vuln Scanner now appears in the list:

Use the Snyk plugin to secure your Eclipse projects

From the Snyk results click whenever you are ready to scan your projects. It shouldnt take too long for the results to appearbut no worries! You can continue to work as usual in the meantime anyway.

If for any reason you need to stop the scan before the build ends, click .

If you only want to scan a single project in your workspace, navigate to the Package Explorer panel, right-click the root of the project you want to test, and then choose Snyk test.

When the scan ends, results and any relevant error messages as well, are displayed from the Snyk results, grouped by project similar to the following:

Work with Snyk results from Eclipse as follows:

Column

Description

Context menu

Right-click menu

Options include:

Ignore issueHover over the specific issue that you want to ignore for the next 30 days and then access the context menu.

Snyk testRun the Snyk test for the entire workspace.

PreferencesAccess and update Snyk Vuln Scanner preferences directly from the right-click menu.

When collapsed

Title

The name of the project.

Dependency

A summary of vulnerabilities and the number of affected paths found per project.

When expanded

Title

The full name of the vulnerability affecting your project, linked to a description and complete details of the vulnerability in our database, to assist you in resolving the issue.

Dependency

The name of the direct dependency package in your project (the package you explicitly installed) that is affected by the vulnerability, either directly or indirectly.

All details appear on a single row and the Dependency (the name of the package explicitly used in the code) and Package (the name of the package that actually contains the vulnerability) columns both display the name of the same package:

When your project is affected by an indirect vulnerability:

Collapsed mode

An arrow appears on the row, grouping together all relevant details, similar to the following examples:

For example:

Package X uses Package Y, which in turn uses Package Z.

Package Z contains a Cross-Site Scripting (XSS) vulnerability, indirectly affecting your project.

The Dependency (the name of the package explicitly used in the code) is Package X; the Package field displays Package Z (the name of the package that actually contains the vulnerability).

Expanded mode

Click the arrow on the row to expand and view the full path from the direct dependency to the actual vulnerable package.

In the example above, the full path would appear as:

[Name of Package X]-->[Name of Package Y]-->[Name of Package Z]

Package

The name of the package in your project that is directly affected by the vulnerability.

In the example above:

the Dependency is indicated as Package Xthis is the package the developer explicitly uses in the code

the Package field displays Package Z, which is the package that actually contains the vulnerability.

Fix

The name of the package, if such exists, and the version that it can be upgraded to in order to resolve the issue.

Snyks Cloud Foundry integration lets you monitor the deployed code of your Java, Node.js and Ruby Cloud Foundry applications for any known vulnerabilities found in the applications dependencies, testing at a frequency you control.

For each test, Snyk will communicate directly with Cloud Foundry to determine exactly what code is currently deployed and what dependencies are being used. Each dependency will, in turn, be tested against Snyks vulnerability database to see if it contains any known vulnerabilities.

If vulnerabilities are found, you will be alerted (via email or Slack) so that you can take immediate action.

In order to turn on the Cloud Foundry integration youll need to:

Connect to Cloud Foundry from the integrations page

Select the projects you want to monitor and click Add to Snyk

Connect Snyk to Cloud Foundry

In order for Snyk to be able to monitor your deployed Cloud Foundry applications, youll first need to connect Snyk to your Cloud Foundry account. You can do this by navigating to the Integrations page and clicking on Connect to Cloud Foundry.

project dashboard

This will take you to a page where youll be prompted to enter your Cloud Foundry API URL, username and password. We recommend setting up a dedicated user for your Snyk organization.

Instructions for how to locate your Cloud Foundry API URL are below.

Cloud Foundry: locate your API URL

You can find your Cloud Foundry API URL from the cf CLI tool.

$ cf api API endpoint: https://api.example.com (API version: 2.2.0)

From there you can login to your Snyk account and enter your Cloud Foundry credentials.

Cloud Foundry: check your connection status

At any time afteryou'veentered your Cloud Foundry credentials, you can check on the connection status in one of two places.

The first is on your integration settings page, where youll see your current integrations listed as well as their connection status.

The connection status is also displayed directly on the Cloud Foundry integration settings page (found by clicking Edit settings on the integration settings page shown above). Ifyou'veentered credentials, youll see a box indicating whether or not Snyk is able to correctly connect to Cloud Foundry.

If you are unable to connect, please re-enter your account credentials to verify that they are correct.

Disable the Cloud Foundry integration

If you decide to disable this integration for any reason, you can accomplish this from the Integrations page in your Settings.

You need to find the specific integration you wish to deactivate in your list of integrations and click Edit settings. You are taken to a page that shows the current status of your integration, a place to update your credentials, specific to each integration (credentials, API key, Service Principal, or connection details), and a red box at the bottom to disconnect this integration, like in the example seen below:

If you choose to disconnect, your credentials will be removed from Snyk and any integration-specific projects we had been monitoring will be deactivated on Snyk.

If you choose to re-enable this integration at any time, you need to re-enter your credentials and activate your projects.

Add a Snyk-specific user to Cloud Foundry

We suggest adding a dedicated user to Cloud Foundry for your Snyk org. That way if at some point you need to revoke access for any reason, you can do so without impacting anyone within your org.

The minimum permissions needed in order to integrate with Snyk is the space role of SpaceAuditor.

You can create a new user with these permissions from the command line using the following commands:

cf create-user snyk pa55w0rd

cf set-space-role snyk my-example-org development SpaceAuditor

You can learn more about how to add another user to your application on the Cloud Foundry documentation.

Add Cloud Foundry apps to Snyk

Onceyou'vesuccessfully connected Snyk to your Cloud Foundry account, youll be able to select Cloud Foundry apps that you would like Snyk to monitor. You can do this either using the Add projects button on the integrations page or directly from the Cloud Foundry integration settings page.

In either case, youll see a list of any available projects on the Cloud Foundry account you connected. Select the ones you want to monitor and click the add to Snyk button.

As soon asyou'veadded the projects to Snyk, Snyk will test them and begin to display a list of all monitored Cloud Foundry applications in your . Youll also see a snapshot of any current vulnerabilities, and be able to click through for a more detailed report including any steps to remediate.

Snyk will now continuously monitor each of those projects for known vulnerabilities. You can add more projects at any time.

In order for Snyk to be able to monitor your deployed Heroku applications, youll first need to connect Snyk to your Heroku account. You can do this by navigating to the Integrations page and clicking on Connect to Heroku.

project dashboard

This will take you to a page where youll be prompted to enter your Heroku API Key. There is only one API Key per Heroku user so we recommend setting up a dedicated user for your Snyk organization.

Instructions for how to generate and locate your Heroku API key are below.

Generate your Heroku API key

You can find and generate your Heroku API key in your Account Settings section of your Heroku Account.

Alternatively, you can use the Heroku CLI to generate your API key and copy it directly to your clipboard:

heroku auth:token | pbcopy

From there you can login to your Snyk account and paste in your Heroku credentials.

Heroku: check your connection status

At any time afteryou'veentered your Heroku credentials, you can check on the connection status in one of two places.

The first is on your integration settings page, where youll see your current integrations listed as well as their connection status.

The connection status is also displayed directly on the Heroku integration settings page (found by clicking Edit settings on the integration settings page shown above). Ifyou'veentered credentials, youll see a box indicating whether or not Snyk is able to correctly connect to Heroku.

If you are unable to connect, please re-enter your account credentials to verify that they are correct.

Add a Snyk-specific user to Heroku

On Heroku, each user is limited to one API key so we suggest adding a dedicated user for your Snyk org. That way if at some point you need to revoke the key for any reason, you can do so without impacting anyone within your org.

This can be accomplished through the Heroku admin interface, or from the command line using the following command:

heroku access:add [email protected]

You can learn more about how to add another user to your application on the Heroku documentation.

Disable the Heroku integration

If you decide to disable this integration for any reason, you can accomplish this from the Integrations page in your Settings.

You need to find the specific integration you wish to deactivate in your list of integrations and click Edit settings. You are taken to a page that shows the current status of your integration, a place to update your credentials, specific to each integration (credentials, API key, Service Principal, or connection details), and a red box at the bottom to disconnect this integration, like in the example seen below:

If you choose to disconnect, your credentials will be removed from Snyk and any integration-specific projects we had been monitoring will be deactivated on Snyk.

If you choose to re-enable this integration at any time, you need to re-enter your credentials and activate your projects.

Add Heroku projects to Snyk

Onceyou'vesuccessfully connected Snyk to your Heroku account, youll be able to select Heroku projects that you would like Snyk to monitor. You can do this either using the Add projects button on the integrations page or directly from the Heroku integration settings page.

In either case, youll see a list of any available projects on the Heroku account you connected. Select the ones you want to monitor and click the add to Snyk button.

As soon asyou'veadded the projects to Snyk, Snyk will test them and begin to display a list of all monitored Heroku applications in your . Youll also see a snapshot of any current vulnerabilities, and be able to click through for a more detailed report including any steps to remediate.

Snyk will now continuously monitor each of those projects for known vulnerabilities. You can add more projects at any time.

Snyks Pivotal Web Services integration lets you monitor the deployed code of your Java, Node.js and Ruby Pivotal Web Services applications for any known vulnerabilities found in the applications dependencies, testing at a frequency you control.

For each test, Snyk will communicate directly with Pivotal Web Services to determine exactly what code is currently deployed and what dependencies are being used. Each dependency will in turn be tested against Snyks vulnerability database to see if it contains any known vulnerabilities.

If vulnerabilities are found, you will be alerted (via email or Slack) so that you can take immediate action.

In order to turn on the Pivotal Web Services integration youll need to:

Connect to Pivotal Web Services from the integrations page

Select the projects you want to monitor and click Add to Snyk

Connect Snyk to Pivotal Web Services

In order for Snyk to be able to monitor your deployed Pivotal Web Services applications, youll first need to connect Snyk to your Pivotal Web Services account. You can do this by navigating to the Integrations page and clicking on Connect to Pivotal Web Services.

Pivotal console

This will take you to a page where youll be prompted to enter your Pivotal Web Services username and password. We recommend setting up a dedicated user for your Snyk organisation.

Pivotal Web Services: check your connection status

At any time afteryou'veentered your Pivotal Web Services credentials, you can check on the connection status in one of two places.

The first is on your integration settings page, where youll see your current integrations listed as well as their connection status.

The connection status is also displayed directly on the Pivotal Web Services integration settings page (found by clicking Edit settings on the integration settings page shown above). Ifyou'veentered credentials, youll see a box indicating whether or not Snyk is able to correctly connect to Pivotal Web Services.

If you are unable to connect, please re-enter your account credentials to verify that they are correct.

Add Pivotal Web Services apps to Snyk

Onceyou'vesuccessfully connected Snyk to your Pivotal Web Services account, youll be able to select Pivotal Web Services apps that you would like Snyk to monitor. You can do this either using the Add projects button on the integrations page, or directly from the Pivotal Web Services integration settings page.

In either case, youll see a list of any available projects on the Pivotal Web Services account you connected. Select the ones you want to monitor and click the add to Snyk button.

As soon asyou'veadded the projects to Snyk, Snyk will test them and begin to display a list of all monitored Pivotal Web Services applications in your project dashbard. Youll also see a snapshot of any current vulnerabilities, and be able to click through for a more detailed report including any steps to remediate.

Snyk will now continuously monitor each of those projects for known vulnerabilities. You can add more projects at any time.

Disable the Pivotal Web Services integration

If you decide to disable this integration for any reason, you can accomplish this from the Integrations page in your Settings.

You need to find the specific integration you wish to deactivate in your list of integrations and click Edit settings. You are taken to a page that shows the current status of your integration, a place to update your credentials, specific to each integration (credentials, API key, Service Principal, or connection details), and a red box at the bottom to disconnect this integration, like in the example seen below:

If you choose to disconnect, your credentials will be removed from Snyk and any integration-specific projects we had been monitoring will be deactivated on Snyk.

If you choose to re-enable this integration at any time, you need to re-enter your credentials and activate your projects.

Add a Snyk-specific user to Pivotal Web Services

We suggest adding a dedicated user to Pivotal Web Services for your Snyk org. That way if at some point you need to revoke access for any reason, you can do so without impacting anyone within your org.

The minimum permissions needed in order to integrate with Snyk is the space role of SpaceAuditor.

You can create a new user with these permissions from the Cloud Foundry command line using the following commands:

cf create-user snyk pa55w0rd

cf set-space-role snyk my-example-org development SpaceAuditor

You can learn more about how to add another user to your application via the command line on the Cloud Foundry documentation.

Alternatively, you can add a Snyk-specific user via the .

Snyk Broker overview

The Broker, an open-source tool composed of a client and a server-side, acts as a proxy between Snyk and your on-premise hosted Git repositories (e.g. GitHub Enterprise or BitBucket Server) and with your on-premise Jira installation when installed behind a firewall.

The Broker client is a service to be installed and hosted on your private infrastructure. Together with the Broker server, hosted on the Snyk backend, it establishes a secure and moderated tunnel with Snyk servers.

With this secure connection, the Broker client:

keeps sensitive data such as your access tokens, within the perimeter of your private networknever sharing that information with Snyk.

limits access to your network by Snyk to the bare minimum required in order to scan and monitor vulnerabilities and offer automated remediation.

Installed within your organizations private network, the Broker client maintains an explicit approved data list, for inbound and outbound data requests, in order to provide maximum protection for your network.

The default approved list provided by Snyk limits bi-directional communication as follows:

InboundSnyk.io is only allowed to fetch and view dependency manifest files and the Snyk policy file. No other source code is viewed, extracted, or modified under any circumstances. Additional files (.snyk files) might be checked in to support our patch mechanism and for any ignore instructions included in your vulnerability policy. For more information about these, see Manifest files.

OutboundGit repo webhooks are set when you initially configure your Broker setup and are necessary to enable automatic Snyk scans that are triggered when new pull requests or merge events are submitted by your developers. Webhook notifications are delivered to Snyk via the Broker client for only events relevant to Snyk actions (push to branch, pull request opened), AND only when the event data also includes a dependency manifest file or a Snyk policy file.

All data, both in transit and at rest, is encrypted. Communication between the Broker client and the Broker server takes place over a secure WebSocket connection.

All requests and webhooks not included in this approved list are dropped.

Note

Broker can also be used as a proxy between Snyk and your publically-accessible Git repos themselves. When implemented for public repos, every interaction between the Broker client and your Git repos is logged, thereby increasing your visibility and control over Snyk activity in those repositories and increasing data security.

The communication between Snyk, the Broker and your repo, as well as the data shared with Snyk, are further described step-by-step in How it works.

Snyk Broker: how it works

The Broker workflow comprises these main components:

Snyk SaaS backend (on Google Cloud Platform)/Broker server

Snyk Broker client ( a Docker image running on a virtual machine behind your firewall)

Either a Git repo instance (Github Enterprise, Gitlab, Bitbucket Server) or Jira

Once implemented the components communicate similarly to the following diagram:

https://app.snyk.io

The Broker workflow is as described in the following steps:

Your organizations IT administrator installs Snyk Broker client, with a Docker image, on a host that has access to the on-prem Git repo as well as outbound access to https://broker.snyk.io (the Broker server). It is preferable to install at least two instances for every integration planned for your deployment to support redundancy.

Your organizations admin configures the Broker client by providing a personal access token or credentials (from your repo or Jira account as described in Retrieve a unique Broker client token). The Broker client uses those credentials to create webhooks on particular events performed against your Git repos (for example, when a PR is created), which trigger events on the Snyk backend to run the appropriate tests (scans). The token or credentials must have the appropriate scope (also as described in Retrieve a unique Broker client token) and be tied to a user or service account that has enough privileges to create these webhooks. These credentials remain within your perimeter at all times and are never sent to the Snyk SaaS backend. They are also obfuscated in the Broker client logs.

Snyk support enables the Broker functionality, exposing a Snyk token in the Project settings area of the snyk.io UI (and as further described in Retrieve a unique Broker client token). This token is used by the Broker client to authenticate itself whenever communicating with Snyk.

Your admin initiates the Broker with a simple Docker command, which activates the container/s.

When initiating, the Broker client container/s calls home (establishing contact with the Broker server at https://broker.snyk.io) using the TLS protocol (through port 443 out/HTTPS, which must be allowed by your firewalls) and establishes a WebSocket (2-way connection) over that open pipe. Each running Broker client container opens a persistent bi-directional WebSocket connection to the Snyk servers that facilitates ongoing communication with your on-premise repo. The Broker client also establishes communication with your Git repo with an HTTPS connection.

Once the connection is established, your developers can each access snyk.io to commence work, as outlined in the remainder of this process.

When a developer clicks Add projects from the Integrations area of snyk.io, snyk.io sends a request to the Broker server to fetch the list of repositories available (HTTPS).

The Broker server tunnels this request to the Broker client. The Broker client validates this request type against its approved list, and then relays that request to the customers Git repository only if included in that list.

The response is the list of repositories to which Snyk has access. Access is determined by the token that the admin created from the Git repo, and is also based on the permissions of the account itself that was used to create that token. The response list is then returned to the Snyk backend for display to the end user from the UI.

The user selects a repo (or repos) to import from the snyk.io UI and clicks Import.

Via the Broker server, snyk.io then sends the Broker client a request to fetch a manifest file/s from the repositories that the developer selected. As before, the Broker server tunnels this request to the customer's Broker client. The Broker client validates the request against the approved list, and then sends that request to the customer's Git repo.

The manifest file/s is then returned to the Snyk SaaS backend over a secure encrypted connection (Snyk uses TLS 1.2 protocol and above with strongest ciphers).

Snyk extracts the dependency tree for the repo and matches the dependencies against our vulnerability database.

In addition to the import and analysis, webhooks are also set (using HTTPS) on the specific repo to trigger on future events for new Pull Requests.

The dependency tree and findings are displayed in the Snyk UI, and the notification mechanisms, monitoring, reporting, Slack integration and more are enabled.

Whenever your developers submit new pull or merge requests, your Git notifies (HTTP) Snyk of that Pull Request by using the webhook that was set upon Import. The extraction mechanism is identical, but this time against the manifest file(s) in the PR, which is used to compare the delta with the base/branch.

Set up Snyk Broker

The Broker client can be installed and configured for use with one or more Git repos, and also with your on-prem Jira when installed behind a firewall.

The connectivity to an on-prem Git repo is achieved by running the Snyk Broker (Broker client) inside the customers network on a host that has access to the on-prem SCM as well as outbound access to https://Broker.snyk.io.

The Broker is an open source project hosted at GitHub, published as a set of Docker images, and each configured for a specific integration. It is best to install the Broker client as a Docker image. Furthermore, you can customize the configuration by using the environment variables offered in the Docker images, also specific to each integration. For this reason, you should install separate, multiple instances of the client for different integration types to ensure proper configuration as well as redundancy (two GitHub instances in one deployment should be separate from a Bitbucket or Jira deployment for example).

To install, configure and roll out your Broker client and repo integration, follow these steps:

Prepare for deployment

Enable permissions for Snyk from your repo/Jira

Retrieve a unique Broker client token

Install and configure the client

Import projects to Snyk

Supported integrations

Snyk Broker currently integrates with these systems:

GitHub

GitHub Enterprise

GitLab

Bitbucket Server

Jiraatlassian.net on-prem

Supported manifest files

Snyk.io fetches and views dependency manifest files in order to analyze and deliver vulnerability results. To get proper test results and to create Snyk projects, at least one of the following manifest files must be present in the tested folder (for integration with CLI), or in the repository (for integration with Git).

Golang

Gopkg.* & vendor/vendor.json

Gradle

build.gradle

Maven

pom.xml

SBT

build.sbt

Pip

requirements.txt

RubyGems

Gemfile.lock

NPM

package.json

package.json & package-lock.json

Yarn

package.json

package.json & yarn.lock

Nuget

project.json

*.csproj, *.vbproj, *.fsproj

packages.config

Note

Your Broker client must be the most recent version in order to ensure that all of these manifest files are supported and found when importing projects to snyk.io.

Prepare Snyk Broker for deployment

In this article, you find the prerequisites and all the information you need to prepare Broker and configure your network for deployment.

Prerequisites

Create a Snyk account and contact [email protected] to enable Broker integration for the organization for which you would like to implement the proxy. Each Broker is identified by a UUID token. Once Broker support has been enabled for your organization, you can access your unique Broker token on the organizations Settings page from the Snyk UI, as described in Retrieve a unique Broker client token. This token is private, and must not be shared.

Install and set up Docker Hub from the client machine on which you want to install the Broker.

Prepare hosts for installation

We recommend configuring:

at least two separate instances of the Broker client for every integration you plan on deploying, either on different hosts or installed via a Kubernetes system to ensure that you always have two (or more) instances running; for example, if you plan on deploying both GitHub and Jira, you should plan on installing for 4 instances, 2 of each to ensure redundancy.

separate Broker clients for every unique integration

Ensure each host designated for the Broker client installation has:

access to the on-prem Git deployment

an outbound TLS (443) connection to https://broker.snyk.io that is also allowed by any firewalls installed on your network. The Broker client needs to be accessible for webhooks coming from the Git repo. Alternatively, you can specify which port the Broker client listens on using the --port command line argument.

Configure your network

If you use a proxy server, ensure you configure it, and any firewalls, to allow the Broker client inbound and outbound access.

Traffic (very light) initiated from your network (i.e. webhooks) should be load-balanced across the broker instances for redundancy purposes; payloads transiting through WebSocket connection used to proxy the request to the broker server are small as well.

Traffic initiated from the Snyk (server) side always uses the latest Broker connectionwe maintain a stack of the connections and always use the top one. If that Broker connection fails for whatever reason, Snyk removes it from the stack and uses the previous one for connection, and so on. All activity from our side (e.g. driven by recurring tests) appears on only one of your replicas at a time (the latest one to connect to us).

In practical terms, this means the amount of Snyk activity is proportional to the activity in your repos (or Jira) as that activity generates webhooks, which is distributed across all replicas.

Snyk Broker: enable permissions for Snyk Broker from your repo/Jira

In order to enable Snyk to find, monitor, fix and prevent, Snyk needs credentials to communicate with and send information to your repo.

Modern Gits grant various access rights by scoped authorization (auth) tokens to ensure that access to repo data and actions are managed. The various scopes associated to tokens grant specific ranges of action on repos.

snyk.io access rights to the Git repos are regulated by such Git access mechanisms and scopes. Therefore, you need to generate auth tokens or credentials for Snyk to perform tasks such as submitting fix pull requests or merge requests. Because tokens are generated by and associated to users (or accounts) that are then added as members of that given repo, the credentials must be generated from a user or service account that also has enough privileges to create the necessary webhooks and pull requests (usually admin-level).

Once you have generated a token, you set it only in the Broker configuration file during installation. Since the client runs from your private network, the credentials are never shared or sent to Snyk. Credentials (or tokens) never leave your network.

Requirements

Snyk requires:

read access on a repo to perform an initial test (Find) and recurring tests (Monitor).

Note that while *not* recommended, Snyk can function in read-only mode, but would then not able to offer Prevent and Fix functionality.

write access on repo including webhooks to also perform pull request checks (Preventchecking code whenever one of your developers submits a new pull request) and Pull Request creation (Fix and AutoFixcreating a pull request in order to apply a security fix). Snyk never writes directly to your repositories, but rather opens Pull Requests with suggested changes. Explicit approval of the Pull Request is always required before said suggestions are taken.

Permissions

Assign permissions based on your integration as follows:

GitHub/GitHub Enterprisesee GitHub documentation for assistance in creating the necessary token: https://github.com/settings/tokens

Bitbucket serverSnyk needs to use the username and password credentials of a Bitbucket user in your organization. See Bitbucket documentation for assistance in creating a user with the necessary credentials: https://confluence.atlassian.com/bitbucket/grant-repository-access-to-users-and-groups-221449716.html

GitLabSnyk needs to use an access token with API scope. See GitLab documentation for assistance in creating an access token with the necessary credentials: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

JiraSnyk needs user credentials with API access. When installing the client, if you wish to authenticate with an API token, then provide the username (usually an email address) as the JIRA_USERNAME and the API token as the JIRA_PASSWORD in the command line arguments. See Jira documentation for assistance in creating a user with the necessary credentials: https://confluence.atlassian.com/cloud/api-tokens-938839638.html

Generate credentials for Snyk

Create the token or user account with the permissions for the specific integration, as described above.

Copy and paste the credentials/token in a file on the desktop to use in the environment variables of the command line argument when you install the client: Install and configure the client.

Snyk Broker: retrieve a unique Broker client token

In order to enable the Broker client to contact the Broker server (Snyk servers), you need to provide the client with Snyk credentials. Snyk credentials are granted with a Broker UUID token, which you can enable through our Support team.

For each organization in Snyk, you can only configure one instance of each integration type. For example, a single organization can integrate with one GitHub repo and also one Bitbucket repo. Similarly, you can run only one Broker for each integration type per organization. This means that any organization can have one integration for each of the different integration types from a single Snyk organization.

At the same time, a second, separate, integration can only be associated with a different organization in Snyk. For example, organization X can integrate with GitHub X and Bitbucket X. If you also work with GitHub Y repos, then you must associate those repos to any organization in Snyk other than organization X.

On the other hand, you can choose to use the same Git across multiple organizations in Snyk by simply using the same Broker token for all of the different organizations. For example, you can integrate Snyk organizations X, Y and Z with your single Git repo X.

To do this, first ensure the token has been created for the desired organization, and then create a new additional organization based on the original. When you do this, the token is cloned for the new organization and you can now enable the Broker for it.

How to retrieve a unique Broker client token

Contact Snyk support to enable Broker functionality.

Once the Support team enables Broker for you, the fields in the Settings => Integrations area for that specific integration update and now display the Broker token. You need this token to install the Broker client.

To retrieve the token, from your snyk.io account navigate to Settings =>Integrations.

From the row for the integration youre setting up, click Edit settings.

Note

Since you have not yet installed and configured the client, the notification from this screen correctly displays Could not connect to.

Copy and paste the credentials/token in a file on the desktop to use in the environment variables of the command line argument when you install the client: Install and configure the client.

Install and configure your Snyk Broker client: overview

Install the Broker client using the Docker image designed for the specific repo (or Jira). The relevant command line argument and environment variables are fully detailed per integration in the following location: https://hub.docker.com/r/snyk/broker/.

At this Docker Hub location you can find the following details and instructions:

Unique Docker images for each of the different available integrations. Use the command line arguments and environment variables relevant to the integration you are deploying.

A full description of the mandatory environment variables per integration typefrom the README file, in the opening section for each of the different integrations, the mandatory variables are listed.

In addition, take special note of the following: For the hostname of your private repo/Jira deployment, use the URL of the repo without the https:// prefix, such as your.ghe.domain.com.

For the Broker client URL, enter the full URL of the Broker client that you installed on your network including the HTTP prefix and the port suffix. For example https://gitlab-broker.companyname:7341

Advanced installation instructions in cases when you prefer to build your own Docker image as part of the installation, providing an additional layer of security

Advanced configuration instructions for HTTPs, SCM certificates, and customized approved lists

Instructions for monitoring and troubleshooting, such as /healthcheck and /systemcheck

When installing the client, if you wish to authenticate with an API token, then provide the username (usually an email address) as the JIRA_USERNAME and the API token as the JIRA_PASSWORD.

Heres an example of the parameters and values for Bitbucket:

docker run --restart=always \

-p 8000:8000 \

-e BROKER_TOKEN=secret-broker-token \

-e BITBUCKET_USERNAME=username \

-e BITBUCKET_PASSWORD=password \

-e BITBUCKET=your.bitbucket-server.domain.com \

-e BITBUCKET_API=your.bitbucket-server.domain.com/rest/api/1.0 \

-e BROKER_CLIENT_URL=https://my.broker.client:8000 \

-e PORT=8000 \

snyk/broker:bitbucket-server

Tip

Save the command-line arguments and values to copy and paste when you need to upgrade in the future.

Note

The Broker token is as sensitive as user credentials. Do not share it with others or distribute it electronically.

How to install and configure your Snyk Broker client

Download the Broker Docker image from here: https://hub.docker.com/r/snyk/broker/ with the docker pull command. You must indicate a specific tag for the pull to succeed; indicate the integration platform as the snyk/broker tag, similar to the following example: docker pull snyk/broker:github-com

Use the command line arguments for the integration you want to set up as detailed in our Docker README (same location), entering the correct values for the different environment variables, including the values you prepared and saved on the side: the token/credentials you set up for Snyk (Enable permissions for Snyk from your repo/Jira) and the Broker token (Retrieve a unique Broker client token).

Press Enter to run the command arguments.

As part of the output, identifying Broker server appears towards the end of the log results, indicating connection has been established.

Refresh the Snyk app.

If this is an installation for upgrade, you can continue working as before.

Select the organization with which you are integrating and navigate to Integrations where you can now see the Add projects button is enabled. For example, if you asked Support for GitLab integration, the relevant button is now activated.

To add projects for scanning, see Import projects to Snyk.

Upgrade your Snyk Broker client

Snyk regularly updates the Broker client in order to provide new features, bug fixes and more. Our full list of versions and their release notes are available from GitHub as part of our Broker project. We also encourage you to subscribe to the RSS feed for that page to easily receive info about versions as they are released.

To upgrade any container, which is a running copy of its image, you need to kill it, delete its instance, and then replace its image (with the docker pull command) and run it again. Similarly, to upgrade your Broker client, which is also installed as a container, you must do the same.

Steps:

Obtain a list of all Docker containers currently running on this host by running the command: docker ps A full list of all Docker containers that are currently running on this host and their container IDs is returned, including actively running Broker containers.

Kill and delete running the Broker containers: To kill all running Broker containers, run the following command, separating multiple container IDs with a space only: docker kill <container_ID> <container_ID>

Now that the containers have stopped running, delete them by running the following command, separating multiple container IDs with a space only: docker rm <container_ID> <container_ID>

Now, delete the Docker image that was originally downloaded when installing the Broker by running the following command, separating multiple image IDs with a space only: docker rmi <image_ID> <image_ID>

Once you have killed all running containers and deleted the original image, install a new version of the Broker client. To do so, follow the instructions in Install and configure the client.

Snyk Broker: import projects

Once your Broker client is up and running, you can import projects and begin finding, monitoring, fixing and preventing vulnerabilities for your private repo deployment.

Steps:

Log in to

Select the organization that youre using with your Broker.

Navigate to the Projects page and click on Add Projects.

When prompted, select the Git repo with which you integrated the Broker.

Repositories from your Brokered Git appear and you can now select the relevant projects for import.

With the Snyk plugin for Artifactory you can track open source vulnerabilities and license details in your cached artifacts.

Once installed, Snyk plugin runs in the background and automatically:

Blocks devs from downloading packages with vuln / license issues according to a predefined threshold that the admin sets

Adds vuln and license data from Snyk as properties in artifact

Continuously monitoring cached artifacts and update their vuln and license data from Snyk (coming soon)

By scanning artifacts as part of your workflow and then displaying those test results directly from the Artifactory UI, the Snyk plugin enables you to more quickly track and identify issues that risk your applications security and avoid using those artifacts in your projects.

This plugin is available for Pro and Enterprise plans.

Install the Artifactory Snyk plugin

To install our plugin, first, download the archived (.zip) distribution of the Snyk Security Artifactory plugin as described in the steps below.

This archive contains the following structure, files and folders:

*plugins

snykSecurityPlugin.groovyour plugin

snykSecurityPlugin.propertiesthe configuration file for the plugin

*libthis is the folder that contains the dependencies for this plugin.

artifactory-snyk-security-core.jar

Install or upgrade the Snyk Security plugin with these steps. Once complete, Snyk automatically scans your artifacts every time you request to download them.

Prerequisites

You must sign up for a Pro or Enterprise account with Snyk before you begin.

You must have a minimum of Artifactory public API 6.2.0 with your Artifactory installation.

How to the Artifactory Snyk plugin

Go to your Snyk account and navigate to Settings to locate, copy and save the following on the side:

service account token

the Organization ID for (any) one of your organizations

Go to our repo in GitHub and navigate to the Releases.

From the most current release, open the Assets section to download the artifactory-snyk-security-plugin-<version>.zip archive.

Extract the folders and files and move the contents of the plugins folder to /artifactory/etc/plugins

Right-click the snykSecurityPlugin.properties file to open and edit it with any text editor.

The file contents appear as in the image:

Note

When a backup file is created for the .properties file, Artifactory cannot recognize the difference between the original and the new file. Therefore, disable any backup features configured for the editor you choose before editing the file.

The following properties can be configured in this file:

snyk.api.urlon-prem customers should update the URL of their Snyk API endpoint based on their Snyk deployment; other users need not configure a URL.

snyk.api.tokenthis property is mandatory and must be configured in order for Snyk to authenticate your account, before scanning your artifacts.

Snyk.api.organisationthis property is mandatory and must be configured in order for Snyk to authenticate your account, along with your API token. Because this plugin does not import any data to your Snyk account, you can use the ID from any of your organizations.

snyk.artifactory.scanner.vulnerability.thresholddefault is *low*. Valid values include low, medium, high. Manually update the configuration based on your needs.snyk.artifactory.scanner.license.thresholddefault is *low*. Valid values include low, medium, high. Manually update the configuration based on your needs.

Paste the token and the organization ID in place of the sample values for each of the parameters.

Copy and paste the plugin into `${ARTIFACTORY_HOME}/etc/plugins/`

Restart your Artifactory server.

Note

Refresh now or Reload is not sufficient. Artifactory must be restarted.

Log in to your Artifactory instance and navigate to the System Logs to double-check Snyk has been installed successfully.

Artifactory plugin: use Snyk for your artifacts

Snyk runs in the background and whenever a download is requested from the UI or from the CLI, Snyk automatically scans the artifact to evaluate vulnerabilities and license issues.

When the scan ends, results are displayed in the Artifactory UI, in the artifact details.

To view details about download status, open the System Logs:

When the scan fails, based on the configurations that were set during installation, the download request is blocked. By reviewing the results, you can evaluate the issues found in your artifact and determine a course of action, before ever using that artifact.

When your setup blocks downloads with issues, you can override this configuration at the artifact levelenabling downloads even when issues are identified, per artifact.

Snyk's Azure Function Apps integration lets you monitor the deployed code of your Node.js, .Net and Java Azure Function Apps for any known vulnerabilities found in the application's dependencies, testing at a frequency you control.

For each test, Snyk will communicate directly with Azure to determine exactly what code is currently deployed and what dependencies are being used. Each dependency will in turn be tested against Snyk's vulnerability database to see if it contains any known vulnerabilities.

If vulnerabilities are found, you will be alerted (via email or Slack) so that you can take immediate action.

In order to turn on the Azure Function Apps integration you'll need to:

Connect to Azure from the integrations page

Add your Azure account credentials to Snyk

Select the projects you want to monitor and click "Add to Snyk"

Connect Snyk to Azure Functions

In order for Snyk to be able to monitor your deployed Azure Function apps, you'll first need to connect Snyk to your Azure account. You can do this by navigating to the Integrations page, locating "Azure and clicking on "Connect to Azure Functions".

project dashboard

This will take you to a page where you'll be prompted to enter your Azure service principal credentials.

Instructions for how to generate and locate your Azure service principal credentials are below.

Generate your Azure service principal

To give Snyk access to your Azure account, you'll need a valid service principal.

To create a service principal for use by Snyk, you can either use the Azure Portal or the Azure CLI 2.0.

After installing the Azure CLI 2.0, you should have the az command. Authenticate the CLI with your account using:

az login

Once authenticated, use it to create the service principal:

az ad sp create-for-rbac --name SpNameExample --role "Website Contributor"

This would result in JSON output similar to the following, which contains the service principal name, password and tenant that you'll need for setting up Snyk:

{

"appId": "f5f1ce7d-c247-42e6-91a4-ad1e7example",

"displayName": "SpNameExample",

"name": "http://SpNameExample",

"password": "97adeba6-4178-4f2b-bf5f-782b3example",

"tenant": "874186fd-a7a8-4e98-9b9e-3df00example"

}

From there you can login to your Snyk account and paste in your name, password and tenant.

More information on creating a service principal for Azure can be found in Azure's documentation:

CLI, Portal

Azure Functions: check your connection status

At any time after you've entered your Azure service principal, you can check on the connection status in one of two places.

The first is on your integration settings page, where you'll see your current integrations listed as well as their connection status.

You can also check the status directly on the Azure Functions integration settings page (found by clicking "Edit settings" on the integration settings page shown above). If you've entered credentials, you'll see a box indicating whether or not Snyk is able to correctly connect to Azure.

If you are unable to connect, please re-enter your account credentials to verify that they are correct.

Disable the Azure Functions integration

If you decide to disable this integration for any reason, you can accomplish this from the Integrations page in your Settings.

You need to find the specific integration you wish to deactivate in your list of integrations and click Edit settings. You are taken to a page that shows the current status of your integration, a place to update your credentials, specific to each integration (credentials, API key, Service Principal, or connection details), and a red box at the bottom to disconnect this integration, like in the example seen below:

If you choose to disconnect, your credentials will be removed from Snyk and any integration-specific projects we had been monitoring will be deactivated on Snyk.

If you choose to re-enable this integration at any time, you need to re-enter your credentials and activate your projects.

Add Azure Functions to Snyk

Once you've successfully connected Snyk to your Azure account, you'll be able to select Azure functions that you would like Snyk to monitor. You can do this either using the "Add projects" button on the integrations page, or directly from the Azure Functions integration settings page.

In either case, you'll see a list of any available Function apps on the Azure account you connected. Select the ones you want to monitor and click the "Add to Snyk" button.

Note: We currently support importing only v2 functions. v1 functions will be ignored.

As soon as you've added the projects to Snyk, Snyk will test them and begin to display a list of all monitored Azure functions in your . You'll also see a snapshot of any current vulnerabilities, and be able to click through for a more detailed report including any steps to remediate.

Snyk will now continuously monitor each of those functions for known vulnerabilities. You can add more functions at any time.

Note: for Node.js and .Net, dev dependencies will be ignored.

Enable integration between your deployed AWS Lambda resources and a Snyk organization, and start managing the security of your deployed code.

Configure the integration with these two parts:

Enable permissions from your AWS account

Configure the integration from your Snyk account

Prerequisites:

You must be the owner or an administrator of the Snyk account youre integrating.

How it works

The user creates a policy-based role, called a Role ARN, in the format arn:aws:iam::<account-id>:role/<newRole>. The role enables read-only access to the users Lambda services. The user configures Snyk for integration with AWS Lambda using the credentials for the role they created.

The user requests to import functions to Snyk (for testing and monitoring).

Snyk evaluates the selected functions and imports them.

Snyk communicates directly with Lambda for each test it runs to determine exactly what code is currently deployed and what dependencies are being used. Each dependency is tested against Snyks vulnerability database to see if it contains any known vulnerabilities.

Based on your configurations, if vulnerabilities are found, Snyk notifies you via email or Slack so that you can take immediate remediation action.

Supported repos and languages

Snyk currently supports integration with AWS Lambda for Node, Ruby and Java projects.

Configure your integration with Snyk

Allow a few minutes for AWS to update the role on their servers.

From AWS, copy the Role ARN key that appears at the top of the Summary section (inside the Role area still; in the format arn:aws:iam::<account-id>:role/<newRole>).

Save this value to paste in Snyk soon.

Now, log in to your Snyk account.

Navigate to Integrations from the menu bar at the top, find and click the AWS Lambda option:

The AWSLambda configuration page in the Settings area loads, with the External ID value automatically populated for you based on the Snyk organization that youre configuring.

Paste the Role ARN that you saved on the side into the ARN field.

Click Save.

Snyk tests the connection values and the page reloads, now displaying AWS Lambda integration details as you entered them. A confirmation message that the details were saved also appears in green at the top of the screen.

In addition, if the connection to AWS failed, notification appears under the Connected to AWS Lambda section accordingly.

Enable permissions

Enable permissions to access AWS Lambda for the first time by creating a new read-only policy-based role from the AWS Identity and Access Management (IAM) console and updating the policy directly from the associated JSON file as necessary.

The role delegates read-only access to all of your Lamda resources by Snyk per organization.

This section generally describes how to navigate the AWS IAM Console for these purposes. For more assistance, see the AWS documentation.

From your Snyk account, navigate to the organization youd like to integrate with, go to Settings and when the General Settings load for the group, scroll down and copy your Organization ID. Save this for use later in this process.

Now, click here to log in to the AWS Management Console, navigate to the Policies page, and create a new policy for the role by updating the related JSON file only, as follows:

From the Policies area of the AWS Management Console, create a new policy.

Navigate to the JSON tab.

Select and delete all of the default text in the JSON file.

Copy the following script and paste it inside the JSON file:

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"lambda:Get*",

"lambda:List*"

],

"Resource": "*"

}

]

}

Click Review policy.

Name the policy SnykReadOnlyForLambda.

Skip any other steps, finish the wizard and create the policy.

The policy is now available in the list of your existing policies.

Create a role by which to implement the policy:

Click here AWS Management Console, navigate to the Roles page and create a new role.

When the first step loads, select Another AWS account as the trusted entity and in the Account ID field, type 198361731867 (this is always Snyks unique ID in AWS).

Check Require External ID and in the External ID field that appears, enter the Organization ID that you copied and saved from your Snyk organization.

Click Next: permissions.

From the list that is displayed, select the SnykReadOnlyForLambda policy you just created.

Skip to the last step (Review) of the process.

Name the role SnykLambdaServiceRole and then finish creating it.

Add projects to Snyk

Add functions to your Snyk projects. Snyk then tests and monitors your AWS Lambda applications to identify vulnerabilities in your deployed code.

Prerequisites:

You must be added as a collaborator to the Snyk organization youd like to work with.

Steps:

Go to Projects, click Add projects and select AWS Lambda.

Note: If youcan'tsee that icon, click the+ option and then from the Integrations page, find and click the Lambda option.

Select the repositories and their relevant functions youd like to test and click Add selected repositories.

Snyk evaluates root folders and custom file locations. If no manifest files are found on the root level or in the paths you configure, Snyk notifies you that no files can be imported.

Once repositories are imported, a confirmation appears in green at the top of the screen.

Refresh the page to view the added functions.

AWS ECR images are indicated with a unique icon, they are grouped and named by repo, and you can now also filter to view only those projects:

AWS Lambda integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages in our docs.

Slack integration

Dont like email? You can set up Slack to receive Snyks alerts about new vulnerabilities that affect your projects, and about new upgrades or patches that have become available.

Youll get two alerts in Slack:

1: A newly disclosed vulnerability affects you

creating your own Slack app

2: A new upgrade or patch is available for a vulnerability that you previously ignored or patched

To set it up, you will need to generate a Slack webhook. You can either do this via the Incoming WebHooks app or by .

Once you have generated your Slack Webhook URL, go to your 'Manage organization settings, and enter the URL.

Set up your Jira integration

Our Jira integration allows you to raise issues for vulnerabilities or license issues in Snyk and is available to all our Pro and Enterprise customers. Our integration includes an API (see our API docs), and a way to manually raise a Jira issue in the UI (documented here).

Caution

if your Jira instance is private, you'll need to set up with Snyk Broker and then follow our brokered Jira setup instructions.

Prerequisites

Snyk requires that you're using Jira version 5 or above.

How to set up your Jira integration

To connect your Snyk account to your Jira account, go to the integrations page in your organization settings and type in your credentials. We recommend setting up a new user in Jira for this, rather than using existing credentials. You can authenticate by username and password, but we recommend authenticating by API token which you can generate from Atlassian API tokens.

Onceyou'veset up the connection, visit one of your Snyk projects. Youll now see a new button at the bottom of each vulnerability and license issue card that allows you to create a Jira issue.

When you click on this, a Jira issue creation form will appear with the Snyk issue details copied across into the relevant fields. You can review and edit this before creating the issue.

Select which Jira project youd like to send the issue to. The fields that we display below are based on the fields that project has, so switching between projects may show different options.

Onceyou'vecreated a Jira issue, the Jira key with a link will display on the issue card. If youre using the Jira API, you can generate multiple Jira issues for the same issue in Snyk.

You can also see which Jira issues have been created from the Issues view in your reports.

Nexus integration: overview

Install Snyk plugin directly on the Nexus instance to track open source vulnerabilities and license details in your artifacts based on your configurations.

Once installed, Snyk runs in the background and whenever a download is requested from the developer's CLI, Snyk automatically:

scans artifacts for licenses and for vulnerabilities and delivers remediation data for known vulnerabilities found in the artifact

blocks developers from downloading vulnerable packagesbased on Snyk results and your severity threshold configurations

By scanning artifacts as part of your work and then displaying those test results, the Snyk plugin enables developers transparency to the risks associated with their packages, and enables administrators to more quickly track and identify issues that risk your applications security and avoid using those artifacts in your organizations projects.

This plugin is available for Pro and Enterprise plans.

Supported languages and package managers

Snyk supports all languages that are supported by both Nexus and the Snyk CLI and API. See our docs for more information about the package managers and languages we support.

How it works

Use the Snyk capability with your Nexus Repository Manager to test your artifacts for vulnerabilities and license issues at installation of this plugin and also every time developers request to download any one of them.

The admin installs and updates the Snyk configurations on the Nexus instance from the Capabilities section, including the authentication token and organization ID from Snyk.

Snyk authenticates the account configuration using the API token and Organization ID that the admin entered, and then runs in the background continuously.

A developer attempts to download an artifact from the Nexus instance to their local environment.

Based on the severity thresholds configured for the Snyk Security Configuration capability, the package is blocked.

The error appears in the developers CLI (including a link to the error with full details) and from the Nexus interface for administrators, detailing the number of known issues for vulnerabilities and licenses.

Administrators guide for the Snyk Nexus plugin

Prerequisites

You must sign up for a Pro or Enterprise account with Snyk before you begin.

You must be an administrator or owner of the Snyk account.

You must have one of the following installed for your team first:

Nexus Repository Manager OSS

Nexus Repository Manager Pro v3.15.0 or greater

From the Nexus interface, enable the Snyk Security Configuration from the Capabilities area. For more information about this, see the Sonatype documentation.

Configure the capability

Go to your Snyk account to copy and save your personal API token or your service account token, and an Organization ID. Both a token and an organization ID are mandatory and must be configured in order for Snyk to authenticate your account. Because this plugin does not import any data to Snyk, you can use any of your organization IDs.

From your Nexus instance, navigate to the Capabilities section and select to edit the Snyk Security Configuration from the list.

Ensure Enable this capability is checked, and enter details for the remaining fields as follows:

Snyk API URL - enter the API endpoint if youre setting up on-prem or Broker for Snyk

Snyk API token - paste the token value you saved from step 1

Snyk Organization ID - paste the token value you saved from step 1

Vulnerability Thresholddefault is *low*. Valid values include low, medium, high. Manually update the configuration based on your needs.

License Thresholddefault is *low*. Valid values include low, medium, high. Manually update the configuration based on your needs.

Shut down the Nexus service instance and then restart it.

Log in to your Nexus instance and double-check that the Snyk bundle has been installed successfully.

Track vulnerabilities in your teams artifacts

Once installed, every time a developer requests to download an artifact, the following occurs:

Based on the severity thresholds that you configured, the download is blocked.

Scan results are displayed for the developer with a link to full details for the error:

Results are stored in the Snyk Security part of the Attributes section from the Nexus interface for the artifact:

By reviewing the results, you can evaluate the issues found in your artifact and determine a course of action.

Work with Snyk properties from Nexus as follows:

Property

Description

issues_licenses

Regardless of the thresholds configured, this row displays license summary scan results.

issues_url

This is the URL to our database and explanation of the vulnerability, including specific details about vulnerable versions, available upgrades and Snyk patches as well.

issues_vulnerabilities

Regardless of the thresholds configured, this row displays vulnerability summary scan results.

Troubleshooting

If your connection to Snyk is unsuccessful, try checking the following points or contact us at [email protected] (< [email protected] >):

Check Nexus logs for any related errors.

Ensureyou'veentered the API URL correctly for the configuration of the capability.

For on-prem and Broker configurations, ensure the Snyk service is running.

Use Snyk in your build

Snyk continuously runs in the background on the Nexus instance. Whenever any team member requests a download, Snyk automatically scans the artifact to evaluate vulnerabilities and license issues and blocks the request based on your administrators configurations.

When the scan ends, you get an error message if the download was blocked, with a link to the full details for the known vulnerabilities found in that artifact, similar to the following example:

Click the link to view details, itemizing the number of vulnerabilities found in the artifact, and their severities.

Snyk is short for 'So Now You Know'.

There isn't a simple answer as it depends on who you ask! Depending on who you speak with, it is pronounced in different ways.

Guy, our CEO and one of the founders, pronounces it the same as 'sneak'. There are others within the team that pronounce it like 'snick' - the noise a lock makes when it is shutting, as it makes you more secure.

We don't really mind whichever way you pronounce it, as long as you are finding and fixing your vulnerabilities!

Snyk integrates with Google Container Registry (GCR) so that you can import your projects, monitor your containers for vulnerabilities and remediate as you work. Snyk tests the projectsyou'veimported for any known security vulnerabilities found, testing at a frequency you control.

Note

For more details about how we scan, check out this article: How Snyk container security works.

Integration with GCR is available for all of our pricing plans.

To set up integration with GCR, follow these steps:

Enable permissions to access GCR

Configure integration for GCR

Snyk analyzes the image and returns vulnerability and remediation details directly from the CLI.

The output includes this information, in the following order:

List of vulnerabilitiessorted by severity and grouped by vulnerability, where each is detailed as follows:

A clear heading lineeach heading to a group of vulnerability details includes the severity and cites the vulnerable package and project dependency in which it is located

Infooffers a link to the full vulnerability description in our database, from which you can find more details and remediation advice for the vulnerability

Descriptionprovides the official common name of the vulnerability

Introduced throughdisplays the top-level package names affected by the vulnerability

Fromlists all full paths of the project in which the package is located

Introduced by your base image/ Introduced in your Dockerfile/ Introduced by the scratch imageindicates the base image, Dockerfile layer, or scratch image in which the package with the vulnerability originated. This feature is only available if you include your Dockerfile in the test (using the --file argument)

Fixed inwhen the package in which the vulnerability was found has been fixed by its maintainer, this line indicates from which version the vulnerability was removed

Project summary, including this information:

Organizationthe Snyk organization to which the project is associated; use environment variables when running snyk test to apply a specific organization. Otherwise, this is your default Snyk organization

Package managerassociated with this image

Docker imagethe image and version that was tested/scanned

Total dependencies with known vulnerabilities, and the total number of vulnerabilities

Scan summarydisplayed under the list of vulnerabilities, after running snyk test.

If you included your Dockerfile in the test, Snyk offers any available actionable remediation advice as follows:

analysis of the scratch image

the safest and best minor upgrade available

an option for a major upgrade which will reduce more vulnerabilities but with greater risk

viable alternative image options for replacing your current image with other, different images that provide the least amount of vulnerabilities possible.

Finally, if your base image is outdated, Snyk also recommends rebuilding your image.

Once you run snyk test at least once, run snyk monitor from the CLI. Alternatively, integrate with a container registry from the UI and select to import your projects to import and then monitor from the Snyk UI.

We then scan your project, testing for vulnerabilities, and import a snapshot of your projects.

From the Projects page, if the project is imported from a registry integration, then it is marked with the relevant registry icon; if it is imported from the CLI, then similarly it is marked with a CLI icon.

You can filter for all container projects, similar to the following example:

When you open any container project, the resulting analysis and remediation advice are displayed from the Snyk UI similar to the following:

The following information is displayed:

Project summary, displays general project details, including these unique details:

Image ID

Image tag

Base Image

Total dependencies with known vulnerabilities, and the total number of vulnerabilities

Remediation adviceif you included your Dockerfile for monitoring, then any available actionable remediation advice is displayed. To view all advice, click the Show more upgrade types link. The advice offered is dependent on available remediation, and appears similar to the following image:

Upgrade suggestions can include:

Minor upgradesthe safest and best minor upgrade available

Major upgradesan option for a major upgrade which will reduce more vulnerabilities but with greater risk

Alternative upgradesviable alternative image options for replacing your current base image with other, different base images that provide the least amount of vulnerabilities possible.

If your base image is outdated, Snyk also recommends rebuilding your image.

Upgrade recommendations include these details:

the name of the recommended base image version

the number of vulnerabilities existent in the recommended upgrade

a summary of the vulnerability severities accordingly.

Filtersin addition to the other filters available for all supported project types, when you view a container project, you can also filter by a specific binary or by OS packages (for binaries/packages containing issues)

Note

If there is only one category of issue in your container, such as Node binary vulnerabilities only or OS packages only, this filter does not appear.

Issues tabList of vulnerabilities, including origins, paths, and an overview of the vulnerability

Dependencies taba tree view of package hierarchy inside the image

Snyk tests and monitors ACR container images by evaluating root folders and custom file locations.

To add registry images to Snyk:

Prerequisites:

You must have an account with Snyk and be onboarded to your organization by an admin.

The integration must be configured between Snyk and your ACR repository.

Steps:

Log in to your account and navigate to the organization that you want to use for scanning your images.

Adding your Dockerfile and test your base image

Go to Projects, and click Add projects. The list of integrations already configured on your account opens, similar to the following:

The Which images do you want to test? view appears, displaying all of the available images for the registry to which you connected, grouped by each of your repositories, similar to the following:

Select single or multiple images with any or all of the following methods:

Type the name of a single image for import in the Image Name field (#1 in the image above),

Select any of the repositories if you want to import all of the associated images (#2 in the image above).

Expand and collapse repositories to select multiple images (#3 in the image above) across multiple repositories.

Click Add selected repositories.

A status bar appears at the top of the page as the images are imported; you can continue working in the meantime.

When the import ends, notification of success, or failure, appears at the top of the page. Click Refresh to view the Projects page with the newly imported images. Images are grouped by repository and are each linked individually to a detailed Projects page.

You can now connect your Git repo to this project in order to use your Dockerfile for enriched remediation advice. For more info, see .

ACR files are indicated with a unique icon . You can now also filter to view only those projects:

ACR integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages, also in our docs.

Enable integration between an ACR registry and a Snyk organization, and start managing your vulnerabilities. To integrate with multiple registries, create a unique organization for each one.

Steps:

Access your ACR account and retrieve unique service principal credentials for use by Snyk with the AcrPull role. For help doing this, see the ACR documentation.

Log in to your Snyk account.

Navigate to Integrations from the menu bar at the top, find and click the ACR option:

The ACR configuration page in the Settings area loads:

Enter the user name, password and container registry name (myregistry.azurecr.io) that you received when you generated a service principal for this integration.

Click Save.

Snyk tests the connection values and the page reloads, now displaying ACR integration information. A confirmation message that the details were saved also appears in green at the top of the screen. In addition, if the connection to Azure failed, notification appears under the Connected to ACR section.

Enable integration between one Artifactory as a container registry and a Snyk organization, and start managing your image security.

Log in to your Snyk account.

Navigate to Integrations from the menu bar at the top, find and click the Artifactory option:

The configuration page in the Settings area loads.

Enter credentials as follows:

Username and Passworduse your Artifactory login credentials.

Container registry name - the full URL for the registry youd like to integrate with.

Click Saved.

Snyk tests the connection values and the page reloads, now displaying integration details as you entered them. A confirmation message that the details were saved also appears in green at the top of the screen. In addition, if the connection failed, a notification appears.

Snyk tests and monitors your Artifactory container images by evaluating its tags in your repositories.

To add images to Snyk:

Prerequisites:

You must have an account with Snyk and be onboarded to your organization by an admin.

The integration must be configured between Snyk and your Artifactory environment.

Steps:

Log in to your account and navigate to the organization that you want to use for scanning your images.

Adding your Dockerfile and test your base image

Go to Projects, and click Add projects. The list of integrations already configured on your account opens, similar to the following:

The Which images do you want to test? view appears, displaying all of the available images for the registry to which you connected, grouped by each of your repositories, similar to the following:

Select single or multiple images with any or all of the following methods:

Type the name of a single image for import in the Image Name field (#1 in the image above),

Select any of the repositories if you want to import all of the associated images (#2 in the image above).

Expand and collapse repositories to select multiple images (#3 in the image above) across multiple repositories.

Click Add selected repositories.

A status bar appears at the top of the page as the images are imported; you can continue working in the meantime.

When the import ends, notification of success, or failure, appears at the top of the page. Click Refresh to view the Projects page with the newly imported images. Images are grouped by repository and are each linked individually to a detailed Projects page.

You can now connect your Git repo to this project in order to use your Dockerfile for enriched remediation advice. For more info, see .

Images are indicated with a unique icon, and you can also filter to view only the Artifactory projects:

Artifactory integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages in our docs.

Enable integration between Docker Hub and Snyk, and start managing your vulnerabilities.

From the Snyk UI, log in to your account and navigate to Integrations from the menu bar at the top.

From the Integrations page under the Docker Hub logo, click the Connect to Docker Hub button:

From the Settings page in the Integrations area, enter your Docker Hub username and password and then click Save:

Snyk tests the connection values and the page reloads, now displaying Docker Hub integration information and the Add your Docker Hub images to Snyk button.

A confirmation message that the details were saved also appears in green at the top of the screen. In addition, if the connection to Docker Hub failed, a notification appears.

Snyk tests and monitors Docker Hub repositories and images by evaluating root folders.

To add repositories to Snyk:

Prerequisites:

You must have an account with Snyk and be onboarded to your organization by an admin.

Ensure the integration with Docker Hub and Snyk has already been configured.

Steps:

Log in to your account and navigate to the organization that you want to use for scanning your images.

Adding your Dockerfile and test your base image

Go to Projects, and click Add projects. The list of integrations already configured on your account opens, similar to the following:

The Which images do you want to test? view appears, displaying all of the available images for the registry to which you connected, grouped by each of your repositories, similar to the following:

Select single or multiple images with any or all of the following methods:

Type the name of a single image for import in the Image Name field (#1 in the image above),

Select any of the repositories if you want to import all of the associated images (#2 in the image above).

Expand and collapse repositories to select multiple images (#3 in the image above) across multiple repositories.

Click Add selected repositories.

A status bar appears at the top of the page as the images are imported; you can continue working in the meantime.

When the import ends, notification of success, or failure, appears at the top of the page. Click Refresh to view the Projects page with the newly imported images. Images are grouped by repository and are each linked individually to a detailed Projects page.

You can now connect your Git repo to this project in order to use your Dockerfile for enriched remediation advice. For more info, see .

You can now also filter to view only those projects:

Once repositories and images are imported, a confirmation appears in green at the top of the screen. Docker Hub files are indicated with a unique icon .

Docker Hub integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages in our docs.

Click here to log in to the AWS Management Console, navigate to the IAM service and then to the Policies page to create a policy for the role by updating the related JSON file only, as follows:

Create a new policy.

Navigate to the JSON tab.

Select and delete all of the default text in the JSON file.

Copy script as it is displayed from the UI in your Snyk account and paste it inside the JSON file:

AWS Management Console

Set AmazonEC2ContainerRegistryReadOnlyForSnyk as the Name.

Enter Provides Snyk with read-only access to Amazon EC2 Container Registry repositories as the Description.

Click Create Policy.

Create a role by which to implement the policy:

From the again, navigate to the Roles page and create a new role.

Select AWS service as the trusted entity and EC2 as the service for this role.

Click Next: permissions.

From the Policies list that is displayed, search for and select the AmazonEC2ContainerRegistryReadOnlyForSnyk policy you just created.

Skip to the last step (Review) of the process.

Name the role SnykServiceRole, enter Allows EC2 instances to call Snyk AWS services on your behalf as the Description and then Create role.

Harden the usability scope for the role:

Again from the Roles page, find and click the link for the role you just created to update its configurations and navigate to the Trust relationships tab.

Click Edit trust relationship.

In the Policy Document, select and delete the entire script and then copy the following script as it is displayed from the UI in your Snyk account and paste:

Once you create or update an IAM role, allow a few minutes for AWS to update the role on their servers before continuing.

From AWS, copy the Role ARN key that appears at the top of the Summary section (inside the Role area still).

Now, log in to your Snyk account.

Navigate to Integrations from the menu bar at the top, find and click the ECR option:

The ECR configuration page in the Settings area loads.

Enter credentials as follows:

AWS Regionuse the format region-part-#. For example eu-west-3. You must enter the default region as configured for your AWS account in order for your repositories and images to be available for import.

Role ARNcopy from your AWS account, in the format arn:aws:iam::<account-id>:role/<newRole>.

For example:

arn:aws:iam::881001789406:role/TestSnykIntegration_role

Click Save.

Snyk tests the connection values and the page reloads, now displaying AWS ECR integration details as you entered them. A confirmation message that the details were saved also appears in green at the top of the screen.

In addition, if the connection to AWS failed, notification appears under the Connected to AWS ECR section.

Snyk tests and monitors your AWS ECR container images by evaluating its tags as they are in your ECR repositories.

To add images to Snyk:

Prerequisites:

You must have an account with Snyk and be onboarded to your organization by an admin.

Ensure you've configured the integration between Snyk and your ECR repository.

Steps:

Log in to your account and navigate to the organization that you want to use for scanning your images.

Adding your Dockerfile and test your base image

Go to Projects, and click Add projects. The list of integrations already configured on your account opens, similar to the following:

The Which images do you want to test? view appears, displaying all of the available images for the registry to which you connected, grouped by each of your repositories, similar to the following:

Select single or multiple images with any or all of the following methods:

Type the name of a single image for import in the Image Name field (#1 in the image above),

Select any of the repositories if you want to import all of the associated images (#2 in the image above).

Expand and collapse repositories to select multiple images (#3 in the image above) across multiple repositories.

Click Add selected repositories.

A status bar appears at the top of the page as the images are imported; you can continue working in the meantime.

When the import ends, notification of success, or failure, appears at the top of the page. Click Refresh to view the Projects page with the newly imported images. Images are grouped by repository and are each linked individually to a detailed Projects page.

You can now connect your Git repo to this project in order to use your Dockerfile for enriched remediation advice. For more info, see .

ECR files are indicated with a unique icon,

You can now filter to view only those projects:

AWS ECR integration works similar to our other integrations. To continue to monitor, remediate and manage your projects, see the relevant pages, also in our docs.

Prerequisites:

Enable the Cloud Resources Manager API for the Google account you plan on integrating with Snyk.

From the relevant project in Google, ensure the you've created a service account for this Snyk integration.

Steps:

Go to the Google Cloud Platform Console Credentials page, select the project that you want to integrate with, and then select to set up a new service account key.

From the view that loads, choose the service account from the dropdown list that you created for this integration, and configure a new key for that account with these values:

Service account name - assign a unique name for the account in order to remember its uses later on.

Role - Project->Viewer

Service account ID - leave empty

Key type - JSON

Click Create.

The key is generated for your project.

Copy the entire contents of the JSON file, which appears similar to the following:

Configure integration for GCR

Save the data you copied in order to paste it when configuring the integration with Snyk.

Next steps:

Now, configure the integration: .

Configure integration from Snyk with your Google container registries to scan for vulnerabilities and fix security and license issues accordingly.

Prerequisites:

Set up a new service account key from your GCR account.

Steps:

Navigate to your Snyk organization, and go to Integrations=>GCR.

From the GCR hostname, enter the registry storage region for the images you want to scan in the format region.gcr.io. For example: gcr.io or asia.gcr.io.

Paste the entire contents of the JSON key file you created from Google into the JSON key file field in your Snyk account, like the following:

Click Save.

Snyk checks the credentials and when successful, the page reloads with a notification that the connection succeeded.

Once an administrator for your Snyk account has installed the Snyk controller on your Kubernetes cluster, collaborators can add new Kubernetes projects to Snyk for testing and monitoring.

Prerequisites

You must have an account with Snyk and be onboarded to your organization by an admin.

The integration must be configured between Snyk and your Kubernetes environment.

Steps

Go to the Projects page, click Add project and select the Kubernetes option.

The import screen loads, similar to the one below, displaying all namespaces from the Kubernetes environment on the left and relevant namespace workloads on the right:

Select one or multiple namespaces from the left side and for each namespace, select one or multiple workloads to import from the right side.

When ready, click Add selected workloads from the top right of the screen. When the import completes, the Projects page loads and all workloads thatyou'veimported appear, with a unique Kubernetes icon

Each item is named according to its Kubernetes metadata as follows: <namespace>/<kind>/<name>.

You can filter for Kubernetes projects only:

All workloads that you and your team have imported for monitoring appear on your Projects page marked with a unique Kubernetes icon .

To view and work with the workload test results:

Go to the Projects page and filter for Kubernetes projects only:

Expand any item to view:

a list of the individual images used in the workload

a summary of the number of vulnerabilities in each image

To view vulnerabilities in detail for any image, including its history, click the image name. The Project details page loads for the selected image similar to the following example:

To view an aggregate list of the vulnerabilities in all of the images in the workload, along with details about the security posture of the workload configuration, click the workload link. The Project details page loads for the selected image similar to the following example: Currently, we test the workload configuration for the following properties:

Snyk parameter

Associated Kubernetes parameters

Description

CPU and Memory limits

Resources.limits.memory

resources.limits.cpu

Limiting the expected CPU and Memory available to the container has operational as well as security benefits. In the context of security, this is about limiting the impact of potential denial of service attacks to affecting the app rather than the node and potentially the whole cluster.

runAsNonRoot

securityContext.runAsNonRoot

By default, containers can run as the root user. This property prevents that at the container runtime, meaning an attacker would only have limited permissions if they were to be able to execute a command in the context of the container.

readOnlyRootFilesystem

securityContext.readOnlyFilesystem

By default the file system mounted for the container is writable. That means an attacker who compromises the container can also write to the disk, which makes certain kinds of attacks easier. If your containers are stateless then youdon'tneed a writable filesystem.

Capabilities

securityContext.capabilities

At a low-level, Linux capabilities control what different processes in the container are allowed to do: from being able to write to the disk, to being able to communicate over the network. Dropping all capabilities and adding in those that are required is possible but requires understanding the list of capabilities first.

If you want to disable the Kubernetes integration first uninstall the controller from your cluster. You can use Helm to do so, or if youre not using helm simply remove the snyk-monitor namespace. With Helm you need to determine the release name, for instance:

$ helm ls --short

snyk-monitor

With that, you can delete the release.

$ helm delete snyk-monitor

With the controller removed, within the Integration Settings in Snyk you can hit the Disconnect button which will invalidate the credentials used to import and synchronise new workloads.

To receive base image remediation advice, including major, minor and alternative upgrades as well as advice when you need to rebuild your image, integrate with your preferred Git repository and import the repo that contains the relevant Dockerfile.

You can add a single Dockerfile to each image that you've imported.

To add your Dockerfile for additional remediation advice:

Prerequisites:

Ensure the relevant Git repository has been configured.

Import the relevant image from its registry first.

Steps:

From the Project tab, filter for your project and then click the settings cog to access the settings to add a Dockerfile:

From the Project settings page, click Configure Dockerfile and then select the relevant Git:

The Add Projects view appears, displaying all repositories from the Git account with which you integrated, grouped per organization and personal account:

Checkmark the relevant repo from which to import the Dockerfile.

Step 2 loads:

Enter the relative path in the Path to your Dockerfile field in the following format: /path/dockerfile.

Click Save.

Snyk tests the project again, this time producing any relevant base image remediation advice such as in the following example:

You can also use snyk test to scrutinize a public package before installing it, to see if it has known vulnerabilities or not. Using the package name will test the latest version of that package, and you can also provide a specific version or range using snyk test module[@semver-range].

snyk test [email protected]

Use our Snyk CLI tool to find and fix known vulnerabilities in your dependencies, both ad hoc and as part of your CI (Build) system.

The Snyk CLI requires you to authenticate with your account before using it.

Install the Snyk CLI using one of the following options:

npm module

Docker container

Homebrew

Supported languages and package managers:

Node.js, Ruby, Python, Java, Scala, Go, PHP and .NET.

Install Snyk CLI with npm

Install our Snyk CLI tool using npm.

Prerequisites:

Ensure you've installed npm on your local environment, version 6 or greater.

To run Snyk on Alpine Linux, first install libstdc++. See this doc for more help.

Steps:

Run these commands to install it for local use:

npm install -g snyk

Once installed, you need to authenticate with your Snyk account:

snyk auth

To test your installation change directory into a folder containing a supported package manifest file (package.json, pom.xml, composer.lock, etc.) and run:

cd /my/project/

syk test

Alternatively, you can perform a quick test on a public npm package, for instance:

snyk test ionic

As you can see, Snyk found and reported several vulnerabilities in the package. For each issue found, Snyk provides the severity of the issue, a link to a detailed description, the path through which the vulnerable module got into your system, and guidance on how to fix the problem.

Install our CLI tool with a container

You can use a Snyk created Docker container already containing npm, the Snyk CLI and other necessary components. Follow the detailed instructions here https://hub.docker.com/r/snyk/snyk-cli

Example output

$ snyk test

High severity vulnerability found on [email protected]

- desc: Regular Expression Denial of Service

- info: https://snyk.io/vuln/npm:minimatch:20160620

- from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]

Remediation:

Upgrade direct dependency [email protected] to [email protected] (triggers upgrades to [email protected] > [email protected] > [email protected] > [email protected])

Medium severity vulnerability found on [email protected]

- desc: Regular Expression Denial of Service

- info: https://snyk.io/vuln/npm:moment:20161019

- from: [email protected] > [email protected]

Remediation:

Upgrade direct dependency [email protected] to [email protected]

Medium severity vulnerability found on [email protected]

- desc: Root Path Disclosure

- info: https://snyk.io/vuln/npm:send:20151103

- from: [email protected] > [email protected] > [email protected]

Remediation:

Upgrade direct dependency [email protected] to [email protected] (triggers upgrades to [email protected])

Install Snyk CLI with Homebrew

From MAC OSx environments, you can use Homebrew to install our Snyk CLI tool.

Prerequisites:

Supported for MAC OSx environments only.

Ensure Homebrew has already been installed.

Steps:

Install the Snyk tap to provide access to software via Homebrew:

brew tap snyk/tap

Install Snyk as follows:

brew install snyk

After running snyk test you will presented with a list of vulnerabilities, including the severity, a description of the issue and a link where you can learn more about the specific vulnerability issue. Depending on the language of the project you have tested you may also see remediation advice providing details on how you can manually fix the vulnerability.

If you are testing a node.js or yarn project you can also use snyk wizard to fix your project.

While testing/importing a Docker Image you might have seen an error Failed to detect OS release One of the many reasons for this Scan Error might be because you have a Scratch based Container Image.We have a known limitation for Scratch based container images and will be fixed as soon as possible.As a workaround, we would suggest you to use the CLI to import/test these docker images. You can refer to these documents here to run aSnyk test inthe CLI and via thesnyk monitor command which you can monitor on your SCM/UI. This is the only workaround that we have as far asScratch based imagesare concerned For more information on Docker based Scratch images you can also refer to this article For any other reasons please do reach out to [email protected]