From git push to a signed, verified deployment on GitLab

Most CI/CD tutorials stop when the tests turn green. Real companies need more: they need to know what they ship, that nobody slipped a secret or a vulnerable library into it, and that the thing running in production is exactly the thing the pipeline built. That is what DevSecOps means in practice: security checks woven into the delivery pipeline instead of a review at the end.

This course follows a small but complete project, devsecops-gitlab-lab. It contains a tiny Python web API (Flask), a Dockerfile, and a .gitlab-ci.yml file that turns every push into the journey drawn above. Every screenshot comes from that project on GitLab.com, and every file you read here is the real file in the repository.

Three ways to use this course

How to read the tier labels

GitLab comes in three tiers. Everything this lab needs works in Free. Some features need Premium (team governance: mandatory approvals, code owners, protected environments, merge trains) or Ultimate (consolidated security: vulnerability report, security widget in merge requests, dependency scanning, security policies). Every feature sheet tells you which tier it needs, because in real companies that decides what you can actually use.

GitLab describes itself as one application for the whole DevSecOps lifecycle: code, tickets, CI/CD, registries, security, deployment and monitoring live in the same product. That is its biggest difference with GitHub, which relies more on apps and third-party actions. For a learner it is good news: everything you need is in one place, behind one left sidebar.

The building blocks

How the pieces talk to each other

1. You push a branch and open a merge request.
2. GitLab reads .gitlab-ci.yml and creates a pipeline for that event.
3. Runners pick up the jobs, run them in containers and send back logs, reports and artifacts.
4. The merge request shows the result: tests, scans, approvals. A reviewer merges.
5. The merge to main starts another pipeline, which builds, signs and deploys.

GitLab moved almost all navigation into the left sidebar. The top bar keeps search, quick creation, your counters and your avatar; a column on the far right opens GitLab Duo. Click the numbered dots on the screenshot to see what each element does.

The + button

The menu is contextual: the first block creates things inside the project you are looking at, the second block creates things globally.

The avatar menu

The left sidebar is the map of GitLab. Its sections follow the lifecycle: plan, code, build, secure, deploy, operate, monitor, analyze. Here is each one, opened on the lab project.

Plan and Code

Build, Secure and Deploy

Build holds the CI features you will meet in stations 5 to 9. Secure holds the scanners (station 10). Deploy holds what the pipeline publishes:

Manage and AI

Manage is where members and labels live (seen above). AI lists the agents enabled in the project; station 14 covers them.

Operate, Monitor, Analyze and Settings

The Code button

The merge request is where code review, automated checks and decisions meet. In the lab, merge request !1 comes from the branch feature/nouveau-message ("new message") and changes the API message. Its description was filled in automatically by a template.

The lab's templates and owners, as they are in the repository

## What / why

Closes #

## DevSecOps checklist
- [ ] Tests added or updated
- [ ] No secret in the code
- [ ] Images and includes pinned
- [ ] Pipeline green

/assign me

## What is happening?

## Steps to reproduce

## Pipeline link (if relevant)

/label ~bug

# CODEOWNERS sections: enforced with "Require approval from code owners" on a protected branch (Premium and Ultimate)
[CI]
.gitlab-ci.yml @georges.momo.n8n
.gitlab/ @georges.momo.n8n

[Application]
app/ @georges.momo.n8n
Dockerfile @georges.momo.n8n

Why one push can create two pipelines

When a branch has an open merge request, a push is two events at once: a push to a branch, and an update to a merge request. Without care, GitLab creates a branch pipeline and a merge request pipeline for the same commit, which doubles your compute minutes. The lab's workflow:rules (station 6) keeps only the merge request pipeline:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"   # merge request pipeline
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS    # avoids the duplicate branch + MR pipeline
      when: never

One file at the root of the repository, .gitlab-ci.yml, describes everything. On every event (push, merge request, tag, schedule, API call, button click) GitLab reads that file, builds a pipeline, and runners come and fetch the jobs one by one.

1. An event happens. A push, a merge request update, a tag, a schedule, an API call. GitLab records it as CI_PIPELINE_SOURCE.
2. workflow:rules decides whether a pipeline is created at all for that event.
3. Each job's rules decide whether that job is added to the pipeline.
4. Stages run in order. By default a stage waits until every job of the previous stage is finished; jobs inside a stage run in parallel. needs can break that barrier (station 6).
5. A runner polls GitLab ("any job for me?"), starts the job's container from its image, plus side containers called services, runs the script, and sends back the log and the artifacts.

