devguard - Your Compliance Platform
PlatformSolutionsFrameworksDevelopersPricing
devguard

One workspace for your whole ISMS — Swiss-hosted, one control set, mapped to every framework you run.

All systems operational
Product
PlatformFeaturesSolutionsFrameworksPricing
Developers
API & CLIIntegrationsDocumentationChangelogSwiss hosting
Company
AboutBlogCompare
© 2026 devguard AG. All rights reserved.
Terms of servicePrivacy policySite noticeTrust centerLLM info
Swiss Made Software
Integrations · Source control

GitLab
evidence where the work happens

GitLab connects over OAuth for two-way remediation issues, cloud or self-hosted. Alongside the sync, read-only checks verify enforced two-factor authentication, project visibility and protected default branches across your group.

The checks

What devguard checks in GitLab

4 read-only checks, run on a schedule. Each failure becomes a finding linked to a control — every check is listed, none are “coming soon”.

Group is readable

Confirms the token can read the target group over the GitLab API.

group-connectivity

info

Group requires two-factor authentication

Fails if the GitLab group does not require all members to enable two-factor authentication. `require_two_factor_authentication` is only accurate when the token owner administers the group.

group-two-factor-required

high

Project is not publicly visible

Fails if the project's visibility is `public`, meaning its source is readable by anyone.

project-not-public

high

Default branch is protected against force-push

Fails if the project's default branch is not in the protected-branches list, or if that protected-branch entry allows force-push. Only exact-name protection rules are evaluated: a wildcard rule (for example `main*` or `*`) is not matched even though it does protect the branch.

default-branch-protected

high

Bring your current platform's test list — we'll map it against these checks, gap by gap

Two-way sync

Create issues in your GitLab projects, cloud or self-hosted, and keep each one in step as its status changes, connected over OAuth.

How it connects

Connected by you, scoped by you

Setup is minutes, not a migration project — and every step stays on your side

01

Install and scope the connection

Connect over OAuth or an app install and choose exactly what GitLab shares — you can revoke it on your side at any time

02

Checks run on a schedule

The first run starts right after connecting, then repeats on a schedule. Results are timestamped, so your evidence has a history, not a snapshot.

03

Evidence lands on the control

Passing results attach as evidence to the controls they support; failures become findings you triage. When the audit comes, the proof is already connected.

Related

More from your stack

Open any page for its full check register.

Read-only, revocable, Swiss-hosted

You create and scope every credential yourself, and you can revoke it at any time. Checks only read; results and evidence are stored in Switzerland and stay exportable.

FAQ

Questions about GitLab

Is the GitLab access read-only?

Yes. The checks authenticate with a credential you create and scope yourself, and only ever read configuration. devguard holds no write access to GitLab and remediates nothing silently.

What happens when a check fails?

A failed check becomes a finding linked to the control it supports, with the evidence attached. You decide the treatment — nothing pages your engineers and nothing is auto-remediated.

Where do the results live?

Checks run from Swiss infrastructure, and results and evidence are stored in Switzerland. Everything is exportable — your evidence stays yours.

Connect GitLab and see the evidence land

20 minutes on how you run certification today. Bring your current test or control list and we'll map it against these checks — honestly, gap by gap.

Book a conversation
Book a conversation
Two-way sync
GitHub
4 checks
Bitbucket
3 checks
Buildkite
3 checks
CircleCI
3 checks
See all integrations
Book a conversation
Sign in
Start for free
Book a conversation
Start for free