terminal DevSecOps / GitOpsfeedback
Dieser Funktionsbaustein wurde als strategisch notwendig identifiziert und befindet sich in der Konzeptionsphase.
Status: Vorgeschlagen | Erstellt am: 13. März 2026 | Zuletzt geändert: 14. März 2026 | Autor: BMDS-Architekturteam
Was ist DevSecOps?feedback
DevSecOps kombiniert drei Disziplinen zu einem integrierten Arbeitsmodell:
| Steht für | Kernidee | |
|---|---|---|
| Dev | Development | Code schreiben, Features bauen, Änderungen versionieren |
| Sec | Security | Sicherheit von Anfang an einbauen, nicht am Ende prüfen |
| Ops | Operations | Betrieb, Deployment, Monitoring, Incident Response |
Das zentrale Prinzip heißt „Shift Left Security": Sicherheitsprüfungen werden so früh wie möglich in den Entwicklungsprozess gezogen, idealerweise bereits beim ersten Commit, nicht erst beim Deployment.
Das folgende Prozessdiagramm zeigt den vollständigen DevSecOps-Ablauf mit Security Gates und Feedback-Schleifen:
Was ist GitOps?feedback
GitOps ist das Betriebsmodell, bei dem Git die einzige autoritative Quelle für den gewünschten Zustand aller Infrastruktur und Deployments ist. Ein GitOps-Controller (ArgoCD, Flux) synchronisiert den Cluster kontinuierlich mit dem Git-Repository.
„If it's not in Git, it doesn't exist."
lightbulb Motivation für den D-Stackfeedback
Ohne DevSecOps/GitOps entstehen im Behördenkontext konkrete Risiken:
- Manuelle Deployments → fehlende Reproduzierbarkeit, Shadow-IT, Compliance-Verstöße
- Security-Lücken in der Pipeline → ungeprüfte Dependencies, kompromittierte Images
- Fehlende Auditierbarkeit → kein Nachweis, wer wann was deployed hat (BSI-Anforderung)
- Supply Chain Attacks → Angriffe über Abhängigkeiten oder Build-Tools (→ Supply Chain Security)
lightbulb Wichtige Konzepte & Begriffefeedback
| Begriff | Bedeutung | Typische Tools |
|---|---|---|
| CI/CD | Automatisierter Build, Test und Deployment bei jedem Commit | GitLab CI, Tekton |
| SAST | Statische Code-Analyse auf Schwachstellen, ohne Ausführung | Semgrep, SonarQube |
| DAST | Test der laufenden Anwendung durch simulierte Angriffe | OWASP ZAP |
| SCA | Analyse von Abhängigkeiten auf bekannte CVEs | Trivy, Dependabot |
| SBOM | Vollständige Stückliste aller Software-Komponenten (BSI TR-03183) | Syft, CycloneDX |
| CVE | Öffentliche Datenbank bekannter Sicherheitslücken (CVSS-Score 0–10) | NVD/NIST |
| SLSA | Stufenmodell für Build-Integrität (Level 1–4, von Google/OpenSSF) | Cosign, Sigstore |
| IaC | Infrastruktur als versionierter Code statt manueller Konfiguration | Terraform, Helm |
| Policy-as-Code | Sicherheitsregeln automatisch in Pipeline und Cluster durchgesetzt | OPA, Kyverno |
| IAM / OIDC | Kurzlebige Tokens statt statischer Secrets für Pipeline-Authentifizierung | Vault, OIDC |
CVSS-Schweregrade und empfohlene Reaktionszeiten (BSI):
| Score | Schweregrad | Reaktionszeit |
|---|---|---|
| 9.0–10.0 | Critical | ≤ 24 Stunden |
| 7.0–8.9 | High | ≤ 72 Stunden |
| 4.0–6.9 | Medium | ≤ 30 Tage |
| 0.1–3.9 | Low | Nach Planung |
CVSS (Common Vulnerability Scoring System) ist ein standardisiertes Bewertungssystem, das Sicherheitslücken von 0.0 bis 10.0 nach Ausnutzbarkeit und Auswirkung einstuft. Die offizielle Datenbank und Detailwerte findest du in der NVD (National Vulnerability Database): https://nvd.nist.gov/vuln-metrics/cvss
Warum wichtig? CVSS macht Risiken vergleichbar und priorisierbar. In DevSecOps steuert der Score, ob ein Build blockiert wird, wie schnell gepatcht werden muss und wo begrenzte Ressourcen zuerst eingesetzt werden.
settings Kernfunktionalitätenfeedback
- CI/CD-Pipelines: Automatisierte Build-, Test- und Deployment-Pipelines mit Security-Gates
- GitOps-Controller: Automatische Synchronisation von Git-Repositories mit Kubernetes-Clustern
- Security-Scanning: SAST, DAST, Container-Image-Scanning und IaC-Scanning in der Pipeline
- Policy-as-Code: Automatische Compliance-Prüfung von IaC-Manifesten (OPA Gatekeeper, Kyverno)
- Secrets-Injection: Sichere Bereitstellung von Secrets zur Laufzeit, kein Klartext in Git
engineering Technische Einordnungfeedback
| Eigenschaft | Wert |
|---|---|
| Kategorie | Betrieb & Plattform |
| Referenzstandards | SLSA, NIST SSDF, GitOps Principles (OpenGitOps), BSI TR-03183 |
| Open-Source-Referenz | ArgoCD, Flux, Tekton, GitLab CI, Trivy, OPA |
arrow_forward Weiterführende Seitenfeedback
| Seite | Inhalt |
|---|---|
| Supply Chain Security | Angriffsvektoren, Fallbeispiele (SolarWinds, Log4Shell, XZ) und Schutzmaßnahmen |
| GitOps-Pipeline-Architektur | Technische Pipeline-Architektur, Security Gates und Toolchain-Übersicht |
share Abhängigkeitenfeedback
- Container-Orchestrierung (Ziel-Cluster für Deployments)
- Schwachstellen-Management (Image-Scanning in Pipeline)
- Machine Identity (Pipeline-Identity via OIDC)
- Secrets-Management (Secrets-Injection zur Laufzeit)
arrow_forward Nächste Schrittefeedback
- Evaluierung ArgoCD vs. Flux für GitOps-Controller
- PoC: GitOps-Pipeline mit Security-Gates (Trivy, OPA Gatekeeper)
- Konzept für Multi-Tenant-Pipeline-Architektur
- Integration in den D-Stack