The keywords that matter

Cache or artifact? Sort them

Rules: the first match wins

rules are read from top to bottom, and the first rule whose condition is true decides. If it says when: never, the job (or with workflow:rules, the whole pipeline) is dropped. If no rule matches at all, the job is not added. That single sentence explains most "why didn't my job run?" questions.

Stages versus a graph with needs

Without needs, a stage is a barrier: the lab's build would wait for the slow SAST job in the test stage, although the image does not depend on it. With needs: [lint, test], build starts the moment lint and both test jobs are done. GitLab calls the result a DAG (directed acyclic graph).

stage lint    lint
stage test    test [3.12]   test [3.13]   semgrep-sast (slow)   secret_detection
              ---- barrier: everything above must finish ----
stage build   build

lint ──┐
test ──┴──> build ──┬──> trivy_gate ──┬──> sign ──> deploy_staging ──> deploy_production (manual)
                    └──> container_scanning  │
semgrep-sast, secret_detection run alongside and do not block build
pages needs: [] and starts immediately

Reusing configuration

At company scale, nobody writes a pipeline from scratch. Four mechanisms help, from the most local to the most shared:

docs_check:
  stage: lint
  image: alpine:3.22
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes: [docs/**/*]
  script:
    - echo "run your link checker here"

The goal of the lab: every push builds an image, scans it, signs it without managing any key, deploys it to a short-lived environment and checks that it answers. Here is what is in the project.

Step 1: the application and its tests

"""Mini API du labo DevSecOps.

Modifie MESSAGE ou VERSION, pousse sur main : le pipeline
build -> scan -> signe -> deploie automatiquement.
"""

import os

from flask import Flask, jsonify

VERSION = os.environ.get("APP_VERSION", "1.0.0")
MESSAGE = "Hello from GitLab CI DevSecOps lab!"

app = Flask(__name__)


@app.get("/")
def index():
    return jsonify(message=MESSAGE, version=VERSION)


@app.get("/healthz")
def healthz():
    return jsonify(status="ok")


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=int(os.environ.get("PORT", "8080")))

from app import app


def test_index():
    client = app.test_client()
    res = client.get("/")
    assert res.status_code == 200
    assert "message" in res.get_json()


def test_healthz():
    client = app.test_client()
    res = client.get("/healthz")
    assert res.status_code == 200
    assert res.get_json() == {"status": "ok"}

flask==3.1.3
# Deliberately old version (known CVE): the scanners report it -> exercise in the course
gunicorn==22.0.0

/healthz is a health check endpoint: the deployment calls it to decide whether the new version is alive. The version comes from the APP_VERSION environment variable, which the pipeline sets to the commit SHA, so you can always tell which build is answering.

Step 2: the Dockerfile

# syntax=docker/dockerfile:1
# ---------- Stage 1: build the dependencies ----------
FROM python:3.13-slim AS build1
WORKDIR /src
COPY app/requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt2

# ---------- Stage 2: minimal final image ----------
FROM python:3.13-slim
LABEL org.opencontainers.image.source="https://gitlab.com/georges.momo.n8n/devsecops-gitlab-lab" \
      org.opencontainers.image.description="GitLab CI DevSecOps lab" \
      org.opencontainers.image.licenses="MIT"

# Non-root user (security best practice, checked by the scanners)
RUN useradd --create-home --uid 10001 appuser3
WORKDIR /app
COPY --from=build /install /usr/local4
COPY app/app.py .

ARG APP_VERSION=dev
ENV APP_VERSION=${APP_VERSION} PORT=8080 PYTHONUNBUFFERED=1 PYTHONDONTWRITEBYTECODE=1
USER 100015
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s CMD python -c "import urllib.request,sys; urllib.request.urlopen('http://127.0.0.1:8080/healthz'); sys.exit(0)"6
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "--workers", "2", "app:app"]7

1. A multi-stage build: the first stage installs dependencies, the second copies only the result. Build tools never reach the final image.
2. Packages are installed into /install so they can be copied in one line.
3. A dedicated user with a fixed uid. Scanners and Kubernetes policies flag images that run as root.
4. Only the installed packages and app.py reach the final image; tests and dev tools are excluded (see also .dockerignore).
5. From here on, the container runs as uid 10001: a compromised app cannot modify system files.
6. Docker itself can check the container's health with the same endpoint the pipeline uses.
7. A production web server (gunicorn) instead of Flask's development server.

