How DSALTA integrates with GitLab — data collected, setup guide, and automated compliance checks.
Overview
How to connect
Automated checks
Useful links
DSALTA connects to GitLab using read-only API access to collect compliance evidence automatically. Data feeds into your Data Library modules. Compliance checks re-run once a day at 02:00 America/New_York.
Read-only access. DSALTA never modifies, creates, or deletes resources in your GitLab environment.
DSALTA reads the GitLab user roster — names, emails, roles and active status, which appears on your Access page; and your GitLab resources, which appear on your Inventory page; and security findings, which appear on your Vulnerabilities page — that page carries GitLab vulnerability findings, which GitLab documents as Ultimate, plus one row per published registry package on every tier, named Package <name>@<version> with severity Info and source GitLab Packages, which is a dependency-inventory signal rather than a detected vulnerability. It also reads your open and merged merge requests, which appear on your Code Changes page — DSALTA does not read commits.It calls these GitLab endpoints:
/user
/groups
/groups/{groupId}/projects
/groups/{groupId}/members/all
/projects
/projects/{id}
/projects/{id}/members/all
/projects/{id}/merge_requests
/projects/{id}/approval_rules
/projects/{id}/protected_branches
/projects/{id}/packages
/projects/{id}/vulnerability_findings
/merge_requests
Permissions the checks require:read_apiEvery request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GitLab environment.
There is no Reconnect button. Open Integrations → Connected, click Manage on the GitLab card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from GitLab. This usually happens when API tokens expire.
Data is not syncing
Verify the connected account still holds the permissions listed under Before you begin. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
Use a GitLab personal access token. Recommended:Legacy token with scopes read_api, read_user, and read_repository. Use Fine-grained token (Beta) only if your organization requires it.Before you begin
GitLab account with access to the groups or projects to assess
Some checks need a paid GitLab tier. Peer review should be enforced for code changes and Code changes should be reviewed by peers before merging read merge-request approval rules, which GitLab documents as Premium, Ultimate. The Vulnerabilities page reads project vulnerability findings, which GitLab documents as Ultimate. On GitLab Free the approval-rules call is refused and DSALTA reads the refusal as zero required approvals, so both peer-review checks report every non-archived project as non-compliant for as long as you stay on Free. Project vulnerability findings are refused the same way, leaving the Vulnerabilities page with the published-package rows described on the Overview tab — the connection itself still works, and the access, classification, MFA and branch-protection checks are unaffected.
You will need:
Field
Where to find it
Example
Personal access token
Legacy token: under Scopes, enable at least read_api; also enable read_user and read_repository when listed. Fine-grained: add read permissions for the groups/projects DSALTA should assess. · Open
glpat-…
1
Start in DSALTA
Open Integrations in the DSALTA sidebar, find GitLab, and click Connect to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
2
Integrating GitLab with DSALTA means
DSALTA will use your token to read GitLab data (projects, groups, members, merge-request and branch settings, pipeline merge requirements where exposed by the API) for security and compliance monitoring.DSALTA only reads. There is no code path that creates, modifies, or deletes anything in your GitLab projects or groups — every remediation is something your team does directly in GitLab.
3
Create a personal access token
In GitLab, select your avatar in the upper-right corner → Edit profile, then in the left sidebar select Access → Personal access tokens.
Click Generate token. Use Legacy token unless Fine-grained (Beta) is required.
Set Token name, Token description (optional), and Expiration date (recommended 1 year).
Legacy scopes:read_api (minimum); also read_user and read_repository when shown. Avoid write scopes and the broad api scope unless required.
Fine-grained:Group and project access → Add resource permissions (Group and project) with Read as needed.
Generate token and copy once (glpat- on GitLab.com).
GitLab caps the expiry date at 365 days from the day you create the token, so 1 year is effectively the longest option available to you. Self-managed instances running GitLab 17.6 or later can allow up to 400 days, but only if an administrator has turned on the buffered_token_expiration_limit feature flag — it is off by default.
GitLab’s members API does not return an email address for every member. When it is missing, DSALTA falls back to the username, and the two access checks match Access rows to your People page by email — so username-only rows will not match a person automatically and will need reviewing by hand.
4
Enter token
Paste your token below and click Connect.
Unless a GitLab host URL is stored on the connection, DSALTA calls https://gitlab.com/api/v4. If you run self-managed GitLab or GitLab Dedicated, a token generated on your own instance will not validate against gitlab.com — and DSALTA connects to gitlab.com, so contact DSALTA before you start if you are on a self-managed or GitLab Dedicated instance.
A personal access token acts as you. DSALTA sees exactly the groups and projects your own GitLab account can see, so generate the token from an account that is a member of every group you want inventoried and access-reviewed. The connection can additionally be narrowed to specific groups by storing a comma-separated list of Group IDs; left empty, DSALTA discovers groups and projects from your memberships.
DSALTA validates the credential when you click Connect. On success the integration moves to the Connected tab, and Manage → Status reads Connected and working properly. Checks begin reporting after the first sync.
If the connection is rejected. Invalid token or insufficient scopes for the requested operations.The on-screen message is generic — see Connection error messages.
Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.