DEV Community

Rahul Singh
Rahul Singh

Posted on • Originally published at aicodereview.cc

Snyk GitLab Integration: Complete Setup Guide for 2026

#codereview #ai #programming #webdev

Why integrate Snyk with GitLab

GitLab teams need security scanning that works natively with merge requests, CI pipelines, and the GitLab workflow. Snyk provides exactly that - a developer-first security platform that plugs into GitLab at multiple levels to catch vulnerabilities before they reach production.

The Snyk GitLab integration operates on two tracks. First, the dashboard-level integration connects Snyk directly to your GitLab instance, enabling automatic project imports, merge request checks, and recurring vulnerability scans without touching your CI configuration. Second, the CLI-based integration runs inside your GitLab CI pipelines, giving you full control over when and how scans execute as part of your build process.

Together, these two integration methods cover the full spectrum of security scanning - open-source dependency analysis (SCA), static application security testing (SAST) via Snyk Code, container image scanning, and infrastructure as code analysis. Whether you are running GitLab.com or a self-managed GitLab instance, this guide walks through every step of the snyk gitlab setup from creating your personal access token to configuring automated MR checks and CI pipeline jobs.

If you have not installed or configured Snyk yet, start with our Snyk code review guide for an overview of the platform's capabilities, or the Snyk CI/CD guide if you want a broader look at CI integration across multiple platforms.

Snyk screenshot

Prerequisites

Before starting the snyk gitlab configuration, make sure you have the following in place:

  • A Snyk account - sign up free at app.snyk.io. See our Snyk pricing breakdown for plan details
  • A GitLab account with Maintainer or Owner access to the projects you want to scan
  • GitLab personal access token with the api scope (creation steps are covered below)
  • Node.js 18 or later installed if you plan to use the Snyk CLI in GitLab CI pipelines
  • Docker installed if you plan to scan container images

For self-managed GitLab instances, you will also need a Snyk Enterprise plan and access to deploy the Snyk Broker in your network.

Step 1: Create a GitLab personal access token

The Snyk GitLab integration authenticates using a GitLab personal access token (PAT). This token gives Snyk the permissions it needs to read your repositories, create webhooks for MR scanning, and open fix merge requests.

Creating the token on GitLab.com

  1. Log in to gitlab.com and click your avatar in the top-right corner
  2. Select Edit profile
  3. In the left sidebar, click Access Tokens
  4. Click Add new token
  5. Fill in the token details:
    • Token name: snyk-integration (or any descriptive name)
    • Expiration date: set this to a reasonable future date. Snyk will stop working when the token expires, so set a reminder to rotate it
    • Select scopes: check api (required) and read_user (recommended)
  6. Click Create personal access token
  7. Copy the token immediately - GitLab only shows it once

Using a group access token instead

For teams that do not want the integration tied to a specific user account, GitLab Premium and Ultimate plans support group access tokens:

  1. Navigate to your GitLab group
  2. Go to Settings > Access Tokens
  3. Create a token with the api scope and Maintainer role
  4. Use this group token in Snyk instead of a personal token

Group access tokens are more resilient because they survive user account changes. If the person who created a personal access token leaves the team, the integration breaks. Group tokens avoid this single point of failure.

Token security best practices

  • Store the token securely - do not paste it into chat messages, documents, or code repositories
  • Set an expiration date and create a calendar reminder to rotate the token before it expires
  • Use the minimum required scope - api is necessary for full functionality, but avoid adding unnecessary scopes
  • For CI/CD usage, store the Snyk API token (not the GitLab PAT) as a masked CI/CD variable in GitLab

Step 2: Connect GitLab to Snyk