Step 3: write and check the pipeline in the editor

1. Create the project: +, New project/repository, Create blank project. Untick "Initialize repository with a README" if you are pushing existing code.
2. Open Build, Pipeline editor. It validates the syntax as you type and offers Visualize, Validate and Full configuration.
3. Commit from the field at the bottom, either straight to main or to a new branch with a merge request. The pipeline starts immediately.

Step 4: read .gitlab-ci.yml block by block

# GitLab DevSecOps pipeline: lint -> tests -> SAST/secrets -> build -> scan -> SBOM -> signature -> deployment -> verification
# GitLab twin of the GitHub Actions lab (georgesmomo/devsecops-actions-lab).
# Interactive course: see docs/index.html (published by the "pages" job at the end of this file).

workflow:1
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"   # merge request pipeline
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS    # avoids the duplicate branch + MR pipeline
      when: never
    - if: $CI_COMMIT_BRANCH                                # push to a branch
    - if: $CI_COMMIT_TAG                                   # tag v1.2.3
  auto_cancel:
    on_new_commit: interruptible                           # cancels interruptible jobs of an older commit

stages: [lint, test, build, scan, sign, deploy]2

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA3
  PIP_CACHE_DIR: $CI_PROJECT_DIR/.cache/pip

include:4
  - local: .gitlab/ci/templates.yml                    # hidden jobs (.python, .docker, .deploy) reused with extends
  - template: Jobs/SAST.gitlab-ci.yml                  # SAST (Semgrep) - Free: JSON report
  - template: Jobs/Secret-Detection.gitlab-ci.yml      # finds secrets committed to the history
  - template: Jobs/Container-Scanning.gitlab-ci.yml    # scans the image (Trivy)

# ---------- Quality ----------
lint:
  extends: .python
  stage: lint
  script:
    - ruff check app
    - ruff format --check app

test:
  extends: .python
  stage: test
  image: python:${PY}-slim
  parallel:5
    matrix:
      - PY: ["3.12", "3.13"]                           # 2 generated jobs
  script:
    - cd app && pytest --junitxml=report.xml
  artifacts:
    when: always
    expire_in: 1 week
    reports:
      junit: app/report.xml                            # pipeline Tests tab6

# ---------- Image ----------
build:
  extends: .docker
  stage: build
  needs: [lint, test]
  script:
    - docker build --build-arg APP_VERSION="$CI_COMMIT_SHORT_SHA" --label org.opencontainers.image.revision="$CI_COMMIT_SHA" -t "$IMAGE" .
    - docker push "$IMAGE"
    - DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE" | cut -d@ -f2)
    - echo "IMAGE_DIGEST=$DIGEST" >> build.env
    - echo "Image published $CI_REGISTRY_IMAGE@$DIGEST"
  artifacts:
    reports:
      dotenv: build.env                                # IMAGE_DIGEST becomes a variable in later jobs7

container_scanning:                                    # overrides the job provided by the template8
  stage: scan
  needs: [build]
  variables:
    CS_IMAGE: $IMAGE

trivy_gate:
  stage: scan
  needs: [build]
  image:
    name: aquasec/trivy:0.76.0
    entrypoint: [""]
  variables:
    TRIVY_USERNAME: $CI_REGISTRY_USER
    TRIVY_PASSWORD: $CI_REGISTRY_PASSWORD
  script:
    - trivy image --exit-code 1 --severity CRITICAL --ignore-unfixed "$IMAGE"          # security gate9
    - trivy image --format cyclonedx --output sbom.cdx.json "$IMAGE"                   # SBOM
  artifacts:
    paths: [sbom.cdx.json]
    reports:
      cyclonedx: sbom.cdx.json10
    expire_in: 30 days

# ---------- Supply chain ----------
sign:
  stage: sign
  image: alpine:3.22
  needs: [build, trivy_gate]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG
  id_tokens:11
    SIGSTORE_ID_TOKEN:                                 # GitLab OIDC token, read automatically by cosign
      aud: sigstore
  before_script:
    - apk add --no-cache cosign
    - cosign login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - cosign sign --yes "$CI_REGISTRY_IMAGE@$IMAGE_DIGEST"

