Overview
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) |
Category | 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
Go to Settings > Preferences > Access Tokens.
Click to Add New Token.
Insert Token Name, and set the following:
Expiration date: as long as possibleScopes:
read_api(minimum)Copy the new personal access token (Make sure you save it - you won't be able to access it again).
Configuring the GitLab Connector
Log in to your Vulcan Cyber dashboard and go to Connectors.
Click on Add a Connector.
Click on the GitLab icon.
Set up the Connector as follows:
Enter the API Token you generated earlier.
Click the Test Connectivity button to verify that Vulcan Cyber can connect to your GitLab instance, then click Create (or Save Changes).
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.
Allow some time for the sync to complete. Then, you can review the sync status under Log on the Connector's setup page.
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:
Go to the Vulnerabilities page.
Use the Search or Filter input box to select the Vulnerability Source or Connector filter.
Select GitLab from the vulnerability source/Connector list to filter results.
Click on any vulnerability for more vulnerability details.
Viewing GitLab assets in the Vulcan Platform
To view assets by Connector/Source:
Go to the Assets page.
Click on the relevant asset type tab (Code Projects).
Use the Search or filter input box to select Connector from the drop-down selection.
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:
Go to the Vulnerabilities / Assets Page.
Click on the Search and Filter input box and select Connector from the drop-down selection.
Locate the GitLab option to view all synced vulnerabilities/assets.
Select the relevant vulnerability from the results list.
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 | 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 |
|
message | Vulnerability title |
|
Technical severity | Vulnerability score |
|
Description (details) | Vulnerability description |
|
Vulnerability ID | Vulnerability details |
|
status | Vulnerability status |
|
CVE | CVE/S |
|
cwe | CWE |
|
CVSS vector | CVSS attack vector |
|
Codebase (location - file and start line) | Vulnerability instance connection- additional information | 
|
Vulnerability’s title | Fix - Title |
|
solution | Fix - Description |
|
Vulnerability status mapping
GitLab Status | Vulcan Status |
Confirmed, Needs triage | Vulnerable |
Resolved | Fixed |
false positive | Ignored - false positive |
acceptable risk, mitigating control, used in tests, not applicable | Ignored risk acknowledged |
Confirmed, Needs triage | Vulnerable |
Vulnerability score mapping
GitLab score | Vulcan score |
Critical | 10 |
igh | 7 |
Medium | 5 |
Low | 3 |
Info / unknown | 0 |
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
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:
Go to the "Projects" page.
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:
Click on a specific project.
Go to "Secure" and then "Vulnerability report."
In the Vulnerability report, filter vulnerabilities by status "Needs triage" and "Confirmed" to compare active vulnerabilities.
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:
On the main GitLab screen, click "Security" and "Vulnerability report."
Filter by status "Needs triage" and "Confirmed," and select specific projects to avoid private projects.
Export the data.
In the Exported File:
Remove duplications by the "Vulnerability" and "Other Identifiers" columns, which define Vulcan identifiers of unique vulnerabilities.
After removing duplications, the number of unique vulnerabilities should match the number of active vulnerabilities in Vulcan.
