Scan Source

GitLab Integration

Scan enabled GitLab repository targets for credentials in reachable branch history, subject to job and access limits.

Connect GitLab View Setup Guide

Key Features

GitLab.com and reachable self-managed GitLab connections
OAuth or access-token connection paths in Cremit
Accessible projects discovered as separate scan targets
Branch commit changes scanned across jobs, subject to limits and fallback mode

Requirements

1A GitLab identity or token that can read the intended projects and repositories
2A Cremit account with permission to add and manage scan sources
3Network reachability from Cremit to a self-managed GitLab instance, if used

Step-by-step setup guide

Review the steps needed to configure this integration.

What is in scope?

Cremit discovers projects visible to the GitLab connection and creates repository scan targets. You choose which targets to enable. A connection does not prove that every project in an organization is accessible or that every discovered target has been scanned. Review newly discovered projects rather than assuming they are included.

For an enabled repository, the normal worker follows branch commit changes and examines supported content. Large repositories, failed clones or API fallback can narrow a job to the default branch or pause at commit and file limits. Unfinished work may continue in later jobs. Check branch progress, completed runs, skipped content and connection errors before describing a repository as covered. This connection does not scan GitLab issue text or merge request conversation bodies.

Connect GitLab

In Cremit Platform, open Configuration → Scan Sources and add a GitLab source. Choose the GitLab.com OAuth path, a configured self-managed OAuth application, or the access-token path shown in the connection form. Give the connection access to only the projects you intend to inspect. A self-managed instance must be reachable from Cremit; private-network access is not implied by entering its URL.

After authorization, inspect the discovered project targets and enable the intended repositories. If a project is absent, check the GitLab identity or token permissions and the instance URL, then refresh discovery. If a target is present but has no completed scan, inspect its job status before relying on a clean result.

Verify one repository

Use a repository you control and commit a harmless nonworking example string on an enabled branch. After a completed scan, check the target, branch progress and finding location. Do not use a working credential as a test fixture. The time to a result depends on scheduling, repository size, connectivity and remaining work; a push does not guarantee a finding within a fixed number of minutes.

For a real finding, inspect the source location and any supported issuer check, then identify the current service owner. Removing the text from GitLab does not invalidate the credential. The owner rotates or revokes a confirmed exposed key at its issuer and checks dependent workloads.