Snyk's Gitlab integration supports Gitlab versions 9.5 and above (API v4).
On-premise Gitlab integrations are available for customers on Enterprise plans and above. See pricing plans for more details.
This integration only works with GitLab instances that are publicly reachable (not on a private network). A Snyk Broker environment is required for private network instances.
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.
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.