# ---------- Deployment ----------
deploy_staging:
  extends: .deploy
  needs: [build, sign]
  environment:
    name: staging
    deployment_tier: staging
    url: $CI_PROJECT_URL/container_registry
  resource_group: staging                              # only one staging deployment at a time12

deploy_production:
  extends: .deploy
  needs: [build, sign, deploy_staging]
  when: manual                                         # Play button: human approval13
  environment:
    name: production
    deployment_tier: production
    url: $CI_PROJECT_URL/container_registry
  resource_group: production

# ---------- Course website ----------
# GitLab Pages publishes whatever a job named "pages" leaves in public/ as an artifact.
# needs: [] starts it at once, without waiting for the other stages: the course does not depend on the image.
pages:14
  stage: deploy
  image: busybox:1.37
  needs: []
  script:
    - rm -rf public && cp -r docs public               # the course lives in docs/, Pages serves public/
  artifacts:
    paths: [public]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH      # publish only from the default branch

1. workflow: one pipeline per event, never a duplicate branch plus merge request pipeline; jobs marked interruptible of an older commit are cancelled when a new commit arrives.
2. stages: the six columns, in order.
3. IMAGE: project registry plus short SHA, so every commit gets its own tag. $CI_REGISTRY_IMAGE is predefined.
4. include: one local file and three official templates, which add the jobs semgrep-sast, secret_detection and container_scanning.
5. parallel:matrix creates test: [3.12] and test: [3.13] from one definition.
6. The JUnit report feeds the pipeline's Tests tab. when: always keeps it even when tests fail, which is exactly when you need it.
7. build pushes the image, then reads its digest (the immutable fingerprint) into build.env. The dotenv report turns IMAGE_DIGEST into a variable for every job that needs: [build].
8. Overriding a template job: same name as the template's job, so these keys are merged into it (new stage, needs and image to scan).
9. The security gate: exit code 1 if a CRITICAL vulnerability that has a fix exists. This job really fails the pipeline.
10. The SBOM in CycloneDX format, published as a report and kept 30 days.
11. id_tokens gives the job an OIDC token with audience sigstore. cosign reads it from SIGSTORE_ID_TOKEN and signs without a stored key (station 8).
12. resource_group: two pipelines can never deploy staging at the same time.
13. when: manual: production waits for a human to press Play. At job level this also means allow_failure: true, so the pipeline shows Passed while production waits.
14. pages publishes docs/ as this course. needs: [] lets it start at once (station 13).

Step 5: the shared hidden jobs

# Hidden jobs (name starting with a dot): never run on their own, reused with extends.

.python:
  image: python:3.13-slim
  interruptible: true1
  cache:
    key:
      files: [app/requirements-dev.txt]               # cache key = hash of this file2
    paths: [.cache/pip]
  before_script:
    - pip install -r app/requirements-dev.txt

.docker:
  image: docker:28
  services:
    - docker:28-dind                                    # Docker-in-Docker3
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"4

.deploy:
  extends: .docker
  stage: deploy
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - apk add --no-cache cosign curl
    # Zero trust: only run the image signed by THIS pipeline of THIS project
    - cosign verify "$CI_REGISTRY_IMAGE@$IMAGE_DIGEST" --certificate-identity "${CI_PROJECT_URL}//.gitlab-ci.yml@refs/heads/${CI_COMMIT_REF_NAME}" --certificate-oidc-issuer "${CI_SERVER_URL}" > /dev/null5
    - echo "Signature verified for $CI_REGISTRY_IMAGE@$IMAGE_DIGEST"
    # Ephemeral environment: the hardened container runs inside the Docker service
    - docker run -d --name app -p 8080:8080 --read-only --tmpfs /tmp --cap-drop ALL "$CI_REGISTRY_IMAGE@$IMAGE_DIGEST"6
    - for i in $(seq 1 20); do curl -fsS http://docker:8080/healthz && break; sleep 2; done
    - curl -fsS http://docker:8080/healthz | grep -q ok7
    - curl -fsS http://docker:8080/
    - echo "Smoke test OK on $CI_ENVIRONMENT_NAME"

