GitLab 01 🦊 Introduction to GitLab and the DevSecOps Platform - KandZ

⏱️ Estimated read: 10 min | |

GitLab began as an open-source project in 2011, started by a single commit with the goal of improving collaboration among team members . Over a decade later, it has evolved into an intelligent orchestration platform that brings development, security, and operations together into a single application . The core premise is simple but ambitious: instead of stitching together a dozen separate tools for planning, source control, CI/CD, security scanning, and monitoring, a team uses one platform that covers the entire software development lifecycle . The “DevSecOps” label is not marketing—it describes a structural shift where security is embedded into every stage of the pipeline rather than bolted on at the end.

Key point: GitLab is a single application for the entire DevSecOps lifecycle. It combines source code management, CI/CD, security scanning, and project planning into one platform, eliminating the integration overhead of a fragmented toolchain.

Why GitLab and DevSecOps exist

The toolchain fragmentation problem. A traditional software team uses one tool for issue tracking (Jira), another for source control (GitHub or Bitbucket), another for CI/CD (Jenkins or CircleCI), another for security scanning (Snyk or SonarQube), and yet another for monitoring. Each integration point is a failure surface. Each tool has its own authentication, its own permissions model, and its own billing. GitLab’s answer is consolidation: one application, one permission model, one bill . The benefit is not just cost—it is visibility. A merge request shows the code diff, the pipeline results, the security findings, and the deployment status in a single view.

The late-security problem. In a traditional DevOps workflow, security is a gate at the end of the pipeline. The code is written, tested, built, and then scanned. If a vulnerability is found, the fix requires reopening the development cycle, re-running the tests, and re-deploying. The cost of a fix at this stage is dramatically higher than a fix at the point of code creation. DevSecOps is the response: shift security left, so that static analysis, dependency scanning, and secret detection run on every commit, not just before release . GitLab implements this directly in the merge request: a vulnerability in a dependency appears as a failed check before the code can be merged.

The platform evolution. GitLab’s own history reflects the platform it sells. The project started in 2011, added CI in 2012, became a company in 2014, and went public on NASDAQ in 2021 . The monthly release cadence—the 22nd of every month—has been continuous for over 177 releases . This cadence matters for the exam: GitLab ships features frequently, and the documentation for a given version may differ from the documentation for the next. The platform is not static.

The enterprise focus. GitLab began as an open-source alternative to GitHub, but it deliberately pivoted toward enterprise needs. The key differences are self-managed deployment (on-premises or private cloud), multiple authentication levels, group-level milestones, and a permission model that scales to large organizations . GitHub is optimized for open-source hosting. GitLab is optimized for organizations that need to run their own instance and control every layer of the stack.

The trade-off. Consolidation means that GitLab does many things well but may not be the absolute best at any single one. A specialized security tool might have deeper vulnerability detection. A specialized CI tool might have more advanced pipeline features. The trade-off is integration: the specialized tool requires integration work, and the integration work is where friction, failures, and security gaps appear. GitLab’s bet is that “good enough at everything, in one place” beats “best at one thing, integrated with five others.”

a. The single application architecture

GitLab is delivered in three forms: GitLab.com (the hosted SaaS), GitLab Self-Managed (the on-premises installation), and GitLab Dedicated (a single-tenant hosted option) . The codebase is the same. The features are the same. The difference is where it runs and who manages the infrastructure.

The architecture is a Ruby on Rails application with a PostgreSQL database, Redis for caching and background jobs, and a Git repository layer. The CI/CD runners are separate processes that pick up jobs from the coordinator and execute them. This separation means the platform can be scaled by adding runners without scaling the core application.

The permission model is hierarchical: instance-level (administrators), group-level (owners, maintainers), and project-level (developers, reporters, guests). The hierarchy mirrors organizational structures. A group can contain subgroups, and a subgroup can contain projects. Permissions inherit downward, and the inheritance can be overridden at each level.

b. The DevSecOps lifecycle in GitLab

The platform covers ten stages of the software development lifecycle. The exam does not require memorizing all ten, but it does require understanding the categories: manage (planning, issues, boards), plan (epics, milestones), create (source code, merge requests), verify (CI, testing), secure (SAST, DAST, dependency scanning), package (container registry, package registry), release (releases, environments), configure (infrastructure as code), monitor (metrics, alerts), and defend (security dashboards) .

