Siebzig Prozent der in der Produktion gefundenen Schwachstellen hätten bereits während der Entwicklung entdeckt werden können. Diese eine Zahl — aus Gartners Analyse der Application Security Posture — ist das gesamte Geschäftsargument für die DevSecOps-Pipeline. Dennoch behandeln die meisten Entwicklungsteams Sicherheit immer noch als ein Gate am Ende des Auslieferungsprozesses, anstatt sie als roten Faden durch jede Phase zu weben.
Dieser Beitrag präsentiert ein konkretes DevSecOps-Pipeline-Diagramm, erklärt jede Phase, nennt die empfehlenswerten Tools und zeigt ein GitHub-Actions-Beispiel, das Sie direkt adaptieren können.
Wie eine DevSecOps-Pipeline wirklich aussieht
Im Kern ist eine DevSecOps-Pipeline eine CI/CD-Pipeline, bei der Sicherheitsprüfungen automatisiert und in jede Phase eingebettet sind — nicht nachträglich angehängt. Das kanonische Pipeline-Diagramm hat sechs Phasen: Pre-Commit → Build → Test → Artefakt → Deploy → Monitor. Sicherheitskontrollen erscheinen innerhalb jeder Phase, nicht als separate Spur.
Der konzeptionelle Ablauf sieht so aus:
[Entwickler-IDE] → [Pre-Commit-Hooks] → [Quellcodeverwaltung / PR-Review]
→ [Build & SAST] → [Abhängigkeitsscan / SCA] → [Container-Image-Scan]
→ [IaC Policy Check] → [Staging Deploy] → [DAST / Pen-Test-Automatisierung]
→ [Produktions-Deploy] → [Laufzeit-Monitoring / CSPM]Jeder Pfeil repräsentiert ein potenzielles Sicherheits-Gate. Schlägt ein Gate fehl — ein kritischer CVE in einer Abhängigkeit, ein hartcodiertes Secret, eine falsch konfigurierte Terraform-Ressource — stoppt die Pipeline. Das ist Shift-Left-Security in ihrer wörtlichsten Form.
Phase-für-Phase-Aufschlüsselung
Phase 1: Pre-Commit
Bevor eine einzige Codezeile das Remote-Repository erreicht, kann die lokale Entwicklermaschine über Git-Hooks leichte Sicherheitsprüfungen durchführen. Tools wie pre-commit kombiniert mit detect-secrets oder gitleaks fangen hartcodierte Credentials, API-Keys und private Zertifikate in Millisekunden ab. Der Blast-Radius eines in ein öffentliches GitHub-Repo eingecheckten AWS-Secrets ist enorm — und hier vollständig vermeidbar.
Phase 2: Build und statische Analyse (SAST)
Die Build-Phase ist, wo Static Application Security Testing seinen Wert unter Beweis stellt. SAST-Tools analysieren Ihren Quellcode, ohne ihn auszuführen, und suchen nach Injection-Fehlern, unsicherer Deserialisierung, Path-Traversal-Mustern und anderen OWASP-Top-10-Problemen. Für Open-Source-DevSecOps-Tools sind Semgrep OSS und Bandit solide Ausgangspunkte.
Die SAST-Funktionen in SECRAILS integrieren sich direkt in die Build-Phase und liefern kontextbezogene Befunde, die CWE-Bezeichnern zugeordnet sind. Die Secret Detection auf Build-Ebene bietet eine zweite Schicht hinter den Pre-Commit-Hooks.
Phase 3: Abhängigkeits- und SCA-Scanning
Software Composition Analysis ist 2025 nicht verhandelbar. Die durchschnittliche Enterprise-Anwendung zieht 528 Open-Source-Abhängigkeiten heran. EPSS-Scores sind hier zunehmend wichtig — ein CVE mit CVSS 9.8, aber EPSS 0,003% ist operativ sehr anders als ein CVE mit CVSS 7.2 und EPSS 42%. Tools wie Grype, OWASP Dependency-Check und Snyk Open Source bieten mittlerweile EPSS-Kontext.
Phase 4: Container-Image-Scanning
Container-Images enthalten regelmäßig OS-Pakete mit bekannten CVEs, übermäßig freizügige Dateirechte und in Schichten eingebackene Secrets. Trivy von Aqua Security ist der De-facto-Open-Source-Standard. Das Container Image Scanning in SECRAILS deckt Base-Image-Schwachstellen, Paket-CVEs und Fehlkonfigurationen in einem einzigen Durchgang ab.
Phase 5: IaC-Policy-Prüfungen
Terraform, Pulumi, CloudFormation, Helm-Charts — alles ist Code und kann vor dem Kontakt mit einer echten Cloud-Umgebung gescannt werden. Policy-as-Code wird hier operativ mächtig. Tools wie Checkov, tfsec und KICS fangen öffentliche S3-Buckets, zu offene Security Groups und unverschlüsselte EBS-Volumes ab, bevor sie je provisioniert werden.
Phase 6: Dynamische Analyse (DAST) und Staging
DAST läuft gegen eine lebende oder Staging-Instanz der Anwendung. Anders als SAST kann es Laufzeitprobleme erkennen: Authentifizierungs-Bypässe, SSRF, Race Conditions und Business-Logic-Schwachstellen. OWASP ZAP bleibt das meistgenutzte Open-Source-DAST-Tool.
Phase 7: Produktionsmonitoring und Laufzeitschutz
Sicher zu deployen ist nicht die Ziellinie. Laufzeit-Monitoring schließt die Schleife. CSPM wertet Cloud-Konfigurationen kontinuierlich gegen CIS Benchmarks und NIST CSF 2.0 aus. Falco bietet Verhaltenserkennnung für Kubernetes. Vulnerability Management zur Laufzeit bedeutet kontinuierliches Scanning lebender Infrastruktur.
DevSecOps-Pipeline-Tools-Liste
Secret Detection: Gitleaks, detect-secrets, TruffleHog v3
SAST: Semgrep, SonarQube Community, Checkmarx, Bandit
SCA / Abhängigkeitsscan: Grype, Trivy, Snyk, OWASP Dependency-Check
Container-Scanning: Trivy, Grype, Clair, Docker Scout
IaC / Policy-as-Code: Checkov, tfsec, KICS, OPA/Conftest
DAST: OWASP ZAP, Nuclei, Burp Suite Enterprise
Runtime / CSPM: Falco, Wiz, Prisma Cloud, SECRAILS CSPM
GitHub-Actions-Beispiel für DevSecOps-Pipelines
Hier ist ein vereinfachter, aber realistischer GitHub-Actions-Workflow, der zeigt, wie mehrere Sicherheitsphasen verkettet werden. Jeder Job hängt vom Erfolg des vorherigen ab. Ein kritischer CVE in Abhängigkeiten blockiert den Container-Build vollständig — das ist beabsichtigt.
Häufige Fehler, die Teams machen
Alert-Fatigue ist real. Eine Pipeline, die 300 Befunde pro Lauf auslöst, wird ignoriert oder deaktiviert. Stimmen Sie Ihre Tools ab. Ein weiterer häufiger Fehler: Nur den Anwendungscode zu scannen, nicht die Infrastruktur, die ihn betreibt. Die Cloud-Security-Schicht ist nicht optional. Außerdem vernachlässigen die meisten Teams die Feedback-Schleife — Sicherheitsbefunde in einem JIRA-Ticket, die nie behoben werden, sind keine Sicherheit.
Abschließende Gedanken
Ein DevSecOps-Pipeline-Diagramm ist kein bürokratisches Artefakt — es ist eine Engineering-Spezifikation. Jedes Element repräsentiert eine automatisierte Sicherheitskontrolle, die bei jeder Code-Änderung ausgeführt wird. Beginnen Sie mit Secrets und SAST. Fügen Sie SCA hinzu. Dann Container-Scanning. Dann IaC-Prüfungen. Sie brauchen die gesamte Pipeline nicht am ersten Tag — aber Sie müssen jetzt anfangen.