1. Python jobs can be cancelled safely when a newer commit arrives.
2. The cache key is a hash of the dependency file: the cache is reused until the dependencies change.
3. Docker-in-Docker: a side container that provides a Docker daemon at the hostname docker.
4. Login with the job's own registry credentials, passed on stdin so the password never appears in the process list.
5. The DevSecOps heart. Before running anything, cosign verify demands that the signature was produced by this .gitlab-ci.yml, of this project, on this branch, with GitLab as the issuer. An image pushed by hand, or signed by another project, is refused.
6. An ephemeral environment: the image runs inside the Docker service, read-only, with every Linux capability dropped.
7. The smoke test: retry /healthz for up to 40 seconds, require ok, then call /. When the job ends, everything disappears.

Scanning tells you an image looked fine when it was built. It does not tell you that the image you are about to run is that image. A tag like :latest or even :fbdd9f27 is a label someone can move to another image. A digest (sha256:…) is computed from the content itself: change one byte and the digest changes. That is why the lab passes IMAGE_DIGEST from job to job and signs and deploys image@digest.

Ride the trust chain

No private key to store, rotate or leak: the pipeline's identity is the key. It is the same principle you use to let a pipeline into AWS, Google Cloud, Azure or Vault without a stored password.

$ cosign verify registry.gitlab.com/<namespace>/devsecops-gitlab-lab@sha256:<digest> \
    --certificate-identity "https://gitlab.com/<namespace>/devsecops-gitlab-lab//.gitlab-ci.yml@refs/heads/main" \
    --certificate-oidc-issuer "https://gitlab.com"

The pipeline list

The graph, grouped by stage

Notice the test column: the two matrix jobs sit next to semgrep-sast and secret_detection, which the templates put in the test stage. Notice also that the pipeline is green while deploy_production still waits: that is the job-level when: manual at work.

The Tests tab

A job log

Environments

Secure, Security configuration lists the scanners, their state on the default branch and the tier they need. A scanner shows as Enabled because the latest pipeline on main produced a valid report for it.

Settings, CI/CD

CI/CD variables

Variable precedence: who wins?

The same variable name can be defined in many places. GitLab applies a precedence order, from strongest to weakest. Use the arrows to put the sources in the right order, then check.

Runners

Protected branches (Settings, Repository)

Merge checks (Settings, Merge requests)

The GitLab agent for Kubernetes (Operate, Kubernetes clusters)

Hardening checklist for your fork

These actions touch security and human decisions, so they are worth doing by hand once. The boxes remember your progress in this browser.

• Forbid direct pushes to main: Settings, Repository, Protected branches, main, "Allowed to push and merge" = No one.
• Turn on merge checks: Settings, Merge requests, tick "Pipelines must succeed" and "All threads must be resolved".
• Add a registry cleanup policy: Settings, Packages and registries, Cleanup policies (for example keep the 10 latest tags, remove tags older than 30 days).
• Protect and create a version tag: protect v*, then Code, Tags, New tag v1.0.0. The tag pipeline builds, scans and signs; deployments stay reserved for main.
• Schedule a weekly rebuild: Build, Pipeline schedules, cron 0 6 * * 1 on main, to catch newly published CVEs.
• Deploy production by hand: press Play on deploy_production and check Operate, Environments.

GitLab has no exact equivalent of GitHub Apps (an installable bot identity with fine permissions and short-lived tokens). It spreads that need over several building blocks. The right choice depends on who is acting and for how long.

Project access tokens

Integrations

Webhooks

The page you are reading is published by the lab's own pipeline. The course lives in docs/; a tiny job copies it into public/, and GitLab Pages serves whatever a job named pages leaves in public/ as an artifact.

pages:
  stage: deploy
  image: busybox:1.37
  needs: []1
  script:
    - rm -rf public && cp -r docs public2
  artifacts:
    paths: [public]3
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH4

1. The site does not depend on the image, so it starts immediately instead of waiting for the six stages.
2. No build step: the course is plain HTML, CSS and JavaScript. A documentation generator (MkDocs, Hugo) would run here.
3. The artifact named public is what Pages publishes.
4. Only the default branch publishes. Merge requests can still preview the site through the job's artifacts.

After the first successful run, Deploy, Pages shows the address. New projects on GitLab.com often get a unique domain such as devsecops-gitlab-lab-xxxx.gitlab.io; you can switch to namespace.gitlab.io/project on the same page, add a custom domain, or restrict access to project members.

