Snyk's Gitlab integration supports Gitlab versions 9.5 and above (API v4).
Here's what you need to know to get started with your GitLab integration.
You can add your Node.js, Ruby, Python, Scala and Java GitLab projects and quickly test them, or decide which ones you’d 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 Snyk’s Broker first.
Generate a Personal Access Token in your GitLab. You’ll find this option in your user account settings area, in the “Access Tokens” section.
Go to Snyk’s 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.
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:
- Ensure that the Gitlab user that you've just generated the access token from, is either the owner of the projects (repos) you'd like to monitor with Snyk or has Maintainer permissions to them.
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 organization’s 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)
When viewing a Snyk test report for a project that you own, or when looking at a project that you are watching with Snyk, you’ll see two options for fixing a vulnerability:
Open a fix Merge Request: generate a Snyk merge request with the minimal changes needed to fix the vulnerabilities affecting the project.
Fix this vulnerability: 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 that can’t be fixed right now before opening the merge request on the Open a fix Merge Request page.
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.
Here’s an example for the merge request:
Whenever a vulnerability is disclosed that affects a project you’re watching, Snyk will not only email you about it, but also generate a Snyk merge request that addresses the vulnerabilities. You’ll receive a merge request similar to the example above.
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.