Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which GitLab artifacts count as security evidence?
Updated
GitLab evidences change management through protected branches and merge-request approval rules, access through group and project membership, and vulnerability management through its security scanners and vulnerability report. Several of those are Premium- or Ultimate-gated.
GitLab evidence map, last verified 10 September 2026 against GitLab's public documentation for protected branches, merge-request approval rules and approval policies, SAST and secret detection, dependency and container scanning, DAST, audit events, and the compliance centre, read alongside the AICPA Trust Services Criteria (CC6 access, CC7 vulnerability, CC8 change) and ISO/IEC 27001:2022 Annex A 5.15, 8.8, 8.28 and 8.32. GitLab's tier packaging moves between releases: some capabilities are included in all tiers, several require Premium, and much of the security-scanning and compliance surface requires Ultimate. Confirm current tier gating in GitLab's own documentation before promising an artifact. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: an engineering leader, security engineer, or compliance owner on GitLab who needs to know which GitLab surface answers which audit question. This page extends the GitLab connector setup guide on this site rather than repeating it: that page covers connecting and scoping the integration, this page covers what the resulting artifacts evidence.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Mapping a control to a GitLab artifact is a planning step, not a conclusion that the control operated — see the prove-a-control-works page in this cluster for the operating-effectiveness question. Last verified 10 September 2026.
UI paths are given in text rather than as images, so they stay readable and stay correct longer. Where GitLab has renamed a navigation entry between releases, the words in the path are the search terms to use in your own instance.
- Tier gating is described as included in all tiers versus Premium-gated or Ultimate-gated, because that is how GitLab's documentation frames capability availability.
- Self-managed and GitLab.com differ on some administrative artifacts, notably instance-level audit events and instance-wide settings. Record which you run, because the artifact differs.
- An artifact is evidence only when you can produce the population — all merges into the protected branch in the period, not a selection.
- Approval rules and approval policies are different mechanisms with different tier requirements. Record which one enforces your protected branches, because an auditor tests the live one.
Control-to-GitLab-artifact map
Read the first column as the control assertion, the second as the GitLab artifact, the third as the navigation path, and the fourth as the tier and framework note. A framework reference is not a finding that the framework applies to you. Last verified 10 September 2026 against GitLab's public documentation. Not legal advice.
| Control assertion | GitLab artifact | Where it lives (UI path) | Tier and framework note |
|---|---|---|---|
| Changes to production code are reviewed and approved before merge | Protected-branch configuration; merge-request approval rules requiring a minimum number of approvals; the merge-request record showing approvers and merge time | Project → Settings → Repository → Protected branches. Approval configuration: Settings → Merge requests → Merge request approvals. Individual changes: the Merge requests list filtered to merged into the protected branch in the period. | Protected branches are documented as available in all tiers; configurable approval rules, including required approvals and eligible approvers, are documented as Premium and above. Maps to AICPA TSC CC8.1 and ISO/IEC 27001:2022 Annex A 8.32. |
| The author of a change cannot approve their own change | Approval settings preventing author and committer approval, and the merge-request approval record showing distinct approver identities | Project → Settings → Merge requests → Approval settings (prevent approval by the author, prevent approvals by users who add commits). | Documented as Premium and above. Maps to AICPA TSC CC8.1 and segregation-of-duties expectations under PCAOB AS 2201 where SOX applies. |
| Security findings block or gate a merge on stated criteria | Merge-request approval policies and scan-result policies, plus the policy evaluation record on each merge request | Group or project → Secure → Policies → Merge request approval policies. | Documented as Ultimate. Maps to AICPA TSC CC7.1 and CC8.1, and Annex A 8.28. |
| Automated checks must pass before a change reaches production | Pipeline configuration requiring successful jobs, the pipeline-must-succeed merge setting, and the pipeline run history | Project → Settings → Merge requests → Merge checks (pipelines must succeed). Run history: Build → Pipelines. | Merge checks are documented as available in all tiers, with some check types tier-gated. Maps to AICPA TSC CC8.1 and NIST SSDF (SP 800-218). |
| Only authorised people have access, at the least privilege needed | Group and project member lists with role levels, group-level membership inheritance, and the list of users with the Owner or Maintainer role | Group → Manage → Members; Project → Manage → Members. | Available in all tiers; custom roles are documented as Ultimate. Maps to AICPA TSC CC6.1–CC6.3 and Annex A 5.15 and 5.18. |
| Access is removed promptly when someone leaves or changes role | Audit events for member addition, removal, and role change, correlated with the leaver record in your HR system | Group → Secure → Audit events, or Admin area → Monitoring → Audit events on self-managed instances. | Group audit events are documented as Premium and above, with a broader event set and streaming on Ultimate. Maps to AICPA TSC CC6.2 and Annex A 5.18. |
| Strong authentication is enforced for everyone with code access | Group-level setting requiring two-factor authentication, plus SAML single sign-on and SCIM provisioning records where used | Group → Settings → General → Permissions and group features (require two-factor authentication). SAML: Settings → SAML SSO. | Two-factor enforcement is documented at group level for GitLab.com and instance level for self-managed; SAML SSO for groups and SCIM are documented as Premium and above. Maps to AICPA TSC CC6.1 and Annex A 5.17. |
| Code is analysed for security weaknesses before release | SAST job results, the vulnerability report with status and severity, and the security dashboard trend | Project → Secure → Vulnerability report; configuration at Secure → Security configuration. Job artifacts under Build → Pipelines. | SAST is documented as available in all tiers with a reduced analyser and reporting surface; the vulnerability report, security dashboard, and full SAST feature set are documented as Ultimate. Maps to AICPA TSC CC7.1 and Annex A 8.28. |
| Secrets are not committed, and leaked secrets are detected and rotated | Secret-detection job results, secret-push-protection configuration and bypass records, and the resolution status per finding | Project → Secure → Security configuration → Secret detection; findings in the pipeline security tab or the vulnerability report. | Secret detection is documented as available in all tiers with reporting depth tier-dependent; secret push protection is documented as Ultimate. Maps to AICPA TSC CC6.1 and Annex A 8.24. |
| Known-vulnerable dependencies and base images are identified and remediated | Dependency-scanning and container-scanning results, the dependency list per project, and remediation or acceptance status per finding | Project → Secure → Dependency list; Secure → Vulnerability report filtered by scanner; configuration at Secure → Security configuration. | Dependency scanning, container scanning, and the dependency list are documented as Ultimate. Maps to AICPA TSC CC7.1 and Annex A 8.8 and 8.28. |
| Running applications are tested from the outside | DAST job results and their findings history | Project → Secure → Security configuration → DAST; findings in the vulnerability report. | Documented as Ultimate. Maps to AICPA TSC CC7.1. Complements, and does not replace, a third-party penetration test — see the penetration-testing page in this cluster. |
| Deployments to production are approved and recorded | Protected environments with approval rules, deployment approval records, and the environment deployment history | Project → Settings → CI/CD → Protected environments; history at Operate → Environments. | Protected environments are documented as Premium and above, with multi-approval deployment approvals on Premium and Ultimate. Maps to AICPA TSC CC8.1 and Annex A 8.32. |
| Control coverage is tracked against a named framework | Compliance frameworks applied to projects, compliance centre status, and the compliance standards adherence report | Group → Secure → Compliance centre; framework definition at Group → Settings → General → Compliance frameworks. | Compliance frameworks are documented as Premium and above; the compliance centre reports and adherence dashboards are documented as Ultimate. Maps to AICPA TSC CC4.1 monitoring. Not a certification and not an auditor's opinion. |
Legal requirement, guidance, best practice, or our recommendation
A GitLab setting is not required by statute because it is sensible. Record the reason each control exists, so the set survives a change of owner. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirement 6.2 asks that bespoke and custom software be developed securely, including review before release to production. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not mandate GitLab, approval rules, or any particular tool, and does not apply outside cardholder-data scope. |
| AICPA TSC CC8.1 requires authorised, tested, approved, and documented change. | Attestation criteria, applying because you sought a SOC 2 report or a contract requires one. | Does not name merge requests, a number of approvers, or a scan policy. Those are your design. |
| ISO/IEC 27001:2022 Annex A 8.28 secure coding and 8.32 change management. | Certification requirement where you seek or hold certification. | Does not require dependency scanning as a purchased capability, and does not make an uncertified organisation non-compliant with anything. |
| NIST SSDF (SP 800-218) practices for code review, component verification, and archiving release artifacts. | Regulatory and standards guidance; binding on some US federal software suppliers through separate acquisition authority. | Does not become a legal obligation because a policy cites it. |
| Prevent author approval, require at least one approval from an eligible approver who did not commit, and require the pipeline to succeed before merge. | Industry best practice, widely expected by auditors as a matter of practice. | Does not appear as a numbered requirement in the criteria above, and one approver does not automatically satisfy a segregation-of-duties assertion. |
| Export the merged-merge-request population and the audit events for the period at the start of the audit, and record who produced each export. | ShipReady Metrics recommendation. | Does not make the control effective by itself, and is not required by any framework named here. |
When a capability is tier-gated
Much of GitLab's security-scanning and compliance surface is Ultimate-gated, and several change-control settings need Premium. A control you cannot enable is a control you cannot evidence, so decide deliberately rather than by omission. Last verified 10 September 2026 against GitLab's public documentation, which is the authority on current tier gating.
- Buy the tier, and evidence the control from the native GitLab artifact. Simplest, and the artifact is one export.
- Substitute an open or third-party scanner as a pipeline job and evidence it from the job artifacts and the scanner's own report. Record the substitution in the control description.
- Accept the gap explicitly, with a risk decision, an owner, and a revisit date. A documented gap is defensible; an unexplained absence is not.
- Do not claim a control because GitLab lists the feature. Evidence is what your instance shows, in the period, for the projects in scope.
- On self-managed instances, check whether the artifact you need is an instance-level admin export rather than a group-level one, and record who can produce it.
Checklist
A question list for the GitLab side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Can we produce the complete list of groups and projects in audit scope, and does each have the protection we claim?
- Are protected branches configured, and is approval enforced by an approval rule, an approval policy, or neither?
- Can an author approve or merge their own change anywhere in scope, and can we show that setting for every project?
- Can we export every merge into protected branches for the period, with approver identities and timestamps, as one population?
- Are audit events available on our tier for the events we rely on, and are they exported before the retention window closes?
- Is two-factor authentication enforced at group or instance level rather than left to individuals?
- For each scanner we claim, is it included in our tier or Ultimate-gated, and do we hold that tier?
- Are vulnerability-report findings dispositioned with a named decision, or is the report simply growing?
- Do protected environments require an approver other than the change author for production deployments?
- Does every artifact above have a named owner and a refresh cadence?
What to do now
Ordered so the most-requested artifacts become producible first. None of these steps is a legal determination, and none files anything with an auditor.
- Fix the project scope list first. The common GitLab evidence failure is a project in scope that nobody applied the group standard to.
- Push protection and approval configuration up to the group level so the evidence is one artifact rather than one per project.
- Export the merged-merge-request population and the audit events for the current period now, into your evidence repository, with the export date and the person who ran it.
- Decide the tier question explicitly for dependency scanning, container scanning, and DAST: buy, substitute in the pipeline, or record the gap.
- Turn vulnerability-report triage into a recorded disposition — remediate, schedule, or accept with a named approver — so the control has an artifact.
- Add protected environments with an approver other than the author for production, the cheapest segregation-of-duties artifact for a small team.
- If you use compliance frameworks or the compliance centre, record clearly that adherence status is an internal indicator, not certification and not an auditor's opinion.
- Re-verify GitLab's documentation for tier gating and paths annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. The GitLab integration ingests security findings. It does not configure protected branches or approval rules, does not export your audit pack, and does not file anything with an auditor.
Ingested findings are deduplicated across sources and ranked using CISA KEV membership, EPSS, and CVSS. Blast-radius search runs over captured dependencies, including transitive npm dependencies where a lockfile was fetched. First-party SAST and DAST exist in this product and complement, rather than replace, third-party penetration testing.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. That is a compliance artifact, not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion. The obligation map lists frameworks your organisation marked in-scope; that mark is not a legal opinion that a framework applies.
The GitLab connector setup guide on this site is the page for connection and least-privilege scoping. This page is the evidence layer on top of it.
Primary sources (last verified 10 September 2026)
GitLab's own documentation is the authority for every product behaviour and tier claim above; framework references are labelled by the kind of authority they carry.
GitLab documentation for protected branches, merge-request approvals and approval policies, merge checks, SAST, secret detection, dependency scanning, container scanning, DAST, the vulnerability report, protected environments, audit events, and the compliance centre. AICPA Trust Services Criteria CC4, CC6, CC7, and CC8 are professional attestation criteria. ISO/IEC 27001:2022 Annex A 5.15, 5.17, 5.18, 8.8, 8.24, 8.28 and 8.32 are certification requirements. NIST SSDF (SP 800-218) is guidance. PCI DSS v4.0.1 Requirement 6.2 binds entities in scope through contract. Not a complete list, and not legal advice.
The GitHub checklist is the equivalent map for GitHub-hosted code. The CI/CD, change-management, and dependency pages in this cluster cover the pipeline and supply-chain sides in depth.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of GitLab artifacts to control assertions, with framework references labelled by the kind of authority they carry. Whether SOC 2, ISO/IEC 27001, PCI DSS, or any statute applies to your organisation is a legal and commercial question for counsel and your contracts. This page does not determine YOUR obligations and does not file anything with an auditor.
Which GitLab tier do we need for audit evidence?
There is no single answer, and no framework names a tier. Protected branches and basic merge checks are documented as available in all tiers; configurable approval rules and audit events are documented as Premium and above; dependency scanning, container scanning, DAST, the vulnerability report, and the compliance centre reports are documented as Ultimate. Read GitLab's current documentation and decide per control: buy, substitute in the pipeline, or record a gap.
Do GitLab compliance frameworks make us compliant?
No. Applying a compliance framework label to a project and reading an adherence report is an internal tracking mechanism. It is not certification, not a SOC 2 report, and not an auditor's opinion. Treat it the way you would treat any internal dashboard: useful for finding gaps, not evidence that a control operated effectively over a period.
Is GitLab's own SAST enough, or do we still need a penetration test?
They answer different questions. Automated SAST, secret detection, and DAST cover breadth and repeatability across every pipeline run. A manual penetration test covers logic flaws, chained abuse, and business-context weaknesses that scanners do not model. Where PCI DSS v4.0.1 Requirement 11.4 applies, testing obligations are explicit. See the penetration-testing page in this cluster.
Does the ShipReady GitLab integration change our GitLab settings?
No. It ingests security findings, deduplicates them across sources, and ranks them using KEV, EPSS, and CVSS. It does not configure protected branches, approval rules, or scanners, does not open merge requests, does not export your audit pack, and does not file with an auditor. Enforcement stays in GitLab, owned by your team.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.