The security features are the “Sec” in DevSecOps. Static Application Security Testing (SAST) analyzes source code for vulnerabilities before it is compiled. Dependency Scanning checks third-party libraries against known vulnerability databases. Container Scanning checks Docker images for CVEs. Secret Detection scans commits for API keys and passwords. Infrastructure as Code (IaC) Scanning checks Terraform and Kubernetes manifests for misconfigurations . Each of these runs as a CI job, and the results appear in the merge request and the security dashboard.

The gitlab-ci.yml file is the configuration mechanism. It defines the pipeline stages, the jobs within each stage, and the scripts that each job runs. The security scanners are typically included as templates: include: template: SAST.gitlab-ci.yml. The template adds the job, the scanner runs, and the results are uploaded as a report artifact that GitLab parses.

c. GitLab versus GitHub: the positioning

The exam may test the distinction between GitLab and GitHub. The positioning is not about feature parity—both have source control, issues, and CI. The distinction is about focus. GitHub is the default for open-source hosting and community-driven projects. GitLab is the default for organizations that need a self-managed platform with integrated security and compliance features .

The key enterprise features that GitLab emphasizes are: self-managed deployment, LDAP and SAML integration, audit logs, multiple approval rules, and the security scanning suite. GitHub Enterprise offers some of these, but GitLab’s pitch is that the entire lifecycle is covered in one application, whereas GitHub relies on integrations and marketplace apps for security scanning and some CI features.

The exam does not ask which is “better.” It asks what GitLab is, what DevSecOps means, and how the platform implements it. The answer is: a single application that integrates security into every stage of the pipeline, from the first commit to the production deployment.

Complete Example Session

# ============================================
# PART 1: IDENTIFY THE PLATFORM
# ============================================

# GitLab is a DevSecOps platform.
# It covers the entire software development lifecycle.

# ============================================
# PART 2: THE THREE DEPLOYMENT MODELS
# ============================================

# GitLab.com         → hosted SaaS
# GitLab Self-Managed → on-premises installation
# GitLab Dedicated   → single-tenant hosted

# ============================================
# PART 3: THE DEVSECOPS STAGES
# ============================================

# Manage → Plan → Create → Verify → Secure
# → Package → Release → Configure → Monitor → Defend

# ============================================
# PART 4: SECURITY FEATURES
# ============================================

# SAST            → static analysis of source code
# Dependency Scan → known CVEs in libraries
# Container Scan  → CVEs in Docker images
# Secret Detection → API keys and passwords
# IaC Scan        → misconfigured Terraform/K8s

# ============================================
# PART 5: THE CI/CD CONFIGURATION
# ============================================

# .gitlab-ci.yml
# stages:
#   - build
#   - test
#   - deploy

# ============================================
# PART 6: THE MERGE REQUEST VIEW
# ============================================

# The merge request shows:
# - Code diff
# - Pipeline status
# - Security findings
# - Deployment readiness

# ============================================
# PART 7: THE PERMISSION HIERARCHY
# ============================================

# Instance → Group → Subgroup → Project
# Permissions inherit downward.

# ============================================
# PART 8: THE MONTHLY RELEASE CADENCE
# ============================================

# New version on the 22nd of every month.
# 177 consecutive monthly releases as of 2026.

# ============================================
# PART 9: GITLAB VERSUS GITHUB
# ============================================

# GitHub: open-source hosting, community focus
# GitLab: enterprise, self-managed, integrated security

The nine parts trace the platform: identity, deployment models, lifecycle stages, security features, CI configuration, merge request integration, permission model, release cadence, and competitive positioning.

Quick Reference

Deployment Models

Model	Description
GitLab.com	Hosted SaaS
GitLab Self-Managed	On-premises
GitLab Dedicated	Single-tenant hosted

DevSecOps Stages

Stage	Purpose
Manage	Planning, issues
Plan	Epics, milestones
Create	Source code, merge requests
Verify	CI, testing
Secure	SAST, DAST, scanning
Package	Container/package registry
Release	Releases, environments
Configure	Infrastructure as code
Monitor	Metrics, alerts
Defend	Security dashboards

