GitLab Connector

The following is not supported in Tenable FedRAMP Moderate environments. For more information, see the Tenable FedRAMP Product Offering.

GitLab is a DevSecOps platform that provides source code management, CI/CD, and application security testing.

The following steps allow you to configure this connector for use with Tenable Exposure Management from start to finish.

Tip: For more information on how third-party integrations work, see Connectors.

Connector Details

Tenable Exposure Management ingests GitLab code repository assets and vulnerability findings (Static Application Security Testing, Secret Detection, and Dependency Scanning) through the GitLab GraphQL API.

Details	Description
Supported products	GitLab SaaS (gitlab.com) GitLab Self-Managed The GitLab Ultimate tier is required to ingest findings.
Category	Static Application Security Testing (SAST) and Software Composition Analysis (SCA)
Ingested data	Assets and Findings
Ingested Asset Classes	Code Repository
Integration type	UNI directional (data is transferred from the connector to Tenable Exposure Management in one direction)
Supported version and type	GitLab SaaS (latest) GitLab Self-Managed 15.0 or later (16.0 or later recommended for full GitLab Advanced SAST support and richer identifier and location data)

Prerequisites and User Permissions

Before you begin configuring the connector, make sure to:

Confirm that you have a GitLab Ultimate license on the group you want to scan. The connector uses the group-level vulnerabilities query, which is an Ultimate-tier feature. On the Premium and Free tiers, the connector completes successfully but ingests no findings.
At the project level, enable Security and Compliance in Settings > General > Visibility, project features, permissions.
Confirm that CI/CD pipelines with security scanning templates run on the project's default branch. Findings aggregate to the group only from default-branch pipelines.
Generate a GitLab access token.

Generate a GitLab access token

Generate a personal access token or a group access token with the read_api scope. The token owner must have at least the Maintainer or Owner role on the target group.

In GitLab, go to User Settings > Access Tokens. For a group-scoped token, go to Group Settings > Access Tokens.
Click Add new token.
Set an expiry date and, optionally, a role of Maintainer or Owner.
Select the read_api scope.
Click Create personal access token.
Copy the token value to a safe location. GitLab shows the token only once, and you need it to configure the connector.

Add a Connector

To add a new connector:

In the left navigation menu, click Connectors.

The Connectors page appears.
In the upper-right corner, click Add new connector.

The Connector Library page appears.
In the search box, type the name of the connector.
On the tile for the connector, click Connect.

The connector configuration options appear.

Configure the Connector

To configure the connector:

(Optional) In the Connector's Name text box, type a descriptive name for the connector.
(Optional) To use a preconfigured on-prem connector to connect to this connector, from the Gateway drop-down, select the on-prem connector you want to use for the connector. Otherwise, select Don't use gateway.

Note: For information about configuring a gateway, see Tenable On-Prem Connector.
In the API Token text box, type the access token that you generated in GitLab.
In the Server URL text box, type your GitLab server URL. For GitLab SaaS, use https://gitlab.com. For GitLab Self-Managed, type the URL of your GitLab instance.
Data pulling configuration: This configuration has dynamic settings tailored to the specific connector and integration type. Below are the configurations relevant to this connector.
- In the Asset Retention text box, type the number of days after which you want assets to be removed from Tenable Exposure Management. If an asset has not been detected or updated within the specified number of days, it is automatically removed from the application, ensuring your asset inventory is current and relevant.
  
  Tip: For more information, see Asset Retention.
- From the Immediately remove assets when their status is drop-down, select one or more asset statuses, such as Archived. Tenable Exposure Management immediately removes an asset when its status in GitLab matches a selected status.
In the Test connectivity section, click the Test Connectivity button to verify that Tenable Exposure Management can connect to your connector instance.
- A successful connectivity test confirms that the platform can connect to the connector instance. It does not, however, guarantee that the synchronization process will succeed, as additional syncing or processing issues may arise.
- If the connectivity test fails, an error message with details about the issue appears. Click Show tests for more information about the exact error.
In the Connector scheduling section, configure the time and day(s) on which you want connector syncs to occur.