GitLab Duo groups GitLab's AI features. Its newest part, the Agent Platform, runs agents (a role, some tools, a model) and flows (several agents chained for one task: turn an issue into a merge request, fix a pipeline, review code).

Duo Chat (right panel)

Agent Platform and the CI/CD Catalog

AI Catalog (AI, Agents)

An AI review job without a paid tier

You can ask an AI model to review a merge request from the pipeline itself. The idea is the same on GitHub: a job triggered on merge requests, an API key in a masked and protected variable, and a narrowly scoped GitLab token to post the comment. This example uses Claude Code; adapt it to your provider.

claude_review:
  stage: test
  image: node:24-alpine
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  variables:
    GIT_DEPTH: 0
  script:
    - apk add --no-cache git curl
    - npm install -g @anthropic-ai/claude-code
    - git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD > mr.diff
    # ANTHROPIC_API_KEY: masked CI/CD variable (Settings, CI/CD, Variables)
    - claude -p "Review mr.diff. List security risks and bugs in at most 10 lines." --allowedTools "Read" > review.md
    # GITLAB_REVIEW_TOKEN: token with the api scope, masked
    - |
      curl -sS --request POST --header "PRIVATE-TOKEN: $GITLAB_REVIEW_TOKEN" \
        --data-urlencode "body@review.md" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes"
  allow_failure: true

This lab has a twin: GitHub Actions DevSecOps, same app, same goals, GitHub version. If you know one platform, this table gets you productive on the other.

GitLab University offers several certifications. For what this course covers, aim for GitLab Certified CI/CD Associate, then possibly GitLab Certified Security Specialist. The format (questions, practical exam, duration, price) changes over time: check the official exam page before you register.

A two-week revision plan

1. Days 1 to 3: stations 5 and 6 again, plus every simulator answer until you predict them all.
2. Days 4 to 6: rebuild the lab's pipeline from an empty .gitlab-ci.yml in your fork, without looking.
3. Days 7 to 9: open every feature sheet that has an exam tip (use the feature index) and explain each tip aloud.
4. Days 10 to 12: do the challenges at the end of the course.
5. Days 13 and 14: take the final exam until you score above 90%, then read the official exam guide one last time.

Challenges

Each challenge extends the lab the way a real team would. Do one, push it to your fork, and you have something concrete to show.

Type a word (runner, variable, token, agent…) to filter. Click a feature to jump to its sheet.

• Search and command palette Free
  The Search or go to field: global search plus quick navigation to a project, a page or a command.
• To-Do List and counters Free
  The three counters at the top right: issues assigned to you, merge requests (assigned or waiting for your review) and your To-Do List.
• Groups and subgroups Free
  A space that contains projects and other groups, with its own members, CI/CD variables, runners and settings.
• Members and roles Free (custom roles: Ultimate)
  The people who can access a project or group, each with a role: Guest, Planner, Reporter, Developer, Maintainer, Owner.
• Profile and preferences Free
  The avatar menu: status, profile, preferences (theme, language, editor), subscription, what's new, sign out.
• Branches, commits and tags Free
  Code, Branches / Commits / Tags: the web view of the project's git history.
• Project information shortcuts Free
  The right-hand column of a project page: description, statistics and links such as Add LICENSE, Add CHANGELOG, CI/CD configuration, Environments.
• Work items (issues, tasks, epics) Free (epics: Premium)
  Plan, Work items: the project's tickets. A work item has a type (issue, task, epic, incident…), a status, assignees, labels, a milestone, a weight.
• Issue boards and milestones Free (scoped labels: Premium)
  A kanban board whose columns are labels, assignees or milestones. Milestones group tickets by due date.
• Wiki Free
  Markdown documentation stored in a separate git repository attached to the project.
• Snippets Free
  Versioned fragments of code or configuration, shared at project or personal level.
• Pipeline schedules Free
  Planned runs of the pipeline (cron) on a branch, with their own variables.
• Artifacts Free
  Files a job keeps after it ends: binaries, reports, SBOMs. Build, Artifacts lists them for the whole project.
• Audit events Premium (streaming: Ultimate)
  A log of who did what: role changes, token creation, changes to variables or protected branches.
• Releases Free
  A published version tied to a git tag, with release notes, links to binaries or images, and evidence.