Security Features

Feature	What It Scans
SAST	Source code
Dependency Scanning	Third-party libraries
Container Scanning	Docker images
Secret Detection	Commits for credentials
IaC Scanning	Terraform, Kubernetes

Best Practices

✅ Do This:

# Use the merge request security view
<!-- Security findings appear before merge -->        # ✅

# Include security templates in .gitlab-ci.yml
<!-- SAST and dependency scanning run automatically --> # ✅

# Understand the permission hierarchy
<!-- Instance → Group → Project inheritance -->       # ✅

❌ Don’t Do This:

# Treat security as a final gate
<!-- DevSecOps embeds it at every stage -->           # ❌

# Assume GitLab and GitHub are interchangeable
<!-- Different focus: enterprise vs community -->     # ❌

# Ignore the monthly release cadence
<!-- Features may differ between versions -->         # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Security findings missed	Scanners not included in CI	Add templates to `.gitlab-ci.yml`
Permission confusion	Hierarchy not understood	Trace from project to group to instance
Version mismatch	Documentation differs by release	Check the docs for the specific version
Self-managed deployment fails	Missing dependencies	Use the Omnibus package or Helm chart

Real-World Examples

1. Hosted Platform

GitLab.com → hosted SaaS

2. Self-Managed

GitLab Self-Managed → on-premises

3. SAST Template

include:
  - template: Jobs/SAST.gitlab-ci.yml

4. Dependency Scanning

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

5. Secret Detection

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

6. Container Scanning

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

7. Permission Level

Project → Group → Instance

8. Release Cadence

22nd of every month

9. Security Dashboard

Secure → Security dashboard

10. Merge Request View

Code diff + pipeline + security findings

Visual

The DevSecOps Lifecycle

┌──────────────────────────────────────────────┐
│  MANAGE → PLAN → CREATE → VERIFY → SECURE    │
│                                              │
│  ┌────────────────────────────────────────┐  │
│  │  Security is embedded in every stage   │  │
│  │  SAST, dependency scanning, secrets    │  │
│  └────────────────────────────────────────┘  │
│                                              │
│  PACKAGE → RELEASE → CONFIGURE → MONITOR     │
│  → DEFEND                                    │
└──────────────────────────────────────────────┘

Single Application vs Toolchain

┌──────────────────────────────────────────────┐
│  TRADITIONAL TOOLCHAIN                       │
│  Jira + GitHub + Jenkins + Snyk + Datadog    │
│  → 5 integrations, 5 auth models, 5 bills    │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  GITLAB                                      │
│  Plan + Code + CI + Security + Monitor       │
│  → 1 application, 1 auth model, 1 bill       │
└──────────────────────────────────────────────┘

Summary

Item	Value
Founded	2011, open-source project
Public	NASDAQ: GTLB (2021)
Platform type	DevSecOps, single application
Deployment models	GitLab.com, Self-Managed, Dedicated
Release cadence	Monthly (22nd)
Core security	SAST, dependency, container, secret, IaC
Permission hierarchy	Instance → Group → Project
Competitive focus	Enterprise, self-managed vs GitHub

Key takeaways:

GitLab is a single application for the entire DevSecOps lifecycle. It replaces the fragmented toolchain with one platform that covers planning, source control, CI/CD, security, and monitoring .
DevSecOps embeds security at every stage. SAST, dependency scanning, container scanning, secret detection, and IaC scanning run automatically in the pipeline, not as a final gate .
The platform is delivered in three models. GitLab.com (hosted), Self-Managed (on-premises), and Dedicated (single-tenant hosted) .
The permission model is hierarchical. Instance administrators, group owners, and project maintainers inherit permissions downward. The hierarchy mirrors organizational structures.
GitLab and GitHub have different focuses. GitHub is optimized for open-source hosting and community. GitLab is optimized for enterprise, self-managed deployment, and integrated security .

Remember: GitLab is not just a Git host. It is a DevSecOps platform that covers the entire software development lifecycle in a single application. The security features are not add-ons—they are integrated into the merge request, the pipeline, and the dashboard. The exam tests the conceptual model: what DevSecOps means, how GitLab implements it, and how the single-application approach differs from a fragmented toolchain.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!