Integrations / Version control & CI

Screenata + GitLab

How do you collect SOC 2 and ISO 27001 evidence from GitLab?

Quick answer

GitLab is where change management gets proved, because SOC 2 CC8.1 asks you to show that a change was reviewed and authorized before it reached production, and the merge request record is what shows it. Having GitLab is not the control. The control is the enforced configuration, such as protected branches and required merge request approvals, plus the record that the configuration operated across the whole audit period. Screenata runs 18 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.

Screenata connects to GitLab read-only and runs 18 native checks across your projects: protected branches, merge request approvals, and pipeline security settings. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog.

See how Vera works

18 native checks · read-only · signed evidence

What it proves

GitLab evidence, mapped to controls.

Each area below is scanned on a schedule. A finding is not a green checkmark: it is a signed artifact an auditor can verify, mapped to the exact requirement it satisfies.

Evidence area

What the checks verify

Maps to

Protected branches

Protection rules on production branches, verified per project against your change management policy.

Proof that direct pushes to production branches are prevented, the enforcement layer of change management.

SOC 2CC8.1ISO 27001A.8.32

Merge request approvals

Whether merges require approvals and how approval rules are configured across projects.

The review-before-deploy record auditors sample when testing change management.

SOC 2CC8.1ISO 27001A.8.32

Pipeline security

CI/CD pipeline security settings, verified against the configuration your deployment controls describe.

Findings that the path from commit to production enforces the gates your policies claim.

SOC 2CC8.1ISO 27001A.8.9

Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.

Compliance checks

What Screenata checks on GitLab, and why each matters.

Each row is a real native check, the framework control it produces evidence for, and the risk it closes. This is what continuous GitLab compliance actually looks like. Checks run on a schedule; a failing check opens a ticket and re-verifies after a human applies the fix.

Check & why it matters

Maps to

Branch Protection Rules

Without a protected default branch, code can be pushed straight to production with no enforced gate. An auditor verifies that active projects protect their default branch.

SOC 2CC8.1

Merge Request Approvals Required

If merges do not require approval, changes reach production without a second reviewer, so unauthorized code can ship. An auditor verifies that merge requests require at least one approval before merge.

SOC 2CC8.1

Approvals Reset on New Commits

An approval that survives later commits can wave through code no one actually reviewed. An auditor verifies that approvals reset when new commits are pushed.

SOC 2CC8.1

2FA Required

Without enforced two-factor authentication, a stolen password is enough to reach your source. An auditor verifies that the group requires 2FA for all members.

SOC 2CC6.1

SAST Scanning Enabled

Static analysis catches insecure code before it merges, and without it flaws ship undetected. An auditor verifies that SAST scanning runs in project pipelines.

SOC 2CC7.1

Dependency Scanning Enabled

Vulnerable dependencies remain exploitable until identified, and dependency scanning surfaces them. An auditor verifies that dependency scanning is configured in CI.

SOC 2CC7.1

Secret Detection Enabled

Credentials committed to a repository stay exploitable until found, and secret detection is what catches them. An auditor verifies that secret detection scanning is enabled.

SOC 2CC7.2

Container Scanning Enabled

Container images can ship known vulnerabilities into production if they are never scanned. An auditor verifies that container scanning runs for projects that build images.

SOC 2CC7.1

Projects Are Private

A project left public can expose source code and secrets to anyone. An auditor verifies that projects are private or internal unless intentionally public.

SOC 2CC6.1

Audit Events Streaming

Audit events that are not streamed off the platform can be lost or tampered with, leaving no reliable record for investigation. An auditor verifies that audit events stream to a SIEM or log destination.

SOC 2CC7.2

Force Push Disabled

Force pushing to the default branch rewrites history and can erase the record of what changed and who approved it. An auditor verifies that force push is disabled on the default branch.

SOC 2CC8.1

Pipeline Must Succeed Before Merge

Merging without a passing pipeline lets untested or failing code reach production. An auditor verifies that merge requests require a successful pipeline before merge.

SOC 2CC8.1

All Discussions Must Be Resolved

Unresolved review threads mean raised concerns can be merged past without an answer. An auditor verifies that merge requests require all discussions resolved before merge.

SOC 2CC8.1

Default Branch Protection Level

If new projects default to weak branch protection, gaps appear the moment a repository is created. An auditor verifies that the group enforces full branch protection by default.

SOC 2CC6.1

Drawn from Screenata’s GitLab check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.

How it connects

Read-only, revocable, yours.

You create a read-scoped access token and Screenata uses it for scheduled scans. Code is never persisted, credentials never touch the Screenata database, and the token can be revoked from your GitLab settings at any time.

Read-only by construction

OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.

Signed findings

SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.

Mapped to controls

Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.

GitLab FAQ

What teams ask before connecting.

Full provider list on the integrations page.

What access does Screenata need to GitLab?

A read-scoped access token that you create and control. Scans read project configuration and settings; code is never persisted, and you can revoke the token at any time.

Does the GitLab integration cover self-managed instances?

The checks target project and branch configuration through the GitLab API. If you run a self-managed instance, connectivity depends on your network setup; guided evidence collection covers anything the native connection cannot reach, recorded and signed like any other artifact.

What happens when a GitLab check fails?

Vera opens a ticket describing the failing configuration and re-verifies after a human applies the fix. Nothing in your projects is changed by Screenata; the connection is read-only by construction.

What are the steps to implement SOC 2 with GitLab?

First, connect Screenata with a read-scoped token covering the projects in scope. Second, let the first scan run so the baseline reflects how your groups and projects are actually configured. Third, fix what fails: protect the default branch, require at least one merge request approval, reset approvals when new commits are pushed, require a successful pipeline before merge, disable force push, and enable secret detection and dependency scanning in CI. Fourth, leave the scheduled scans running so passing results accumulate as signed evidence across the observation window, which for a Type 2 report is usually three to twelve months. Fifth, hand the evidence package to an independent auditor. The audit is a separate engagement with a licensed CPA firm, which issues the report; Screenata prepares and holds the evidence it asks for.

What evidence do auditors ask for about change management?

They pick a sample of merged changes and expect four things for each one. That a review happened before the merge, not after. That an enforced protected branch and approval configuration made the review mandatory rather than a convention people follow. That the approver was someone other than the author. And that the record covers the whole audit period, not a screenshot taken the week before fieldwork. Branch Protection Rules and Merge Request Approvals Required show the enforcement, Approvals Reset on New Commits shows the approval applied to the code that actually merged, and Pipeline Must Succeed Before Merge shows the testing gate held.

Do auditors accept evidence Screenata collects from GitLab?

Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.

Connect and see

Fifteen minutes after connecting GitLab, you know your real posture.

Pricing

Related: GitHub · Bitbucket · Azure DevOps · Kubernetes