With your personal access token ready, you can now establish the connection between GitLab and Snyk.

  1. Log in to app.snyk.io
  2. Navigate to Integrations in the left sidebar
  3. Select GitLab from the list of available integrations
  4. Enter your GitLab personal access token in the token field
  5. For GitLab.com, leave the URL field as the default (https://gitlab.com). For self-managed GitLab, enter your instance URL (for example, https://gitlab.yourcompany.com)
  6. Click Save to validate and connect

Snyk tests the token by making an API call to GitLab. If the connection succeeds, you will see a confirmation message and the integration status changes to "Connected." If it fails, verify that the token has the api scope and has not expired.

Self-managed GitLab setup with Snyk Broker

For self-managed GitLab instances that are not accessible from the public internet, you need to deploy the Snyk Broker. The Broker acts as a secure proxy between your private GitLab server and Snyk's cloud platform.

Deploy the Broker as a Docker container inside your network:

docker run -d \
  --name snyk-broker-gitlab \
  -p 8000:8000 \
  -e BROKER_TOKEN=your-broker-token \
  -e GITLAB_TOKEN=your-gitlab-pat \
  -e GITLAB=gitlab.yourcompany.com \
  -e PORT=8000 \
  -e BROKER_CLIENT_URL=http://broker-host:8000 \
  snyk/broker:gitlab
Enter fullscreen mode Exit fullscreen mode

The Broker establishes an outbound connection to Snyk (no inbound firewall rules needed) and relays API requests between Snyk's cloud and your GitLab server. All code cloned during scans passes through the Broker and is never stored by Snyk.

Step 3: Import GitLab projects

After connecting GitLab, import the repositories you want Snyk to scan.

  1. Click Add projects in the Snyk dashboard
  2. Select GitLab as the integration source
  3. Snyk displays all projects accessible with your token, organized by GitLab group
  4. Check the repositories you want to import - you can select individual projects or entire groups
  5. Click Add selected repositories

Snyk runs an initial scan on each imported project. It automatically detects manifest files - package.json, requirements.txt, pom.xml, Gemfile, go.mod, Dockerfile, Terraform files, and others - and creates a separate Snyk project for each one. A single GitLab repository with both a package.json and a Dockerfile results in two Snyk projects.

What happens during the initial scan

During the initial import, Snyk:

  • Clones the repository temporarily (the code is not stored permanently)
  • Identifies all supported manifest files and configuration files
  • Resolves the full dependency tree for each manifest
  • Checks every direct and transitive dependency against Snyk's vulnerability database
  • Runs Snyk Code SAST analysis if enabled in your organization settings
  • Creates a baseline snapshot for ongoing monitoring

The initial scan results appear in your Snyk dashboard within a few minutes. From here, you can view vulnerability details, severity ratings, exploit maturity, and available fix paths for each finding.

Configuring project settings

After import, configure how Snyk handles each project:

  • Test frequency - set how often Snyk re-scans the project (daily, weekly, or never for CI-only scanning)
  • Branch - select which branch Snyk monitors (defaults to the repository's default branch)
  • Snyk Code - enable or disable SAST scanning for this project

Step 4: Configure merge request checks

Snyk MR checks scan every merge request for security issues before it can be merged. This is one of the most valuable features of the snyk gitlab integration because it catches vulnerabilities at the point where they can still be blocked from entering your codebase.

Enabling MR checks

  1. In the Snyk dashboard, go to Settings
  2. Select GitLab under Integrations
  3. Under Default Snyk test for pull requests, toggle it to Enabled
  4. Configure the fail conditions:
    • Only fail when the MR is adding a dependency with issues - recommended for most teams. This prevents existing vulnerabilities from blocking new work
    • Fail if the repo has any issues - stricter option that blocks MRs until all existing vulnerabilities are resolved

How MR checks work

When a developer opens a merge request against a monitored branch, Snyk automatically:

  1. Receives a webhook notification from GitLab
  2. Clones the MR branch and runs a dependency scan
  3. Compares the results against the target branch to identify newly introduced vulnerabilities
  4. Reports the results back to GitLab as a pipeline status check
  5. The MR shows a pass (green check) or fail (red X) next to the Snyk check

Combining with GitLab merge request approval rules

To enforce that MRs cannot be merged when Snyk checks fail:

  1. Go to your GitLab project Settings > Merge requests
  2. Under Merge checks, enable Pipelines must succeed
  3. This ensures the Snyk status check must pass before the merge button becomes available

You can also configure specific approval rules that require security team review when Snyk detects high or critical severity findings, adding a human review step on top of the automated scanning.

Automatic fix merge requests

Snyk can automatically create merge requests that upgrade vulnerable dependencies:

  1. In the Snyk GitLab integration settings, enable Automatic fix pull requests
  2. Set the maximum number of open fix MRs per project (default is 5)
  3. Choose whether to create fix MRs for new vulnerabilities only, or also for vulnerabilities discovered in recurring scans

Fix MRs include a detailed description of the vulnerability, the version upgrade path, release notes for the new version, and any known breaking changes. They are designed to be reviewed and merged quickly without requiring the developer to manually research the upgrade.

Step 5: Configure the .snyk policy file

The .snyk policy file gives you project-level control over how Snyk handles vulnerabilities. Both the dashboard integration and the CLI respect this file, making it the single source of truth for vulnerability exceptions across all scanning methods.

Creating the .snyk file

Use the Snyk CLI to create ignore entries:

snyk ignore --id=SNYK-JS-LODASH-1018905 \
  --expiry=2026-06-13 \
  --reason="Function _.template is not used in our codebase"
Enter fullscreen mode Exit fullscreen mode

This generates a .snyk file in your project root:

# Snyk (https://snyk.io) policy file
version: v1.25.0
ignore:
  SNYK-JS-LODASH-1018905:
    - '*':
        reason: Function _.template is not used in our codebase
        expires: 2026-06-13T00:00:00.000Z
        created: 2026-03-13T00:00:00.000Z
Enter fullscreen mode Exit fullscreen mode

Path-specific ignores

You can scope ignores to specific paths - useful for test dependencies or vendored code:

version: v1.25.0
ignore:
  SNYK-JS-EXAMPLE-12345:
    - 'test/*':
        reason: Test dependencies are not shipped to production
        expires: 2026-09-13T00:00:00.000Z
Enter fullscreen mode Exit fullscreen mode

Best practices for the .snyk file in GitLab workflows

  • Commit the .snyk file to your GitLab repository so every team member and CI pipeline uses the same policy
  • Require MR approval for .snyk changes - add a CODEOWNERS rule that requires security team review when the .snyk file is modified
  • Set expiration dates on all ignores - a 90-day window forces periodic review and prevents permanent blind spots
  • Include clear, specific reasons - "not exploitable" is insufficient. Explain why it is not exploitable in your context
  • Review the .snyk file as part of regular security audits - expired ignores may indicate vulnerabilities that need re-evaluation

The .snyk policy file works the same way whether Snyk scans your project through the GitLab dashboard integration or through the CLI in a GitLab CI pipeline. This consistency means you maintain a single set of policies regardless of how the scan is triggered.

Step 6: Set up Snyk in GitLab CI

Running Snyk directly in your GitLab CI pipeline gives you full control over the scanning process - when it runs, which products to use, severity thresholds, and how results are reported. This is the snyk gitlab ci integration that most teams rely on for gated security checks.

Basic .gitlab-ci.yml configuration

Add a security scanning stage to your pipeline:

stages:
  - build
  - test
  - security
  - deploy

snyk-dependency-scan:
  stage: security
  image: node:20-alpine
  before_script:
    - npm install -g snyk
  script:
    - snyk auth $SNYK_TOKEN
    - snyk test --severity-threshold=high
  allow_failure: false
  only:
    - merge_requests
    - main
Enter fullscreen mode Exit fullscreen mode

Setting up the SNYK_TOKEN variable

Before the pipeline can run, add your Snyk API token as a CI/CD variable:

  1. Go to your GitLab project Settings > CI/CD
  2. Expand the Variables section
  3. Click Add variable
  4. Set the key to SNYK_TOKEN
  5. Paste your Snyk API token as the value
  6. Check Mask variable to prevent the token from appearing in pipeline logs
  7. Optionally check Protect variable to restrict it to protected branches only

For group-level configuration, add the variable at Group Settings > CI/CD > Variables so all projects in the group share the same token.

Multi-product scanning pipeline

For comprehensive security coverage across all Snyk products in a single snyk gitlab pipeline:

stages:
  - build
  - test
  - security
  - deploy

variables:
  SNYK_IMAGE: "snyk/snyk-cli:npm"

snyk-open-source:
  stage: security
  image: $SNYK_IMAGE
  script:
    - snyk test --severity-threshold=high --json-file-output=snyk-os.json
  artifacts:
    paths:
      - snyk-os.json
    when: always
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

snyk-code:
  stage: security
  image: $SNYK_IMAGE
  script:
    - snyk code test --severity-threshold=high --json-file-output=snyk-code.json
  artifacts:
    paths:
      - snyk-code.json
    when: always
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

snyk-iac:
  stage: security
  image: $SNYK_IMAGE
  script:
    - snyk iac test --severity-threshold=medium --json-file-output=snyk-iac.json
  artifacts:
    paths:
      - snyk-iac.json
    when: always
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

snyk-monitor:
  stage: security
  image: $SNYK_IMAGE
  script:
    - snyk monitor
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Enter fullscreen mode Exit fullscreen mode

All three scanning jobs run in parallel within the security stage, so the total scan time is determined by the slowest individual scan rather than the sum of all three.

Using the Snyk Docker image

Instead of installing the CLI via npm in every job, you can use Snyk's official Docker image:

snyk-scan:
  stage: security
  image: snyk/snyk-cli:npm
  script:
    - snyk test --severity-threshold=high
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
Enter fullscreen mode Exit fullscreen mode

The snyk/snyk-cli:npm image comes with the Snyk CLI pre-installed and configured. It reads the SNYK_TOKEN environment variable automatically, so no explicit authentication step is needed.

Integrating with GitLab security dashboard

GitLab Ultimate users can display Snyk results in the GitLab security dashboard by converting the output to GitLab's security report format:

snyk-dependency-scan:
  stage: security
  image: snyk/snyk-cli:npm
  script:
    - snyk test --json-file-output=snyk-results.json || true
    - snyk-to-gl-dependency-report snyk-results.json > gl-dependency-scanning-report.json
  artifacts:
    reports:
      dependency_scanning: gl-dependency-scanning-report.json
Enter fullscreen mode Exit fullscreen mode

This surfaces Snyk findings directly in the merge request security widget, where reviewers can see new vulnerabilities introduced by the MR without leaving GitLab.

Step 7: Container scanning in GitLab CI with Snyk

Container scanning in GitLab CI requires building the image first, then scanning it with Snyk. This catches vulnerabilities in your base image OS packages and any application dependencies installed inside the container.

Basic container scanning job 

snyk-container:
  stage: security
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
    IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  before_script:
    - apk add --no-cache npm
    - npm install -g snyk
  script:
    - docker build -t $IMAGE_TAG .
    - snyk container test $IMAGE_TAG
      --file=Dockerfile
      --severity-threshold=high
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Enter fullscreen mode Exit fullscreen mode

Container monitoring after deployment

Add a separate job that runs only on the default branch to monitor the deployed image:

snyk-container-monitor:
  stage: deploy
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
    IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  before_script:
    - apk add --no-cache npm
    - npm install -g snyk
  script:
    - docker build -t $IMAGE_TAG .
    - snyk container monitor $IMAGE_TAG --file=Dockerfile
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Enter fullscreen mode Exit fullscreen mode

The snyk container monitor command uploads the image's dependency snapshot to the Snyk dashboard for continuous monitoring. Snyk checks the snapshot against newly disclosed vulnerabilities on a recurring schedule and sends alerts when new issues are found.

Scanning images from GitLab Container Registry

If your pipeline pushes images to GitLab's built-in container registry, you can scan them after the push:

snyk-registry-scan:
  stage: security
  image: snyk/snyk-cli:docker
  services:
    - docker:24-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - snyk container test $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      --severity-threshold=high
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Enter fullscreen mode Exit fullscreen mode

Troubleshooting common issues

Even with a straightforward setup, the snyk gitlab integration can hit a few common problems. Here is how to diagnose and fix each one.

Personal access token errors

Problem: Snyk returns "Unable to connect to GitLab" or "Invalid token" when you try to set up the integration.

Fix: Verify the token has not expired and has the correct scopes. Test the token directly against the GitLab API:

curl --header "PRIVATE-TOKEN: your-token-here" \
  "https://gitlab.com/api/v4/user"
Enter fullscreen mode Exit fullscreen mode

If this returns your user information, the token is valid. If it returns a 401 error, regenerate the token. Make sure you selected the api scope - read_api alone is insufficient for the full integration.

Projects not appearing in import list

Problem: After connecting GitLab, some or all projects do not appear when you click "Add projects" in Snyk.

Fix: The token owner must have at least Maintainer-level access to the projects. Guest, Reporter, and Developer roles do not have sufficient permissions for Snyk to access project configurations. Check your role in each GitLab project under Members. If you are using a group access token, verify it was created with the Maintainer role.

MR checks not triggering

Problem: Merge requests do not show Snyk status checks after enabling MR checks.

Fix: Snyk uses webhooks to receive notifications about new merge requests. Verify that the webhook was created by going to your GitLab project Settings > Webhooks and looking for a Snyk webhook URL. If the webhook is missing, disconnect and reconnect the GitLab integration in Snyk. Also confirm that the project is imported and monitored in the Snyk dashboard - MR checks only work for imported projects.

GitLab CI pipeline failing with authentication errors

Problem: The Snyk CLI returns "Missing API token" or "Authentication failed" in GitLab CI.

Fix: Verify the SNYK_TOKEN CI/CD variable is set correctly:

  1. Go to Settings > CI/CD > Variables in your GitLab project
  2. Confirm the variable name is exactly SNYK_TOKEN (case-sensitive)
  3. Check that the variable is not restricted to protected branches only (if your MR source branches are not protected)
  4. Verify the token value is a Snyk API token from app.snyk.io/account, not a GitLab personal access token - these are different tokens for different purposes

Scan results differ between dashboard and CI

Problem: The Snyk dashboard shows different vulnerability counts than the GitLab CI pipeline.

Fix: This typically happens when the dashboard and CI are scanning different branches, different lock file states, or using different Snyk organization settings. Ensure your CI pipeline runs on the same branch that the dashboard monitors. Commit your lock files (package-lock.json, yarn.lock, poetry.lock) to ensure consistent dependency resolution. Verify that the .snyk policy file is committed and present in both contexts.

Rate limiting on the free plan

Problem: Scans return "You have exceeded your test limit" before the billing period ends.

Fix: The free plan has strict test limits - 400 Open Source tests, 100 Code tests, 300 IaC tests, and 100 Container tests per period. Reduce consumption by configuring CI to run Snyk only on merge requests targeting the default branch, not on every push to every branch. Use the rules keyword in your .gitlab-ci.yml to restrict when Snyk jobs run. Consider upgrading to a paid plan at $25 per contributing developer per month for unlimited tests - see our Snyk pricing guide for details.

Dashboard integration vs. CI integration

You do not have to choose between the Snyk dashboard integration and GitLab CI - most teams use both. Each approach has distinct advantages, and they complement each other.

The dashboard integration provides:

  • Automatic project discovery and import
  • Recurring background scans that catch newly disclosed vulnerabilities
  • Automated fix merge requests
  • Centralized visibility across all GitLab projects
  • No changes to your .gitlab-ci.yml required

The GitLab CI integration provides:

  • Full control over scan timing, severity thresholds, and fail conditions
  • Consistent scanning as part of your existing pipeline stages
  • JSON and SARIF output for custom reporting
  • Integration with GitLab's security dashboard (Ultimate tier)
  • No dependency on Snyk's webhook delivery

The recommended approach is to use the dashboard integration for monitoring and fix MRs, and the CI integration for gated security checks on merge requests. This gives you both the automated monitoring and the enforcement that prevents vulnerable code from being merged.

Alternative: CodeAnt AI for GitLab

If you are evaluating options beyond Snyk for GitLab security scanning, CodeAnt AI is worth considering. CodeAnt AI provides AI-powered code review with native GitLab support, combining security analysis with code quality checks in a single tool.

CodeAnt AI is priced at $24 to $40 per user per month depending on the plan, which includes SAST scanning, code quality analysis, and AI-powered review comments on merge requests. Unlike Snyk, which focuses specifically on security vulnerabilities, CodeAnt AI covers both security and code quality in a single integration. It connects to GitLab natively without requiring a Broker for self-managed instances.

For teams that primarily need open-source dependency scanning and container security, Snyk remains the stronger choice. For teams that want combined security and code quality review in one tool with simpler pricing, CodeAnt AI offers a compelling alternative. See our Snyk alternatives roundup for a broader comparison of options.

Comparing Snyk GitLab integration with GitHub integration

Teams evaluating Snyk across multiple Git platforms should understand the differences between the GitLab and GitHub integrations. While the core scanning capabilities are identical, the integration mechanisms differ.

The Snyk GitHub integration uses a GitHub App with granular permissions and OAuth-based authentication. The GitLab integration uses a personal access token (or group access token) with API scope. Both support MR/PR checks, automatic fix MRs/PRs, and recurring scans.

Key differences:

  • Authentication - GitHub uses an OAuth App with granular permissions. GitLab uses a PAT with broad API scope
  • Self-managed support - both require Snyk Broker for on-premise instances
  • Fix MRs/PRs - both support automatic fix merge/pull requests with the same vulnerability information
  • CI integration - GitHub Actions uses official Snyk actions. GitLab CI uses the Snyk CLI or Docker image directly
  • Security dashboard - GitHub has the Security tab with SARIF support. GitLab has the security dashboard on Ultimate tier

The scanning engine, vulnerability database, and remediation guidance are identical regardless of which Git platform you use. Your choice of platform does not affect the quality of security findings.

Summary

Integrating Snyk with GitLab creates a multi-layered security scanning setup that catches vulnerabilities at every stage of your development workflow. Here is a checklist of everything covered in this guide:

  1. Create a GitLab personal access token with the api scope for Snyk authentication
  2. Connect GitLab to Snyk through the Integrations page in the Snyk dashboard
  3. Import GitLab projects and run initial scans to establish a vulnerability baseline
  4. Enable merge request checks so every MR is scanned before it can be merged
  5. Configure the .snyk policy file to manage exceptions with documented reasons and expiration dates
  6. Add Snyk to your GitLab CI pipeline for dependency, SAST, and IaC scanning
  7. Set up container scanning in GitLab CI with Docker-in-Docker for image vulnerability analysis
  8. Use snyk monitor on the default branch for continuous vulnerability tracking

The combination of dashboard-level monitoring and CI pipeline scanning gives you both automated oversight and enforceable security gates. Vulnerabilities are caught in merge requests before they enter the codebase, newly disclosed vulnerabilities are detected in recurring scans, and fix merge requests are created automatically to reduce the time between detection and remediation.

For teams outgrowing Snyk's free tier, paid plans start at $25 per contributing developer per month. If your needs extend beyond security into code quality review, CodeAnt AI ($24-40/user/month) provides native GitLab support with combined security and quality analysis in a single tool.

Further Reading

Frequently Asked Questions

How do I connect Snyk to GitLab?

Log in to app.snyk.io, navigate to Integrations in the sidebar, and select GitLab. Enter your GitLab personal access token with api and read_user scopes. Snyk validates the token and establishes the connection. Once connected, click Add Projects and select the GitLab repositories you want to scan. Snyk automatically detects manifest files in each repository and creates projects for dependency scanning, Snyk Code SAST, container image analysis, and IaC checks.

What GitLab personal access token scopes does Snyk require?

Snyk requires a GitLab personal access token with the api scope, which grants full read and write access to the GitLab API. The read_user scope is also recommended so Snyk can identify the token owner. For GitLab groups, you can use a group access token with the api scope instead, which avoids tying the integration to a specific user account. The token must belong to a user or group with at least Maintainer-level access to the projects you want to import.

Does Snyk support GitLab self-managed instances?

Yes, Snyk supports both GitLab.com (SaaS) and GitLab self-managed (on-premise) instances. For GitLab.com, enter your personal access token in the Snyk dashboard and you are connected. For self-managed GitLab, you need a Snyk Enterprise plan and must deploy a Snyk Broker to establish a secure connection between your private GitLab instance and Snyk's cloud platform. The Broker runs as a Docker container inside your network and handles all communication without exposing your GitLab server to the internet.

How do I enable Snyk merge request checks on GitLab?

After connecting GitLab and importing projects, go to Settings in your Snyk organization, select GitLab under Integrations, and enable 'Default Snyk test for pull requests.' Once enabled, Snyk runs a security scan on every merge request opened against your monitored repositories. The results appear as a pipeline status on the MR. Configure whether the check fails only when the MR introduces new vulnerabilities or when the repository has any existing issues.

How do I add Snyk to a GitLab CI pipeline?

Add a security scanning stage to your .gitlab-ci.yml file. Install the Snyk CLI using npm or use the snyk/snyk-cli Docker image as the job image. Set the SNYK_TOKEN as a CI/CD variable in your GitLab project or group settings. Run 'snyk test --severity-threshold=high' as the script command to scan dependencies. Add additional jobs for 'snyk code test' (SAST), 'snyk container test' (containers), and 'snyk iac test' (infrastructure as code) to cover all scanning dimensions.

Can Snyk create automatic fix merge requests on GitLab?

Yes, Snyk can automatically create merge requests that upgrade vulnerable dependencies on GitLab. Enable this in your Snyk organization settings under the GitLab integration by toggling 'Automatic fix pull requests.' Snyk creates MRs that upgrade dependencies to the nearest non-vulnerable version, including a detailed description of the vulnerability, the upgrade path, and breaking change warnings. You can configure the maximum number of open fix MRs per project to prevent MR overload.

How do I scan Docker containers with Snyk in GitLab CI?

Add a container scanning job to your .gitlab-ci.yml that builds the Docker image, then runs 'snyk container test your-image:tag --file=Dockerfile --severity-threshold=high'. You need Docker-in-Docker (dind) or Kaniko for building images in GitLab CI. Set the SNYK_TOKEN variable and install the Snyk CLI in your job. The --file=Dockerfile flag provides base image upgrade recommendations. For continuous monitoring, add 'snyk container monitor' after successful deployments on the default branch.

What is the .snyk policy file and how does it work with GitLab?

The .snyk file is a YAML policy file in your project root that controls how Snyk handles specific vulnerabilities. You can ignore findings that are not exploitable in your context, set expiration dates on exceptions, and document reasoning. Create ignore entries using 'snyk ignore --id=VULN-ID --reason=explanation --expiry=date'. Commit the .snyk file to your GitLab repository so the entire team shares the same policy. Both the Snyk dashboard integration and GitLab CI pipeline scans respect the .snyk policy file.

How often does Snyk scan my GitLab repositories?

Snyk scans GitLab repositories at three intervals. It runs an initial scan when you import a repository. It scans on every merge request if MR checks are enabled. It also performs recurring background scans - daily on paid plans and weekly on the free plan. You can adjust the recurring test frequency in your Snyk organization settings. Background scans check your monitored projects against newly disclosed vulnerabilities, alerting you even when no code changes have been made.

Is the Snyk GitLab integration available on the free plan?

Yes, the Snyk GitLab integration is available on all plans including the free tier. The free plan allows you to connect GitLab, import repositories, and enable MR checks. However, the free plan has test limits of 400 Open Source tests, 100 Code tests, 300 IaC tests, and 100 Container tests per billing period. Teams with multiple active repositories running CI on every merge request typically exhaust these limits within weeks. Paid plans start at $25 per contributing developer per month and include unlimited tests.

How do I troubleshoot Snyk GitLab connection failures?

First verify your personal access token has not expired and has the api scope by testing it against the GitLab API directly with curl. Check that the token owner has at least Maintainer access to the projects you want to import. For self-managed GitLab, verify that your Snyk Broker is running and healthy. If projects fail to import, confirm that the repositories contain recognized manifest files. Check Snyk's status page at status.snyk.io for service outages. Regenerate the token if authentication errors persist.

What are alternatives to Snyk for GitLab security scanning?

GitLab Ultimate includes built-in SAST, DAST, dependency scanning, and container scanning, but it requires the most expensive GitLab tier. Trivy is an open-source scanner for containers and dependencies that integrates easily with GitLab CI. Semgrep provides SAST scanning with a generous free tier. CodeAnt AI offers AI-powered code review with native GitLab support starting at $24 per user per month, covering both security analysis and code quality in a single tool.

Originally published at aicodereview.cc

Top comments (0)