The GitLab integration enables security and compliance teams to automatically collect vulnerability data from GitLab projects. It connects Drata to GitLab so your team can continuously monitor code, dependency, secret, and container vulnerabilities and use this evidence to support ongoing compliance.
Key Capabilities
Automated Data Retrieval: Imports findings from supported scanning tools
Evidence support: Provides vulnerability data used in Drata’s automated evidence collection for vulnerability scanning tests mapped to DCF-18.
Read-only access: Retrieves vulnerability metadata without triggering or modifying scans
Prerequisites & Data Access
GitLab Project, Group, or Personal Access Token
Required GitLab role: Developer (for the token’s associated user)
Required GitLab scopes:
read_apiread_repositoryread_registry
Access to the GitLab projects you want Drata to monitor
Must be assigned one of the following Drata roles: Admin, Workspace Managers, DevOps Engineer.
If you have the Access Reviewer Drata role, you can only view the Connections page.
Important Note about Sync duration:
The initial sync may take additional time depending on how many vulnerabilities exist in your environment.
Drata retrieves up to 1,000 new findings per day. If your environment contains more than 1,000 findings, only the first 1,000 will be included in each daily sync, based on the scope you configured when connecting.
Any remaining findings are synced (up to a 1,000) during the next daily update. The order in which findings sync is determined by the scope you configured during the connection setup.
Permissions & Data Table
Permission / Scope | Why It’s Needed | Data Accessed (Read Only) |
| Retrieve vulnerability and project metadata | Vulnerability findings, project identifiers |
| Analyze repository-level findings | Code, dependency, and secret findings |
| Access container image metadata | Container vulnerability findings |
Step-by-Step Setup
Step 1: Create an Access Token
Create one of the following GitLab access tokens to authenticate the integration:
(Recommended) Project Access Token (Least Privilege)
Limits access to a single GitLab project
Ideal when monitoring only one project
Group Access Token: Grants access to all projects in the group
Personal Access Token: Grants access to all projects the user is a member of
Requirements
Role: Developer
Scopes:
read_api,read_repository,read_registrySet the expiration date to the maximum allowed
Save the token securely — it will not be visible again
Expected outcome: You have a valid GitLab access token that Drata can use to connect to GitLab.
Step 2: (Optional) Identify Project IDs
If you are using a Group or Personal Access Token and want to restrict scanning to specific projects, collect the Project IDs.
To find a Project ID:
Open the project in GitLab
Select Actions (⋯) on the project overview page
Click Copy project ID or navigate to Settings → General
Create a comma-separated list (example):
67411111,67422222,67433333
Expected outcome: You have a list of GitLab Project IDs that limit which projects Drata can access.
Step 3: Connect inside Drata
In Drata, go to Connections .
Go to your available connections and search and choose to connect GitLab. Ensure it is the correct type of connection.
Select the following configurations:
Severity of vulnerabilities: Choose the severity levels you want to import (Critical, High, Medium, Low).
Date: Select the date from which vulnerabilities should be pulled.
Private Access Token: Your GitLab access token
Allowed Project Ids (optional): Comma-separated Project IDs to restrict access. If
allowed_project_idsis not set, all projects accessible by the token will be scanned.
Expected outcome: The GitLab integration is connected using the access and project scope you specified.
Step 4: Validate connection / test
Confirm the connection card shows Connected in Drata.
Navigate to Vulnerabilities to confirm findings are being populated.
Validate that only scoped resources appear, if you restricted the API token's access.
Expected outcome:
Vulnerabilities appear inside Drata and can be used to support applicable vulnerability scanning tests.

