Infrastructure

GitLab security operations

Security controls, evidence, and shared responsibilities for managed GitLab

GitLab security operations

This page supports the GitLab platform option under Managed Git Server. GitLab security is a shared operating model. Assistance can operate the agreed GitLab platform boundary, harden the runtime, document controls, and collect provider evidence. The customer remains responsible for repository content, user approvals, data classification, release decisions, runner trust decisions, and legal or compliance conclusions unless a broader agreement says otherwise.

This page describes the security topics that should be confirmed before Assistance operates a GitLab environment. It avoids blanket certification claims because evidence depends on the selected deployment model, provider, region, and support contract.

Security scope#

AreaAssistance can operate or supportCustomer owns
Platform runtimeInstallation, configuration, upgrades, backups, monitoring, and platform incident triageBusiness priority, accepted downtime, product communication, and provider-account approval
Identity and accessSSO/SAML/LDAP integration support, role recommendations, service-account design, and audit-log visibilityIdentity source of truth, user approvals, privileged-access reviews, and offboarding decisions
Repository and CI boundaryProtected-branch guidance, runner isolation planning, secret-exposure review, and evidence collectionRepository content, merge policy decisions, CI/CD workflow logic, and application secrets
Network and TLSDNS/TLS setup, firewall recommendations, private access patterns, and monitoringNetwork policy approval, allowlists, VPN/private-link decisions, and risk acceptance
EvidenceRunbooks, change records, backup notes, access model, monitoring links, and provider evidence inventoryLegal, regulatory, procurement, and audit conclusions based on the evidence

Controls to confirm during onboarding#

Identity and access#

  • Which identity provider is authoritative for GitLab users.
  • Whether SAML, LDAP, OAuth, SCIM, MFA, or local accounts are in scope.
  • Who approves owners, administrators, maintainers, deploy keys, and service accounts.
  • How break-glass access is requested, logged, reviewed, and removed.

Repository and pipeline protection#

  • Protected branches, required approvals, code-owner rules, and merge restrictions.
  • Secret handling for CI variables, protected variables, deploy tokens, and masked values.
  • Runner labels, tags, executors, and environment separation.
  • Cache, artifact, package, and container-registry retention rules.

Network and runtime security#

  • Public, VPN, private-network, or allowlisted access model.
  • DNS and TLS ownership, certificate renewal path, and redirect behavior.
  • Firewall rules, ingress points, outbound access, and dependency mirrors.
  • Patch and upgrade cadence for GitLab, operating system, database, Redis, object storage, and runners.

Backups and recovery#

  • Repository, database, LFS, artifacts, packages, container registry, and configuration backup coverage.
  • Backup location, encryption approach, retention, deletion process, and access control.
  • Restore validation cadence and evidence.
  • Recovery point and recovery time targets that match the selected topology and support plan.

Provider evidence#

When GitLab runs in a customer cloud, Assistance-managed environment, or partner-hosted service, keep provider claims tied to current evidence. Useful artifacts include:

ArtifactWhy it matters
Data Processing Agreement and subprocessor listHelps customer privacy teams assess processing roles and provider chain
Region and backup-location documentationSupports residency and business-continuity review
Security certificates or audit summariesShows provider controls when certificates are current and in scope
Technical and organizational measuresDocuments encryption, access control, logging, incident response, and physical security
Penetration-test or vulnerability-summary evidenceSupports risk review when shared under the provider's disclosure rules
Incident notification and support termsDefines escalation path, notification timing, and support availability

Assistance can help collect and organize these artifacts, but it does not certify a customer environment unless that work is explicitly contracted and evidenced.

Monitoring and incident response#

A production GitLab runbook should define:

  • health checks for web, SSH, background jobs, database, Redis, object storage, and runners;
  • alert thresholds for storage growth, queue depth, failed backups, certificate expiry, and error rates;
  • severity definitions, communication cadence, escalation contacts, and customer decision owners;
  • evidence preservation for suspected compromise, data loss, or unauthorized access;
  • post-incident notes with cause, impact, recovery actions, and follow-up work.

Response times and coverage hours are support-plan terms. Do not assume 24/7 coverage, emergency-only access, or regulated incident commitments unless they are written into the agreement.

Not included by default#

  • Formal compliance certification or legal attestation for the customer environment
  • Unlimited user administration or access-review ownership
  • Rewriting application pipelines unrelated to platform security
  • Guaranteeing availability for unassessed integrations, runners, or customer-controlled networks
  • Provider-account ownership, procurement decisions, or insurance obligations

Getting started#

Request a GitLab security assessment with your deployment model, identity provider, repository scope, runner model, compliance drivers, and current evidence. Assistance will confirm the operating boundary before making production-impacting changes.

Request GitLab security assessment →