Tip: For more information, see Connector Scheduling.
Click Create. Tenable Exposure Management begins syncing the connector. The sync can take some time to complete.
To confirm the sync is complete, do the following:
- Navigate to the Connectors page and monitor the connector's status. Sync is complete once the connector status is Connected.
- View the sync logs for the connector to monitor the logs for a successful connection.

GitLab in Tenable Exposure Management

Locate Connector Assets in Tenable Exposure Management

As the connector discovers assets, Tenable Exposure Management ingests those devices for reporting.

To view assets by connector:

In Tenable Exposure Management, navigate to the Assets page.
In the Filters section, under 3rd Party Connectors, click the connector name for which you want to view assets.

The asset list updates to show only assets from the selected connector.
Click on any asset to view Asset Details.

Locate Connector Findings in Tenable Exposure Management

As the connector discovers individual findings, Tenable Exposure Management ingests those findings for reporting.

To view findings by connector:

In Tenable Exposure Management, navigate to the Findings page.
In the Filters section, under 3rd Party Connectors, click the connector name for which you want to view findings.

The findings list updates to show only assets from the selected connector.
Click on any asset to view Finding Details.

Data Mapping

Tenable Exposure Management integrates with the connector via API to retrieve relevant weakness and asset data, which is then mapped into the Tenable Exposure Management system. The following tables outline how fields and their values are mapped from the connector to Tenable Exposure Management.

Code Repository Mapping

Tenable Exposure Management UI Field	GitLab Field
Asset Id	project.id
Asset Class	CODE_REPOSITORY
Source	gitlab
Asset Name	group.name / project.name
Description	project.description
Code Repository URL	project.webUrl
Visibility	project.visibility
Asset Status	project.archived
External Tags	project.topics
Created Date	project.createdAt
Last Commit Date	project.lastActivityAt
First Seen	project.createdAt
Last Seen	project.lastActivityAt
Asset Custom Attributes	project.fullPath group.path group.name

Finding Mapping

Tenable Exposure Management UI Field	GitLab Field
Vendor ID	vulnerability.id
Finding Type	SOURCE_CODE
Finding Category	SAST SCA
Finding Name	vulnerability.title
Description	vulnerability.description
CVEs	vulnerability.identifiers (cve)
CWEs	vulnerability.identifiers (cwe)
Severity	vulnerability.severity
Solution	vulnerability.solution
Code File Path	vulnerability.location.file
Code Line Number	vulnerability.location.startLine
Source Code Package Name	vulnerability.location.dependency.package.name
Source Code Package Version	vulnerability.location.dependency.version
Origin Finding URL	vulnerability.vulnerabilityPath
First Seen	vulnerability.detectedAt
Last Seen	vulnerability.updatedAt
State	vulnerability.state
Finding Custom Attributes	project_full_path end_line primary_identifier vulnerable_class vulnerable_method false_positive

Finding Status Mapping

Tenable Exposure Management Status	GitLab Status
Active	DETECTED CONFIRMED
Fixed	RESOLVED DISMISSED

Tenable Exposure Management Status

GitLab Status

Active

DETECTED

CONFIRMED

Fixed

RESOLVED

DISMISSED

Finding Severity Mapping

Tenable Exposure Management Severity	GitLab Severity
Critical	critical
High	high
Medium	medium
Low	low
None	info unknown

Note: GitLab returns severity labels for findings. Tenable Exposure Management ingests the GitLab severities and CVSS scores for reference. These values do not affect the scoring that Tenable Exposure Management calculates.

Status Update Mechanisms

Every day, Tenable Exposure Management syncs with the vendor's platform to receive updates on existing findings and assets and to retrieve new ones (if any were added).

The table below describes how the status update mechanism works in the connector for findings and assets ingested into Tenable Exposure Management.

Update Type in Tenable Exposure Management	Mechanism (When?)
Archiving Assets	Asset not seen for X days according to "Last Seen". See Asset Retention Asset status changes to one of the selected statuses defined in the Asset Retention configuration.
Change a Finding status from "Active" to "Fixed"	Finding status changes to RESOLVED or DISMISSED on the vendor's side.