• Feature flags Free
  Switches for features, managed in GitLab and compatible with Unleash SDKs.
• Package registry Free
  A built-in registry for npm, Maven, PyPI, NuGet, Composer, Conan, Helm, Go and generic packages.
• GitLab Pages Free
  Hosting for static websites produced by a pipeline job.
• Labels Free (scoped: Premium)
  Coloured tags on work items and merge requests, defined per project or per group.
• Terraform / OpenTofu states and modules Free
  An HTTP backend for Terraform state managed by GitLab, plus a module registry.
• Monitor: error tracking, alerts, incidents, Service Desk Free (advanced on-call: paid)
  Operations tools: application errors (Sentry-compatible), incoming alerts, incidents with a timeline, Service Desk (tickets by email).
• Analyze: value stream, CI/CD analytics, DORA Free (full DORA: Ultimate)
  Dashboards about the delivery flow: time per stage, pipeline success rate and duration, deployment frequency.
• Clone over SSH or HTTPS Free
  The Code menu gives clone URLs, IDE shortcuts and source downloads.
• Web IDE Free
  A VS Code editor in the browser, opened on the repository (press . or Code, Web IDE).
• Workspaces Premium
  Remote development environments (a container plus an IDE) started from GitLab in your own Kubernetes cluster.
• Merge request Free (security widget: Ultimate)
  A request to merge a source branch into a target branch, with discussion, diff, pipeline, approvals and reports.
• Merge request approvals Free (required rules: Premium)
  The Approve button and, in paid tiers, mandatory approval rules (how many, who, which groups).
• CODEOWNERS Premium
  A file that maps paths to owners (people or groups), optionally in sections.
• Issue and merge request templates Free
  Markdown files offered in the Description list when you create an issue or a merge request.
• Pipelines Free
  Build, Pipelines: every run, with status, source (branch, merge request, tag), author and stages.
• rules and workflow:rules Free
  Conditions checked in order; the first one that matches decides (when, allow_failure, variables).
• needs (DAG) Free
  The list of jobs a job really depends on. It starts as soon as they finish, without waiting for its whole stage.
• include, extends and hidden jobs Free
  Ways to reuse configuration: assemble files (include) and inherit blocks (extends).
• CI/CD components and the CI/CD Catalog Free
  Versioned pipeline building blocks with typed parameters (spec:inputs), published in a searchable catalog.
• Cache Free
  Files kept between pipelines to go faster (pip, npm, Maven downloads).
• Parent-child and multi-project pipelines Free
  A job with trigger: that starts another pipeline: a child pipeline (same project, other YAML) or another project's pipeline.
• Predefined variables Free
  Variables GitLab gives every job: CI_COMMIT_SHA, CI_COMMIT_SHORT_SHA, CI_DEFAULT_BRANCH, CI_PIPELINE_SOURCE, CI_REGISTRY_IMAGE, CI_JOB_TOKEN, CI_PROJECT_URL…
• Pipeline editor Free
  An editor dedicated to .gitlab-ci.yml with live validation, visualisation, simulation and merged configuration.
• id_tokens (OIDC) Free
  JWT tokens signed by GitLab, requested by a job, that describe its identity (project, branch, pipeline, environment).
• Docker-in-Docker (services) Free
  A side container docker:dind that gives the job a Docker daemon, reachable at the hostname docker.
• Jobs and logs Free
  A job page: live log, duration, runner, commit, pipeline, related jobs, and Retry, Cancel, Erase buttons.
• Container registry Free
  The project's Docker image registry, at registry.gitlab.com/<namespace>/<project>.
• Environments Free (protected environments: Premium)
  Operate, Environments: each deployment target (staging, production…) with its latest deployment, history and actions.
• Review apps Free
  Dynamic environments created per merge request, with a preview URL and automatic stop.
• SAST Free (Advanced SAST and MR widget: Ultimate)
  Static analysis of your source code, based on Semgrep and GitLab rules.
• Secret detection Free (push protection: Ultimate)
  A search for secrets (cloud keys, GitLab tokens, private keys…) in commits.
• Container scanning Free
  A scan of the packages inside the Docker image (OS and language packages) with Trivy.
• Dependency scanning Ultimate
  Analysis of declared dependencies (requirements, package-lock, pom) and generation of an SBOM.
