GitLab
Visualize GitLab users, groups, code repositories, and merge requests, map GitLab users to employees and development/security trainings, and monitor changes through queries and alerts.
- Installation
- Data Model
- Types
Installation
To use this integration, JupiterOne requires a GitLab personal access token configured with read access (read_api scope) and
the API base URL, such as https://gitlab.com).
Configuration in JupiterOne
To install the GitLab integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select GitLab. Click New Instance to begin configuring your integration.
Creating an instance requires the following:
-
Account Name by which you'd like to identify this GitLab account in JupiterOne. Ingested entities will have this value stored in
tag.AccountNamewhen Tag with Account Name is selected. -
Description that will further assist your team when identifying the integration instance.
-
Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as
DISABLEDand manually execute the integration. -
Personal Access Token configured for read access in GitLab.
Once your token has expired, the integration will no longer run successfully, and the token will be revoked from your GitLab account. You will need to create another token to replace the expired one.
- Your GitLab API Base URL (e.g.,
https://gitlab.com, or your self-managed instance URL).
Data Volume Configuration
Control how much data is ingested from GitLab to manage storage and processing.
Ingestion Windows (Time Ranges)
| Field | Description | Default | Options |
|---|---|---|---|
| Merge Requests Ingestion Window | Ingestion window for updated merge requests (days ago) | 90 | 90, 180, 275, 365 |
How it affects data volume: Longer windows increase the number of merge requests ingested from GitLab.
Data Filtering Options
| Field | Type | Description | Default |
|---|---|---|---|
| Included Vulnerability Severities | Multi-select | Select vulnerability severities to ingest | Medium, High, Critical |
| Included Vulnerability States | Multi-select | Select vulnerability states to ingest | Confirmed, Detected |
| Included Vulnerability Report Types | Multi-select | Select vulnerability report types to ingest | None (all disabled by default) |
| Ingest Regular Users Only | Boolean | Skip all bot accounts including project and group bots | false |
How it affects data volume:
- Severity filtering reduces vulnerabilities by excluding lower-severity findings. By default, only Medium, High, and Critical severabilities are ingested.
- State filtering limits vulnerabilities to selected states. By default, only Confirmed and Detected vulnerabilities are ingested (Dismissed and Resolved are excluded).
- Report type filtering allows selecting specific vulnerability scan types (SAST, DAST, Container Scanning, etc.). By default, all types are disabled and must be explicitly enabled.
- User filtering, when enabled, excludes bot accounts from ingestion, reducing the number of user entities.
Click Create after all values are provided to finalize the integration.