Note: Updates on the vendor side are reflected in Tenable Exposure Management only when the next scheduled connector sync time is complete (once a day).

Uniqueness Criteria

Tenable Exposure Management uses defined uniqueness criteria to determine whether an ingested asset or finding should be recognized as a distinct record. These criteria help define how assets and findings are identified and counted from each connector.

Tip: To learn more about data deduplication and uniqueness criteria, See Third-Party Data Deduplication in Tenable Exposure Management.

The uniqueness criteria for this connector are as follows:

Data	Uniqueness Criteria
Asset	project.id
Finding	vulnerability.id

API Endpoints in Use

API version: GraphQL (versionless).

API	Use in Tenable Exposure Management	Permissions required
`POST {server_url}/api/graphql` — `currentUser`	Tests connectivity and authentication.	read_api
`POST {server_url}/api/graphql` — `user.groups`	Discovers the groups that the token can access.	read_api Maintainer or Owner role
`POST {server_url}/api/graphql` — `group.projects`	Enumerates the projects under each group to create code repository assets.	read_api Maintainer or Owner role
`POST {server_url}/api/graphql` — `group.vulnerabilities` (SAST and Secret Detection)	Retrieves SAST and Secret Detection findings for each group.	read_api GitLab Ultimate license
`POST {server_url}/api/graphql` — `group.vulnerabilities` (Dependency Scanning)	Retrieves Dependency Scanning (SCA) findings for each group.	read_api GitLab Ultimate license

Data Validation

This section shows how to validate and compare data between Tenable Exposure Management and GitLab.

Asset Data Validation

Objective: Ensure the number of projects visible to the token in GitLab aligns with the number of code repository assets displayed in Tenable Exposure Management.

In GitLab:

Navigate to Group > Projects.

Note the number of projects visible to the token.

In Tenable Exposure Management:

Locate your connector assets, filtered by Source = gitlab.
Compare the total number of assets between GitLab and Tenable Exposure Management.

Expected outcome: The total numbers returned in GitLab and Tenable Exposure Management should match, minus any projects that are scheduled for deletion. GitLab retains projects that are scheduled for deletion for approximately seven days.

If an asset is not visible in Tenable Exposure Management, check the following conditions:

The token has the Maintainer or Owner role on the group.
The project is not scheduled for deletion or archived when archived-asset filtering is on.
The Security and Compliance setting is enabled at the project level.
The asset status changed to one of the selected statuses defined in the Asset Retention configuration.
The asset was archived because it did not return in the connector's last sync.

Tip: To learn more on how assets are archived and findings change status, see Status Update Mechanisms.

Finding Data Validation

Objective: Ensure the number of vulnerabilities in GitLab aligns with the number of findings in Tenable Exposure Management.

In GitLab:

Navigate to Group > Secure > Vulnerability Report.

Filter by Status = Needs triage or Status = Confirmed.

Note the number of vulnerabilities.

In Tenable Exposure Management:

Locate your connector findings, filtered by Source = gitlab and State = Active.
Compare the total number of findings between GitLab and Tenable Exposure Management.

Expected outcome: The total numbers returned in GitLab and Tenable Exposure Management should match. Differences are usually caused by findings on non-default branches, which GitLab's group-level aggregation excludes, or by scans that have not completed.

If a finding is missing from Tenable Exposure Management or no longer active, check the following conditions:

A pipeline ran and passed on the default branch.
The individual scan jobs (GitLab Advanced SAST, Secret Detection, and Gemnasium Dependency Scanning) ran and produced non-empty report artifacts.
The finding appears first in the project-level Vulnerability Report. If it does not, the group-level query is also empty.
The group has an active GitLab Ultimate license.
The finding is in the Detected or Confirmed state, not Dismissed.
The finding is marked as Fixed and appears under the Fixed state on the Findings screen.

Tip: To learn more on how assets are archived and findings change status, see Status Update Mechanisms.