# GitLab CI/CD Modern Security Patterns

> **Intro:** A secure GitLab pipeline is not just a list of jobs. It is a control plane for trust, concurrency, artifact visibility, environment protection, and policy-aware release flow. The most useful GitLab CI improvements in recent years are the ones that make dependency flow, artifact access, parallelism, and shared pipeline logic more explicit.
>
> **What this page includes**
>
> * practical pipeline patterns that matter in 2026
> * where older GitLab CI guidance is now incomplete
> * examples for `needs`, `needs:artifacts`, `parallel:matrix`, `resource_group`, and artifact access
> * secure design notes for reusable CI logic

## The modern GitLab mindset

A strong GitLab CI/CD design now tends to emphasize:

* **smaller explicit DAGs** rather than stage-only sequencing;
* **artifact minimization** instead of wide default artifact flow;
* **controlled concurrency** for deploy and mutable resources;
* **reusable includes or components** that are pinned and reviewed;
* **protected environments and protected variables** for privileged operations;
* **clear trust boundaries** between untrusted MR pipelines and trusted protected-branch or tag pipelines.

## Older guidance that is now incomplete

| Older habit                                       | Why it is incomplete                            | Better current pattern                                                        |
| ------------------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------- |
| rely on stage order only                          | hides real dependencies and slows feedback      | use `needs` for explicit DAG flow                                             |
| let jobs inherit all previous artifacts           | creates artifact sprawl and accidental exposure | restrict with `needs:artifacts`, `dependencies`, and explicit artifact design |
| use one static build job for every platform combo | becomes slow and repetitive                     | use `parallel:matrix` and targeted downstream `needs:parallel:matrix`         |
| allow multiple deploy jobs to race                | causes conflicting release behavior             | use `resource_group`                                                          |
| treat artifacts as naturally private              | access rules are more nuanced than teams assume | use `artifacts:access`, project visibility settings, and token restrictions   |
| copy large pipeline fragments everywhere          | drift and review quality degrade                | use reviewed reusable includes or components pinned to known refs             |

## Pattern 1 — explicit DAGs with `needs`

```yaml
build:
  stage: build
  script:
    - ./scripts/build.sh
  artifacts:
    paths: [dist/]

unit_tests:
  stage: test
  needs:
    - job: build
      artifacts: true
  script:
    - ./scripts/test.sh
```

### Why this is better

* test does not wait for unrelated jobs in earlier stages;
* artifact consumption becomes explicit;
* the pipeline graph is easier to reason about.

## Pattern 2 — selective artifact download

```yaml
policy_gate:
  stage: security
  needs:
    - job: sbom_generate
      artifacts: true
    - job: unit_tests
      artifacts: false
  script:
    - ./scripts/evaluate-policy.sh sbom.json
```

### Why this matters

Without explicit `needs:artifacts`, teams often download more artifacts than required, which increases runtime, storage, and accidental data exposure.

## Pattern 3 — artifact access control

```yaml
security_report:
  stage: security
  script:
    - ./scripts/export-findings.sh
  artifacts:
    access: developer
    paths:
      - reports/security/
```

### What this improves

This reduces casual artifact exposure through the GitLab UI and API for public or wider-visibility projects. It is not a substitute for broader CI/CD visibility settings, but it is an important layer.

## Pattern 4 — deploy concurrency with `resource_group`

```yaml
deploy_production:
  stage: deploy
  resource_group: production
  script:
    - ./scripts/deploy-prod.sh
```

### Why it matters

This prevents multiple deployments to the same mutable target from racing across pipelines. In practice it is one of the easiest ways to remove a whole class of release collisions.

## Pattern 5 — controlled platform explosion with `parallel:matrix`

```yaml
container_scan:
  stage: security
  parallel:
    matrix:
      - IMAGE:
          - api
          - worker
          - frontend
        REGION:
          - eu
          - us
  script:
    - ./scripts/scan-image.sh "$IMAGE" "$REGION"
```

### Why this helps

Matrix jobs let you scale platform coverage without duplicating job definitions endlessly.

### Security caution

Do not add matrix complexity only because it looks advanced. Use it when the matrix reflects real release or runtime differences.

## Pattern 6 — downstream precision with `needs:parallel:matrix`

```yaml
publish_scan_summary:
  stage: security
  needs:
    - job: container_scan
      parallel:
        matrix:
          - IMAGE: api
            REGION: eu
          - IMAGE: api
            REGION: us
  script:
    - ./scripts/publish-summary.sh
```

### Why this matters

Without this pattern, downstream jobs may drag in all parallel artifacts by default, creating confusion and overwrites.

## Pattern 7 — reusable security logic

```yaml
include:
  - project: platform/ci-templates
    ref: v3.4.2
    file:
      - /security/zap-api.yml
      - /security/sbom.yml
```

### Good practice

* pin to a reviewed ref or tag;
* treat shared templates like production code;
* document which contexts are allowed to consume them;
* keep privileged deploy logic out of untrusted MR flows.

### Bad practice

