Was macht DevSecOps-Pipeline mit GitLab CI erstellen?
Überblick
GitLab bietet eine integrierte DevSecOps-Plattform, die Sicherheitstests direkt in die CI/CD-Pipeline einbettet. Durch die Nutzung der integrierten Sicherheitsscanner von GitLab – SAST, DAST, Container-Scanning, Abhängigkeitsscanning, Geheimnis-Erkennung und Lizenz-Compliance – können Teams Sicherheit nach links verschieben und Schwachstellen während der Entwicklung erkennen, anstatt erst nach der Bereitstellung. GitLab Duo AI unterstützt bei der Erkennung von Fehlalarmen für SAST-Schwachstellen und hilft Sicherheitsteams, sich auf echte Probleme zu konzentrieren.
Verwendungszweck
- Beim Bereitstellen oder Konfigurieren von DevSecOps-Pipelines mit GitLab CI in Ihrer Umgebung
- Beim Festlegen von Sicherheitskontrollen zur Einhaltung von Compliance-Anforderungen
- Beim Aufbau oder der Verbesserung der Sicherheitsarchitektur für diesen Bereich
- Bei der Durchführung von Sicherheitsbewertungen, die diese Implementierung erfordern
Voraussetzungen
- GitLab Ultimate-Lizenz (erforderlich für die vollständige Sicherheitsscanner-Suite)
- Konfigurierter GitLab Runner (gemeinsam genutzt oder selbst gehostet)
- Vertrautheit mit der
.gitlab-ci.yml-Pipeline-Konfiguration - Docker-in-Docker (DinD) oder Kaniko für Container-Builds
- In einer Staging-Umgebung bereitgestellte Anwendung für DAST-Scans
Wichtige Sicherheitsscan-Stufen
Static Application Security Testing (SAST)
SAST analysiert Quellcode auf Schwachstellen vor der Kompilierung. GitLab unterstützt 14+ Sprachen mit Analysatoren wie Semgrep, SpotBugs, Gosec, Bandit und NodeJsScan. Die einfachste Integration erfolgt über die verwalteten Vorlagen von GitLab.
Dynamic Application Security Testing (DAST)
DAST testet laufende Anwendungen, indem es Angriffspayloads gegen HTTP-Endpunkte simuliert. Es erkennt XSS, SQLi, CSRF und andere Laufzeitschwachstellen, die SAST nicht finden kann. DAST erfordert eine bereitgestellte, erreichbare Ziel-URL.
Container-Scanning
Verwendet Trivy, um Docker-Images auf bekannte CVEs in Betriebssystempaketen und Anwendungsabhängigkeiten zu scannen. Läuft nach der Docker-Build-Stufe, um Images zu sperren, bevor sie eine Registry erreichen.
Abhängigkeitsscanning
Überprüft Abhängigkeitsmanifeste (package.json, requirements.txt, pom.xml, Gemfile.lock) auf bekannte, verwundbare Versionen. Arbeitet auf Quellcode-Ebene und ergänzt das Container-Scanning.
Geheimnis-Erkennung
Scannt Commits auf versehentlich committete Anmeldedaten, API-Schlüssel, Tokens und private Schlüssel mittels Mustervergleich und Entropieanalyse. Läuft bei jedem Commit, um zu verhindern, dass Geheimnisse ins Repository gelangen.
Implementierung
Vollständige Pipeline-Konfiguration
# .gitlab-ci.yml
stages:
- build
- test
- security
- deploy-staging
- dast
- deploy-production
variables:
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
SECURE_LOG_LEVEL: "info"
# GitLab-verwaltete Sicherheitsvorlagen einbinden
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Secret-Detection.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml
- template: DAST.gitlab-ci.yml
- template: Security/License-Scanning.gitlab-ci.yml
build:
stage: build
image: docker:24.0
services:
- docker:24.0-dind
variables:
DOCKER_TLS_CERTDIR: "/certs"
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $DOCKER_IMAGE .
- docker push $DOCKER_IMAGE
rules:
- if: $CI_COMMIT_BRANCH
unit-tests:
stage: test
image: $DOCKER_IMAGE
script:
- npm ci
- npm run test:coverage
coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
artifacts:
reports:
junit: junit-report.xml
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
# SAST überschreiben, um in der Sicherheitsstufe zu laufen
sast:
stage: security
variables:
SAST_EXCLUDED_PATHS: "spec,test,tests,tmp,node_modules"
SEARCH_MAX_DEPTH: 10
# Container-Scanning überschreiben
container_scanning:
stage: security
variables:
CS_IMAGE: $DOCKER_IMAGE
CS_SEVERITY_THRESHOLD: "HIGH"
# Abhängigkeitsscanning überschreiben
dependency_scanning:
stage: security
# Geheimnis-Erkennung überschreiben
secret_detection:
stage: security
# Lizenz-Compliance-Scanning
license_scanning:
stage: security
deploy-staging:
stage: deploy-staging
image: bitnami/kubectl:latest
script:
- kubectl set image deployment/app app=$DOCKER_IMAGE -n staging
- kubectl rollout status deployment/app -n staging --timeout=300s
environment:
name: staging
url: https://staging.example.com
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
# DAST läuft gegen die bereitgestellte Staging-Umgebung
dast:
stage: dast
variables:
DAST_WEBSITE: https://staging.example.com
DAST_FULL_SCAN_ENABLED: "true"
DAST_BROWSER_SCAN: "true"
needs:
- deploy-staging
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deploy-production:
stage: deploy-production
image: bitnami/kubectl:latest
script:
- kubectl set image deployment/app app=$DOCKER_IMAGE -n production
- kubectl rollout status deployment/app -n production --timeout=300s
environment:
name: production
url: https://app.example.com
when: manual
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Sicherheitsgenehmigungsrichtlinien
Konfigurieren Sie Scan-Ausführungsrichtlinien, um obligatorische Sicherheitsscans durchzusetzen:
- Navigieren Sie zu Sicherheit & Compliance > Richtlinien
- Erstellen Sie eine „Scan-Ausführungsrichtlinie“, die SAST und Geheimnis-Erkennung auf allen Branches vorschreibt
- Erstellen Sie eine „Merge Request-Genehmigungsrichtlinie“, die die Zustimmung des Sicherheitsteams erfordert, wenn kritische Schwachstellen erkannt werden
Benutzerdefinierte SAST-Regelwerkkonfiguration
Erstellen Sie .gitlab/sast-ruleset.toml, um das Verhalten der Analysatoren anzupassen:
[semgrep]
[[semgrep.ruleset]]
dirs = ["src"]
[[semgrep.passthrough]]
type = "url"
target = "/sgrep-rules/custom-rules.yml"
value = "https://semgrep.dev/p/owasp-top-ten"
[[semgrep.passthrough]]
type = "url"
target = "/sgrep-rules/java-rules.yml"
value = "https://semgrep.dev/p/java"
Sicherheitsdashboard und Schwachstellenmanagement
Schwachstellenbericht
GitLab fasst alle Scannerergebnisse in einem einzigen Schwachstellenbericht zusammen, der unter Sicherheit & Compliance > Schwachstellenbericht abrufbar ist. Jede Schwachstelle enthält:
- Schweregrad (Kritisch, Hoch, Mittel, Niedrig, Info)
- Scannerquelle (SAST, DAST, Container, Abhängigkeit, Geheimnis)
- Position im Quellcode oder in der Image-Ebene
- Behebungsanleitung und empfohlene Korrekturen
- Statusverfolgung (Erkannt, Bestätigt, Verworfen, Behoben)
Merge-Request-Sicherheitswidget
Jeder Merge Request zeigt ein Sicherheits-Scan-Widget an mit:
- Neuen Schwachstellen, die durch den MR eingeführt wurden
- Behobenen Schwachstellen, die durch den MR gelöst wurden
- Vergleich mit der Basislinie des Ziel-Branches
Pipeline-Optimierung
- Parallele Ausführung: Sicherheitsscanner laufen gleichzeitig in der Sicherheitsstufe
- Caching: CI-Cache für Abhängigkeits-Downloads verwenden, um Scans zu beschleunigen
- Inkrementelles Scannen: SAST kann nur geänderte Dateien scannen mit
SAST_INCREMENTAL: "true" - Fehlerbedingungen: Setzen Sie
allow_failure: falsebei kritischen Scannern, um Qualitätstore durchzusetzen
Überwachung und Metriken
| Metrik | Beschreibung | Ziel |
|---|---|---|
| Pipeline-Sicherheitsabdeckung | Prozentsatz der Projekte mit allen aktiven Scannern | > 95 % |
| Kritische Schwachstellen-MTTR | Zeit von Erkennung bis Behebung bei kritischen Befunden | < 48 Stunden |
| Falsch-Positiv-Rate | Prozentsatz der als falsch-positiv verworfenen Befunde | < 15 % |
| Geheimnis-Erkennungs-Blockrate | Prozentsatz der durch Push-Regeln blockierten Geheimnis-Commits | > 99 % |