• Vulnerability report Ultimate
  The consolidated list of vulnerabilities found on the default branch, each with a status (detected, confirmed, dismissed, resolved).
• Security policies Ultimate
  Central rules: scan execution policies (force scans), pipeline execution policies (force jobs), merge request approval policies (require approval when a flaw appears).
• Auto DevOps Free
  A complete predefined pipeline (build, tests, scans, Kubernetes deployment) used when a project has no .gitlab-ci.yml.
• Pipeline trigger tokens Free
  Tokens that start a pipeline through an API call (POST /projects/:id/trigger/pipeline).
• Deploy freezes Free
  Periods, written as cron expressions, during which deployments are not allowed.
• CI_JOB_TOKEN and job token permissions Free
  The automatic token of every job, valid while the job runs, with the permissions of the user who started the pipeline, limited to some APIs.
• Secure files Free
  Storage for sensitive files (Android keystores, Apple profiles, certificates) that jobs can download.
• CI/CD variables Free
  Key/value pairs injected into jobs, defined on a project, group or instance, with a type, an environment scope, a visibility and flags.
• Runners Free
  The agents that execute jobs: instance runners (provided by GitLab.com), group runners, project runners.
• Protected branches and tags Free (code owner approval: Premium)
  Rules on a branch or pattern: who can merge, who can push, whether force push is allowed.
• Deploy tokens and deploy keys Free
  Dedicated access for one use: a deploy token for registry, packages or repository; a deploy key is an SSH key that can clone.
• Merge checks Free
  Mandatory conditions to merge: pipeline succeeded, threads resolved, and more depending on your tier.
• Merged results and merge trains Premium
  Merged results: test the result of merging the merge request into its target. Merge train: a queue of merge requests, each tested together with the ones ahead of it.
• GitLab agent for Kubernetes Free
  A component (agentk) installed in your cluster that opens an outbound connection to GitLab. The cluster API is never exposed.
• Project access tokens Premium on GitLab.com
  A token bound to the project, with a role, scopes and an expiry date. It creates a bot user that is a member of the project.
• Service accounts Premium
  Non-human accounts created at group (or instance) level, which can hold several tokens and be members of several projects.
• OAuth applications Free
  An external application registered in GitLab, which gets a token on behalf of a user after consent.
• Personal access tokens Free
  A token that acts as you, with scopes and an expiry date.
• Integrations Free
  Native connectors to external tools (Slack, Jira, Teams, Jenkins, Asana…), configured with a form.
• Webhooks Free
  An HTTP POST that GitLab sends to your URL on each chosen event (push, tag, merge request, pipeline, job, deployment…).
• GitLab Duo Chat Paid add-on or GitLab Credits
  A conversational assistant in the right panel that knows the context of the page (project, issue, merge request, job, file).
• Duo Agent Platform Credits (some agents: Premium or Ultimate)
  GitLab's agent platform: agentic chat, foundational agents (Planner, Security Analyst, Data Analyst, CI Expert…), custom agents and flows.
• Flows Credits
  Chains of agents for a multi-step task, executed on GitLab runners.
• AI Catalog Credits
  The catalog of agents and flows published by GitLab and the community, with visibility, usage and stars.
• External agents (Claude Code and others) Premium
  Third-party agents plugged into the platform, which work in issues and merge requests like GitLab's own agents.
• MCP (server and clients) Free (external servers for agents: paid, beta)
  Model Context Protocol: GitLab exposes an MCP server (issues, merge requests, pipelines) to AI tools, and its agents can call external MCP servers.
• GitLab Credits Usage-based
  The usage-based billing unit for the AI features of the Agent Platform.

Dotted words in the course open these definitions in place.

Official documentation

• CI/CD YAML syntax reference: every keyword.
• Predefined CI/CD variables.
• OpenID Connect (id_tokens) authentication.
• Application security: scanners and tiers.
• Project access tokens.
• Protected environments.
• GitLab Pages.
• GitLab Duo Agent Platform.
• Sigstore and cosign.
• GitLab Certified CI/CD Associate exam.

The DevSecOps Learning Series

Three courses, one method: a real lab, annotated screenshots, simulators and quizzes.

• GitHub Actions DevSecOps, with its lab devsecops-actions-lab.
• GitLab CI/CD DevSecOps (this course), with its lab devsecops-gitlab-lab.
• Kubernetes + Helm, with its lab k8s-helm-lab.