GitLab

Access

Code Repository

Mycroft records merge request approvals, protected branch rules and security scanner findings from GitLab.

GitLab's group hierarchy makes permissions inheritable, so effective access is usually broader than direct membership suggests. Mycroft resolves it, and records whether authors are permitted to approve their own merge requests.

Find out more

How Mycroft connects to GitLab

How it connects: You authorize Mycroft through GitLab OAuth, or issue an API token for it to use.
What Mycroft can access: Granted scopes are read_api, read_user, api, read_repository and read_registry, which include repository read access. Mycroft runs a read-only pull model and does not write back.

Which controls GitLab evidence maps to

Each row is a control an auditor tests and the specific artifact Mycroft collects from GitLab to satisfy it. Collection runs on a schedule and every result is timestamped.

GitLab compliance control mappings and the evidence Mycroft collects for each
Framework	Control	What it requires	Evidence collected from GitLab
SOC 2	CC8.1	Changes are authorized and approved before implementation.	Merge request records with approvers, approval rules applied, pipeline status and merge timestamp for every change to a protected branch.
SOC 2	CC6.1	Logical access controls restrict access to information assets.	Group and project membership with access level (Guest through Owner), including inherited membership from parent groups.
SOC 2	CC6.3	Access is least privilege and removed when no longer needed.	Owner and Maintainer holders enumerated and reconciled against the current workforce roster in the access review.
SOC 2	CC7.1	Vulnerabilities are identified through monitoring.	SAST, dependency scanning and secret detection enablement per project, with open findings by severity and age.
ISO 27001	A.8.4	Access to source code is restricted.	Project visibility settings and the full membership matrix showing who holds developer and above on each repository.
ISO 27001	A.8.32	Changes follow a documented change management process.	Protected branch configuration, push rules and approval rules (including whether authors can approve their own merge requests) tested continuously.
ISO 27001	A.8.28	Secure coding practices are applied.	Security scanner configuration in CI templates with scan results attached to the merge requests they gated.
ISO 27001	A.8.31	Development, test and production environments are separated.	Environment and deployment configuration per project, with protected environment approval rules recorded.

What Mycroft collects automatically

Gathered from GitLab on a schedule, dated and stored against the controls above.

Merge request history with approvers, approval rules and merge timestamps
Protected branch settings, push rules and whether force push is permitted
Approval rule configuration, including the self-approval setting
Group and project membership with access levels and inherited grants
Project visibility across the group hierarchy
SAST, dependency scanning and secret detection enablement with open finding counts
Protected environment configuration and deployment approvals

Manual work this removes

The tasks that disappear from someone's quarter once GitLab is connected.

Resolving inherited group membership to determine who holds Maintainer on production
Screenshotting protected branch settings for each project
Exporting merge request approvals for the change management sample
Verifying project by project that self-approval is disabled
Confirming whether security scan findings were fixed or expired

Often connected alongside:

All integrations →

GitLab and Mycroft: frequently asked questions

Yes, where the instance is reachable from Mycroft. Both GitLab.com and self-managed instances expose the same REST API, and the integration uses read-only API scope either way. Self-managed setups usually need a brief network allowlist step during onboarding.

Through approval rules. Mycroft records whether merge request approval is required, how many approvers, and critically whether the author can approve their own merge request. That configuration plus the merge history is what an auditor tests when they ask you to show the person who wrote a change was not the person who released it.

The granted scopes are read_api, read_user, api, read_repository and read_registry, so repository read access is included. Mycroft runs a read-only pull model and does not store your code or write back.

Mycroft resolves the effective access level, including inheritance, so the access review shows what someone can actually do rather than only their direct membership. Inherited Owner and Maintainer grants are the ones that most often surprise teams during a review.

We turn the compliance nightmare into a dream

Talk to us