* importing floating refs from unreviewed template projects;
* hiding sensitive behavior in shared scripts that most engineers never inspect;
* assuming a reusable component is safe because it is internal.

## Pattern 8 — protected trust zones

A secure GitLab design usually separates these zones:

### Zone A — untrusted MR pipelines

Use for:

* lint,
* unit tests,
* lightweight scanners,
* non-privileged validation.

Do **not** give these jobs:

* production deploy tokens,
* broad cloud access,
* privileged runners,
* unrestricted secret access.

### Zone B — protected-branch or protected-tag pipelines

Use for:

* release packaging,
* image signing,
* provenance,
* environment deployment,
* evidence generation.

This separation is more important than any single scanner choice.

## Pattern 9 — GitLab DAST integration without scanner theatre

A modern GitLab ZAP or DAST design should make three things explicit:

* where the target is deployed,
* whether authentication is valid,
* what findings are release-blocking.

That means your GitLab CI should preserve:

* the DAST config file,
* the progress or exception file,
* the report artifacts,
* the gating summary.

## Pattern 10 — release evidence as a first-class output

## Pattern 11 — shared GitLab delivery logic without copy-paste sprawl

A recurring lesson from large GitLab estates is that one `.gitlab-ci.yml` per service quickly turns into drift unless teams standardize shared logic.

### Practical pattern

* keep one thin service-local file;
* import reviewed shared includes or components;
* pin shared logic to known refs;
* isolate privileged deploy logic from untrusted MR execution.

### Why this matters

This gives you reuse without silently turning every pipeline into a black box.

### Legacy-to-current note

Older GitLab patterns often relied on large monolithic templates or historical deploy tools. The durable idea is **standardized reviewed shared logic**. The current recommendation is to keep the shared parts explicit, pinned, and reviewable.

## Pattern 10 — release evidence as a first-class output

Treat the pipeline as a producer of:

* build metadata,
* artifact digests,
* SBOM,
* attestation or signing metadata,
* scanner summaries,
* release notes and approvals.

This is what turns CI/CD into a trustworthy release system rather than a job launcher.

## A practical secure GitLab pipeline skeleton

```yaml
workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
    - if: '$CI_COMMIT_TAG'
    - when: never

stages:
  - prepare
  - build
  - security
  - package
  - release
  - deploy

prepare:
  stage: prepare
  script:
    - ./scripts/prepare.sh

build:
  stage: build
  needs: [prepare]
  script:
    - ./scripts/build.sh
  artifacts:
    paths: [dist/]

semgrep:
  stage: security
  needs:
    - job: build
      artifacts: true
  script:
    - semgrep scan --config p/default --json --output semgrep.json
  artifacts:
    paths: [semgrep.json]

zap_api:
  stage: security
  needs: [deploy_review]
  script:
    - ./scripts/run-zap-api.sh
  artifacts:
    access: developer
    paths: [reports/zap/]

package_image:
  stage: package
  needs:
    - job: build
      artifacts: true
    - job: semgrep
      artifacts: true
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_TAG'
  script:
    - ./scripts/package-image.sh
  artifacts:
    paths: [image-digest.txt, sbom.json]

release:
  stage: release
  resource_group: release-main
  needs:
    - job: package_image
      artifacts: true
  rules:
    - if: '$CI_COMMIT_TAG'
  script:
    - ./scripts/create-release.sh

production_deploy:
  stage: deploy
  resource_group: production
  needs: [release]
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_TAG'
      when: manual
  script:
    - ./scripts/deploy-prod.sh
```

## What to review during pipeline design

* Are untrusted and trusted pipeline contexts separated?
* Which jobs can touch secrets?
* Which jobs can reach mutable environments?
* Which artifacts are actually needed downstream?
* Where can concurrency collisions occur?
* Which shared includes are pinned and reviewed?
* Are scanner outputs preserved as evidence or thrown away?

## Recommended snippet pack additions

* `snippets/ci/gitlab/secure-gitlab-pipeline-2026.yml`
* `snippets/ci/gitlab/restricted-artifact-access.yml`
* `snippets/ci/gitlab/zap-api-scan-job.yml`
* `snippets/ci/gitlab/resource-group-deploy.yml`
* `snippets/ci/gitlab/matrix-needs-example.yml`

## Cross-links

* [GitLab CI YAML Deep Dive](/devsecops-cicd-and-supply-chain/index-1/gitlab-ci-yaml-deep-dive.md)
* [GitLab Release Evidence](/devsecops-cicd-and-supply-chain/index-1/gitlab-release-evidence.md)
* [Reusable GitLab Includes and Components](/devsecops-cicd-and-supply-chain/index-1/reusable-gitlab-includes-and-components.md)
* [Protected Environments and Deployment Approvals](/devsecops-cicd-and-supply-chain/index-1/protected-environments-and-deployment-approvals.md)
* [Self-Hosted Runners Security Review Pack](/devsecops-cicd-and-supply-chain/index-1/self-hosted-runners-security-review-pack.md)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/gitlab-ci-cd-modern-security-patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.