Skip to main content
GitLab Connector

Learn all about integrating GitLab into the Vulcan Platform

Updated over a week ago


About GitLab

GitLab is an open-source code repository and collaborative software development platform for large DevOps and DevSecOps projects.

Why integrate GitLab into the Vulcan platform?

The GitLab Connector by Vulcan integrates with the GitLab platform to pull and ingest assets type Code Project and their related vulnerabilities into your Vulcan Platform. Once the integration is complete, the Vulcan Platform scans the report's findings to correlate, consolidate, and contextualize the ingested data to impact risk and remediation priority.

GitLab Connector Details

Supported products

GitLab Ultimate (paid version of gitlab)


Application Security - SAST, SCA

Ingested asset type(s)

Code Projects

Integration type

UNI directional (data is transferred from the Connector to the Vulcan Platform in one direction)

Supported version and type

SaaS (latest)

Connector Setup

Prerequisites and user permissions

Before you begin configuring the Connector, make sure you have the following:

Generating GitLab API Token

  1. Go to the GitLab platform and log in.
    Minimum user permissions required: read_api scope

  2. Go to Settings > Preferences > Access Tokens.

  3. Click to Add New Token.

  4. Insert Token Name, and set the following:
    Expiration date: as long as possible

    Scopes: read_api (minimum)

  5. Copy the new personal access token (Make sure you save it - you won't be able to access it again).

Configuring the GitLab Connector

  1. Log in to your Vulcan Cyber dashboard and go to Connectors.

  2. Click on Add a Connector.

  3. Click on the GitLab icon.

  4. Set up the Connector as follows:

  5. Click the Test Connectivity button to verify that Vulcan Cyber can connect to your GitLab instance, then click Create (or Save Changes).

  6. Inactive Assets: You can configure a Vulcan rule to consider inactive assets, and Vulcan will remove assets that do not appear in scans within the configured time range.

  7. Allow some time for the sync to complete. Then, you can review the sync status under Log on the Connector's setup page.

  8. To confirm the sync is complete, navigate to the Connectors page. Once the GitLab icon shows Connected, the sync is complete.

GitLab in the Vulcan Platform

Viewing GitLab vulnerabilities in the Vulcan Platform

To view vulnerabilities by Connector/Source:

  1. Go to the Vulnerabilities page.

  2. Use the Search or Filter input box to select the Vulnerability Source or Connector filter.

  3. Select GitLab from the vulnerability source/Connector list to filter results.

  4. Click on any vulnerability for more vulnerability details.

Viewing GitLab assets in the Vulcan Platform

To view assets by Connector/Source:

  1. Go to the Assets page.

  2. Click on the relevant asset type tab (Code Projects).

  3. Use the Search or filter input box to select Connector from the drop-down selection.

  4. Select GitLab from the Asset source/Connector list to filter results and view all synced assets.
    See the complete list of available asset filters per asset type

Taking Action on vulnerabilities and assets detected by GitLab

To take remediation action on vulnerabilities and assets detected by GitLab:

  1. Go to the Vulnerabilities / Assets Page.

  2. Click on the Search and Filter input box and select Connector from the drop-down selection.

  3. Locate the GitLab option to view all synced vulnerabilities/assets.

  4. Select the relevant vulnerability from the results list.

  5. Click Take Action.

Automating remediation actions on vulnerabilities detected by GitLab

Large environments quickly become unmanageable if constant manual attention and effort are necessary to remediate vulnerabilities. You can take advantage of the automation capabilities of Vulcan Cyber and the GitLab Connector.

From GitLab to the Vulcan Platform - Data Mapping

The Vulcan Platform integrates with GitLab through API to pull relevant vulnerabilities and assets data and map it into the Vulcan Platform pages and fields.

Code Project fields mapping

GitLab field

Vulcan field

field/Value example

Project name

Asset Name

Code Projects

Asset type

file name

Asset codebase - Source (SAST)

line number

Asset codebase - Location (SAST)

package name

Asset libraries- Component name (SCA)

package version

Asset libraries- Component version (SCA)

Project ID
web URL

Asset details

Repo Tags

Asset Tags - Vendor’s tags

topic tags

Asset Tags - Additional

Vulnerability instance uniqueness criteria

Discovery time

Vulnerability instance first seen

scan date

Vulnerability instance Last seen

source file and line

Vulnerability instance location path


Vulnerability title

Technical severity

Vulnerability score

Description (details)

Vulnerability description

Vulnerability ID

Vulnerability details


Vulnerability status





CVSS vector

CVSS attack vector

Codebase (location - file and start line)
scanner name
location URL (identifier URL) need to be clickable and included in the ticket
job info (pipeline, jobID, branch, commit, etc)
Protected/not protected branch
full path

Vulnerability instance connection- additional information

Vulnerability’s title

Fix - Title


Fix - Description

Vulnerability status mapping

GitLab Status

Vulcan Status

Confirmed, Needs triage




false positive

Ignored - false positive

acceptable risk, mitigating control, used in tests, not applicable

Ignored risk acknowledged

Confirmed, Needs triage


Vulnerability score mapping

GitLab score

Vulcan score









Info / unknown


Status Update Mechanisms

Every day, the Vulcan Platform syncs with the vendor's platform to receive updates on existing vulnerabilities and assets and to retrieve new ones (if any added).

The table below lists how the status update mechanism works in the Git Lab connector for the vulnerabilities and assets in the Vulcan Platform.

Update type in Vulcan

Mechanism (When?)

The asset is archived

- Asset status on the connector's side indicates irrelevancy or archived. In this case, it's the status "Archived".

The vulnerability instance status changes to "Fixed"

- If the vulnerability no longer appears in the scan findings.

- Vulnerability status on the connector's side indicates that the vulnerability has been fixed. In this case, it is the status "Resolved".

Note: Asset or vulnerability updates on the vendor side are reflected on the Vulcan Platform only on the next scheduled connector sync (the next day).

Support and Expected Behaviour

Support and expected behavior remarks on some of GitLab ingested and uningested data:

  • In Vulcan, unique vulnerabilities are identified based on their name and GitLab "Identifiers." Consequently, you may encounter several vulnerabilities with the same name on the Vulcan unique vulnerability screen. However, when you click on one of them, you will notice that the identifiers, such as CVEs, CWEs, and scanner reports, will vary among these vulnerabilities.

API Endpoints in Use

API version: GraphQL API


Use in Vulcan


Get information about current user.


Find groups visible to the current user.


Find projects visible to the current user.


Vulnerabilities reported on projects on the current user’s instance security dashboard.


Get information about current user.

Data Validation

This section shows how to validate and compare data between Vulcan and the GitLab platform.

Matching Assets

In GitLab:

  1. Go to the "Projects" page.

  2. The number of projects under "Yours" (minus personal projects) should match the number of code projects in Vulcan.

    In this example, the user has six (6) personal projects.

Matching Vulnerability Instances

In GitLab:

  1. Click on a specific project.

  2. Go to "Secure" and then "Vulnerability report."

  3. In the Vulnerability report, filter vulnerabilities by status "Needs triage" and "Confirmed" to compare active vulnerabilities.

  4. The number of vulnerabilities in the "Development" vulnerability tab should match the vulnerability instances count in Vulcan. Other instances statuses will be mapped according to the Vulnerability Status Mapping table above.

Matching Unique Vulnerabilities

In GitLab:

  1. On the main GitLab screen, click "Security" and "Vulnerability report."

  2. Filter by status "Needs triage" and "Confirmed," and select specific projects to avoid private projects.

  3. Export the data.

In the Exported File:

  1. Remove duplications by the "Vulnerability" and "Other Identifiers" columns, which define Vulcan identifiers of unique vulnerabilities.

  2. After removing duplications, the number of unique vulnerabilities should match the number of active vulnerabilities in Vulcan.

Did this answer your question?