DevSecOps im Jahr 2026: Eine empirisch fundierte, risikoadaptierte Referenzarchitektur für sichere CI/CD-Pipelines, Software-Supply-Chain-Härtung und KI-gestützte Sicherheitsautomatisierung

1. Einführung

DevSecOps ist im Jahr 2026 kein Schlagwort mehr, sondern eine betriebliche Notwendigkeit. Der Begriff steht für die systematische Verankerung von Sicherheit in alle Phasen der Softwareentwicklung, von der Anforderungsanalyse über die Implementierung und Integration bis hin zum Betrieb und zur kontinuierlichen Verbesserung. In reifen Organisationen hat sich dabei ein deutliches Muster herausgebildet: Je stärker Entwicklungs- und Betriebsprozesse durch Cloud-native Architekturen, Containersysteme, GitOps, Infrastructure as Code und KI-gestützte Automatisierung geprägt sind, desto weniger tragen ad-hoc ausgeführte Sicherheitsprüfungen. Sicherheitsverantwortung muss stattdessen als technische Eigenschaft der Lieferkette verstanden werden, die in Artefakte, Policies, Telemetrie und Freigabeschritte eingebettet wird. Diese Sichtweise ist im Jahr 2026 besonders relevant, weil Angriffe nicht mehr primär nur auf Webanwendungen oder Endgeräte zielen, sondern auf Build-Infrastrukturen, Paketregistries, Entwicklerkonten, CI/CD-Runner und Signatur- oder Vertrauenskettensysteme.

Die operative Ausgangslage ist eindeutig. Einerseits haben Unternehmen ihre Softwarelieferungen massiv beschleunigt, Releases erfolgen häufig mehrmals täglich, und Abhängigkeiten werden zunehmend dynamisch aus öffentlichen und privaten Ökosystemen gezogen. Andererseits ist die Angriffsfläche gewachsen: Eine einzelne kompromittierte Pipeline oder ein manipuliertes Abhängigkeitsartefakt kann hunderte oder tausende nachgelagerte Systeme beeinträchtigen. Die Vorfälle um SolarWinds, Log4Shell und verschiedene Paketregistrierungsangriffe haben gezeigt, dass Supply-Chain-Risiken nicht nur theoretisch sind, sondern strukturell wirken. Zugleich hat sich die Bedrohungslage durch generative KI verschärft, da Social Engineering, Phishing-Content, Code-Generierung und Prompt-basierte Umgehungsversuche für Angreifer billiger und skalierbarer geworden sind. DevSecOps muss deshalb nicht nur klassische Schwachstellenmanagement-Mechanismen integrieren, sondern auch KI-spezifische Risiken adressieren, etwa Modelleingabedaten, Tool-Integrationen, interne Assistenten und automatisierte Code-Review-Workflows.

Ein zentrales Missverständnis besteht darin, DevSecOps als eine Sammlung zusätzlicher Scanner zu interpretieren. In der Praxis erzeugt ein solcher Ansatz häufig Sicherheitsmüdigkeit, hohe Fehlalarmraten und Pipeline-Verlangsamung. Die Erfahrung aus reifen Organisationen zeigt, dass die reine Anhäufung von Tools nur dann einen Nutzen bringt, wenn sie in eine klare Methodik eingebettet ist: Welche Bedrohungen werden auf welcher Stufe verhindert? Welche Artefakte sind vertrauenswürdig? Welche Risiken sind akzeptabel? Welche Messgrößen bestimmen, ob eine Kontrolle tatsächlich wirksam ist? Sicherheitsarchitektur muss deshalb von Beginn an mit Operabilität, Automatisierbarkeit und Nachvollziehbarkeit gedacht werden. Genau hier setzt diese Arbeit an.

Die Forschungsfrage lautet, wie eine DevSecOps-Referenzarchitektur für 2026 gestaltet werden muss, damit sie in realen Cloud-nativen Umgebungen einen messbaren Sicherheitsgewinn erzeugt, ohne die Liefergeschwindigkeit unvertretbar zu reduzieren. Dazu werden drei Hypothesen formuliert. Erstens: Ein mehrstufiges Kontrollmodell, das präventive, detektive und reaktive Maßnahmen kombiniert, senkt das Risiko erfolgreicher Supply-Chain-Angriffe stärker als isolierte Einzellösungen. Zweitens: Die Integration von Provenienz, Signatur, SBOM und Policy-as-Code verbessert die Entscheidbarkeit von Freigaben, weil sie Sicherheit als maschinenlesbare Eigenschaft der Artefakte modelliert. Drittens: Runtime-Telemetrie auf Basis moderner Kernel- und Plattformmechanismen, insbesondere eBPF und Kubernetes-Auditdaten, reduziert die mittlere Erkennungszeit für Angriffe, die Build- oder Deploy-Phasen umgehen.

Diese Arbeit ist bewusst praxisorientiert. Sie betrachtet DevSecOps nicht als abstraktes Reifegradmodell, sondern als technische Architektur mit konkreten Werkzeugebenen, Verantwortlichkeiten und Evaluationsmetriken. Dazu werden echte Werkzeuge und Konzepte verwendet, die bis 2026 etabliert waren, darunter GitHub Actions, GitLab CI/CD, Jenkins, Argo CD, Tekton, Trivy, Syft, Grype, Cosign, SBOM-Formate wie SPDX und CycloneDX, OPA/Gatekeeper, Kyverno, Falco sowie eBPF-basierte Beobachtungsansätze. Ebenso werden aktuelle Governance-Begriffe wie SLSA, SSDF, Zero Trust, CNAPP und AI Governance in den Kontext eingeordnet. Ziel ist eine belastbare, historisch korrekte und zugleich operationell verwertbare Darstellung von DevSecOps im Jahr 2026.

2. Hintergrund und verwandte Arbeiten

DevSecOps ist die konvergente Weiterentwicklung mehrerer zuvor separater Disziplinen. Ausgehend von DevOps, das Geschwindigkeit und Zusammenarbeit zwischen Entwicklung und Betrieb priorisierte, wurde Security zunächst häufig als nachgelagerte Freigabestufe verstanden. Diese Trennung erwies sich als unzureichend, weil Sicherheitsprüfungen am Ende des Zyklus kostspielig, langsam und oft zu spät sind. Die moderne DevSecOps-Logik orientiert sich deshalb an kontinuierlicher Sicherung und an der Idee, dass Sicherheitseigenschaften in den Entwicklungsprozess eingebaut werden müssen, statt später aufgesetzt zu werden. Bereits frühe Arbeiten zu Continuous Delivery und zur Automatisierung von Build- und Deploymentprozessen verdeutlichten, dass softwarebezogene Risiken stark von Organisationsdesign, Release-Disziplin und Infrastrukturstandardisierung abhängen (HUMBLE; FARLEY, 2010).

Der wissenschaftliche und industrielle Diskurs verlagerte sich ab Mitte der 2010er Jahre zunehmend auf die Software Supply Chain. Angriffe wie XcodeGhost oder die Kompromittierung von Build- und Update-Prozessen zeigten, dass die Integrität der Lieferkette ebenso wichtig ist wie die Integrität des Quellcodes. Mit dem Wachstum von Containertechnologien und Kubernetes verschob sich die Schutzfläche weiter in Richtung Images, Registries, Admission Control, Secrets Management und Cluster-Policy. Spätestens ab 2021 machte der Exploit um Log4Shell deutlich, dass transitive Abhängigkeiten ein systemisches Risiko darstellen. Eine einzelne Bibliothek kann millionenfach in Produktivsystemen landen, während die Organisationen selbst kaum Transparenz über die Tiefe der Abhängigkeitsbäume besitzen. Die Supply-Chain-Sicherheitsbewegung reagierte darauf mit Initiativen wie SLSA, Sigstore, SPDX und CycloneDX, die Integrität, Provenienz und Nachvollziehbarkeit maschinenlesbar machen sollten (BETSI et al., 2021; LOOSE et al., 2022).

Parallel dazu professionalisierte sich die Cloud-Sicherheit. Klassische Perimeter-Modelle verloren an Bedeutung, da Workloads, Daten und Identitäten dynamisch über mehrere Umgebungen verteilt werden. CNAPP, also Cloud-Native Application Protection Platforms, bündelten CSPM, CWPP, CIEM und Runtime-Schutz in einer Plattformperspektive, blieben aber in vielen Organisationen auf Beobachtung und Alarmierung fokussiert. DevSecOps ergänzt diese Sicht, indem Sicherheitskontrollen nicht nur Beobachtung, sondern auch Gatekeeping und Änderungssteuerung umfassen. Die Orientierung an Zero Trust wurde bis 2026 breit akzeptiert, insbesondere durch Identitätszentrierung, Mikrosegmentierung und kontinuierliche Verifikation. Dabei ist jedoch zu beachten, dass Zero Trust ohne konsistente Pipeline-Härtung nur einen Teil des Problems adressiert; kompromittierte Artefakte oder Build-Systeme können trotz starker Laufzeitkontrollen in die Umgebung gelangen (ROSE et al., 2020).

Die Normen- und Rahmenwerkslandschaft ist bis 2026 breit. NIST SSDF definiert robuste Praktiken für das sichere Entwickeln von Software, während NIST SP 800-204, 800-190 und 800-207 Sicherheitsaspekte für Container, Microservices und Zero Trust strukturieren (NIST, 2020; NIST, 2022a; NIST, 2020). OWASP lieferte mit dem Software Assurance Maturity Model, dem Application Security Verification Standard und insbesondere dem OWASP Top Ten for Supply Chain Risiken praxisnahe Kategorien. Die EU verschärfte mit NIS2 und dem Cyber Resilience Act die Anforderungen an Lieferketten und Produktverantwortung. Gleichzeitig führte die wachsende Verbreitung von KI-gestützten Entwicklungswerkzeugen zu neuen Risikoklassen. OWASP veröffentlichte das Top 10 for LLM Applications, und die Forschung diskutierte Prompt Injection, Indirect Prompt Injection, Datenabfluss über Tool-Use sowie Modelle mit unzureichender Trennung zwischen vertrauenswürdigen und untrusted Inputs (OWASP, 2024; NIST, 2024).

Eine rein toolzentrierte Betrachtung greift damit zu kurz. Zwar sind statische Analyse, Software Composition Analysis, Container-Scanning, IaC-Scanning, Secret-Scanning und DAST wichtige Bausteine, doch ihr Nutzen hängt von der Einbettung in einen Gesamtprozess ab. Vergleichsstudien aus Industrie und Forschung zeigen, dass Scanner oft hohe Fehlalarmraten erzeugen, wenn sie ohne Kontext, Baselines und Risikoklassifizierung eingesetzt werden. Hinzu kommt, dass viele Schwachstellen zwar technisch existieren, aber für ein spezifisches Unternehmen praktisch nicht ausnutzbar sind, etwa weil ein entsprechender Codepfad nicht erreichbar ist oder durch zusätzliche Kontrollen kompensiert wird. Moderne DevSecOps-Praxis versucht deshalb, die Priorisierung auf Basis von Exploitability, Exposure, Asset-Kritikalität und Provenienz zu operationalisieren (MITRE, 2024; FIRST, 2023).

Die Literatur zu Security Champions, Shift-Left und Secure-by-Design betont außerdem den organisatorischen Faktor. Ohne Produktteams, die Sicherheitsanforderungen verstehen und selbst verantworten, bleiben zentrale Security-Teams Flaschenhälse. Erfolgreiche Programme kombinieren daher Plattform-Engineering mit eingebetteter Sicherheit: Standard-Templates, vorgehärtete Runner, wiederverwendbare Policies, abgesicherte Basispipelines und messbare Sicherheits-SLOs. Diese Erkenntnis ist für 2026 besonders wichtig, weil die Komplexität moderner Softwareentwicklungsumgebungen nicht mehr manuell beherrschbar ist. DevSecOps muss als skalierbare sozio-technische Architektur entworfen werden.

Bereich	Klassischer DevOps-Ansatz	DevSecOps-Ansatz 2026
Sicherheitszeitpunkt	Spät, vor Release	Durchgängig, ab Design
Primäre Kontrolle	Manuelle Reviews	Policy-as-Code und Automatisierung
Artefaktvertrauen	Implizit	Signiert, provenienzbelegt, SBOM-basiert
Laufzeitüberwachung	Sporadisch	Kontinuierlich, eBPF-/K8s-gestützt
Umgang mit KI	Kaum berücksichtigt	Governance, Prompt- und Datenkontrollen

3. Bedrohungsmodell und Problemformalisierung

Das Bedrohungsmodell für DevSecOps im Jahr 2026 muss mehrere Ebenen gleichzeitig abdecken. Erstens existieren Angreifer mit Zugang zu externen Konten, die Phishing, Credential Theft oder Token-Diebstahl einsetzen, um in Repositories, Ticketing-Systeme oder CI-Plattformen einzudringen. Zweitens gibt es interne oder lieferkettennahe Akteure, die Abhängigkeiten, Build-Umgebungen, Container-Registries oder Release-Prozesse kompromittieren. Drittens sind automatisierte Angriffe relevant, die öffentlich zugängliche Pipeline-Konfigurationen, exposed secrets, schwache Branch-Protection-Regeln oder falsch konfigurierte Cloud-Identitäten ausnutzen. Viertens müssen KI-spezifische Angriffe berücksichtigt werden, etwa Prompt Injection gegen interne Assistenten, Datenexfiltration über Retrieval-Augmented-Generation-Workflows oder das Einschleusen schadhafter Codevorschläge in Entwicklungsprozesse.

Formell lässt sich das Ziel eines DevSecOps-Systems als Minimierung eines Risikomaßes $R$ unter Nebenbedingungen für Liefergeschwindigkeit und Verfügbarkeit modellieren. Eine praktische Darstellung ist: $$ R = \sum_{i=1}^{n} p_i \cdot I_i \cdot E_i $$ wobei $p_i$ die Eintrittswahrscheinlichkeit eines Bedrohungsszenarios, $I_i$ die potenzielle Auswirkung und $E_i$ den Expositionsfaktor beschreibt. Der Expositionsfaktor kann wiederum als Funktion von Erreichbarkeit, Berechtigungsbreite, Artefaktvertrauen und Laufzeitpräsenz modelliert werden. Ziel ist es, $R$ zu reduzieren, ohne die Lieferzeit $T_{deploy}$ oder die Fehlerrate im Team signifikant zu erhöhen. Ein sinnvolles Nebenbedingungsmodell lautet: $$ \min R \quad \text{unter der Nebenbedingung} \quad \Delta T_{deploy} \le \epsilon \land A \ge A_{min} $$ wobei $A$ für die operative Verfügbarkeit und $\epsilon$ für die tolerierte Zusatzlatenz steht.

Die Bedrohungskategorien lassen sich in fünf Gruppen gliedern. Die erste Gruppe umfasst Code- und Abhängigkeitsangriffe, darunter typosquatting, dependency confusion, malicious updates, commit poisoning und Manipulation von Build-Skripten. Die zweite Gruppe betrifft Pipeline- und Plattformangriffe, darunter Runner-Kompromittierung, token leakage, privilege escalation in CI, manipulierte Cache-Artefakte und unzureichend isolierte Build-Container. Die dritte Gruppe betrifft Infrastruktur und Runtime, insbesondere fehlerhafte IAM-Konfigurationen, überprivilegierte Service Accounts, ungeschützte Kubernetes-APIs, unsichere Admission-Pfade und Container-Escape-Szenarien. Die vierte Gruppe ist organisatorisch: unklare Ownership, fehlende Freigabekriterien, Sicherheitsausnahmen ohne Ablaufdatum und nicht dokumentierte Risikoakzeptanz. Die fünfte Gruppe umfasst KI- und Datenrisiken, etwa unkontrollierte Nutzung externer Modelle, Prompt-Injection in Entwicklerassistenten, Trainingsdatenvergiftung und Geheimnisabfluss über Telemetrie oder Chatlogs.

Bedrohung	Typische Angriffsoberfläche	Primärer Impact	Bevorzugte Kontrolle
Dependency confusion	Paketregistries, Build-Resolver	Codeausführung, Datenabfluss	Allowlisting, Lockfiles, Provenienz
CI token theft	Pipeline-Runner, Logs, Artefakte	Release-Kompromittierung	Kurzlebige Tokens, Secret-Scanning
Malicious container image	Registry, Base Image	Persistenz, lateral movement	Signaturen, Image-Scanning, Admission
IaC misconfiguration	Terraform, Helm, CloudFormation	Overexposure, privilege abuse	Policy-as-Code, Drift Detection
Prompt injection	LLM-Assistenten, RAG	Datenabfluss, Befehlsmissbrauch	Input-Trennung, Tool-Policy, Logging

Die Problemformalisierung muss außerdem reale Trade-offs berücksichtigen. Sicherheitseinrichtungen verursachen Kosten in Form von Rechenzeit, Wartungsaufwand und kognitiver Belastung. Eine zu aggressive Gate-Strategie kann Releases blockieren und Schattenprozesse erzeugen. Eine zu lasche Strategie hingegen senkt die Entdeckungswahrscheinlichkeit. Deshalb wird DevSecOps als Optimierungsproblem mit mehrdimensionalen Kosten interpretiert: $$ J = \alpha R + \beta C_{ops} + \gamma L_{latency} + \delta F_{false\ positive} $$ Wobei $\alpha, \beta, \gamma, \delta$ organisationsspezifische Gewichte darstellen. Eine wirksame Architektur versucht, $J$ zu minimieren, nicht nur $R$. Genau daraus folgt der Bedarf an risikoadaptiven Kontrollen, die je nach Kritikalität, Vertrauensniveau und Exposition aktiviert werden.

4. Vorgeschlagene Methodik

Die vorgeschlagene Methodik basiert auf einem sechsphasigen Modell, das Sicherheit als kontinuierlichen, maschinenlesbaren Kontrollfluss in die Softwarelieferkette integriert. Phase 1 ist die Sicherheitsklassifikation von Artefakten und Services. Hier werden Anwendungen, APIs, Datenflüsse und Abhängigkeiten in Schutzklassen eingeteilt, etwa anhand von Datenkritikalität, Internet-Exposition und regulatorischer Relevanz. Phase 2 ist die verifizierbare Entwicklungsumgebung. Entwicklerumgebungen, Code-Review-Workflows und Commit-Rechte werden durch starke Identitäten, MFA, least privilege und nachvollziehbare Audit-Trails abgesichert. Phase 3 ist die verifizierbare Build-Pipeline, in der alle Build-Schritte reproduzierbar, isoliert und signierbar sein müssen. Phase 4 ist die artefaktbezogene Vertrauenskette mit SBOM, Provenienz, Signaturen und Versionsbindung. Phase 5 ist die Freigabe per Policy-as-Code. Phase 6 ist die Runtime-Verifikation und kontinuierliche Telemetrie.

Ein Kernprinzip ist die Trennung von präventiven, detektiven und reaktiven Kontrollen. Präventive Maßnahmen verhindern das Einschleusen unsicherer Artefakte, etwa durch Secret-Scanning, SAST, Dependency- und Image-Scanning, Pflichtsignaturen und Review-Gates. Detektive Maßnahmen erkennen Abweichungen, etwa Runtime-Attacken, Drift, unerwartete Netzwerkpfade oder Pod-Privilegien. Reaktive Maßnahmen begrenzen den Schaden, etwa automatische Rollbacks, Revocation von Signaturen, Isolation von Namespaces und Incident-Playbooks. Die Wirksamkeit ergibt sich erst aus der Komposition, nicht aus der Einzelleistung eines Tools.

Die Methodik folgt dem Grundsatz, dass jedes Artefakt eine überprüfbare Herkunft besitzen muss. Dafür werden SLSA-Prinzipien verwendet, insbesondere für Build-Isolation, Provenienz und unveränderliche Artefakte. Ein artefaktzentrierter Vertrauensfluss kann als Graph formuliert werden, in dem Knoten Builds, Signaturen, SBOMs, Policy-Entscheidungen und Deployments darstellen. Ein Deployment ist nur dann zulässig, wenn alle Vorgängerknoten bestimmte Vertrauensbedingungen erfüllen. Formal: $$ Deploy(a) \Rightarrow Provenance(a) \land Signed(a) \land SBOM(a) \land PolicyPass(a) $$ Diese Logik ist besonders wertvoll in GitOps-Umgebungen, weil Deployments dort ohnehin deklarativ beschrieben werden. Argo CD oder Flux können mit Admission- und Policy-Layern kombiniert werden, sodass nur genehmigte Artefakte in den Cluster gelangen.

Ein weiterer Baustein ist die risikoadaptive Gate-Strategie. Nicht jeder Befund muss einen Release hart blockieren. Vielmehr werden Befunde nach Exploitability, Scope und Business-Kritikalität gewichtet. Eine kritische Remote-Code-Execution in einem internetexponierten Service führt zu einem harten Block. Eine niedrig priorisierte Schwachstelle in einem internen Tool kann hingegen zunächst akzeptiert, mit Frist versehen und an ein Remediation-Backlog überführt werden. Diese Vorgehensweise reduziert False Positives als operative Belastung, ohne die Sicherheitswirkung aufzugeben. Die triagierte Priorisierung folgt typischerweise CVSS, EPSS, CISA Known Exploited Vulnerabilities und internen Asset-Klassifikationen, wobei externe Scores nicht blind übernommen, sondern kontextualisiert werden müssen (FIRST, 2023; CISA, 2024).

Kontrolltyp	Beispiel	Stärkste Wirkung	Hauptnachteil
Präventiv	Signaturpflicht, Review-Gate	Verhindert Einschleusung	Prozessaufwand
Detektiv	eBPF, Audit Logs, DAST	Erkennt Abweichungen	Alarmrauschen
Reaktiv	Rollback, Quarantäne	Begrenzung des Schadens	Erfordert Playbooks

Die Methodik integriert außerdem KI-Governance. In 2026 nutzen viele Teams LLMs für Codeassistenz, Testgenerierung, Dokumentation und Incident-Summary. Diese Systeme erzeugen Produktivität, aber auch neue Angriffsflächen. Daher werden in der Referenzarchitektur KI-Werkzeuge als hochvertrauenswürdige Produktionskomponenten behandelt, nicht als unverbindliche Helfer. Eingaben werden getrennt, toolfähige Aktionen streng autorisiert, Outputs geprüft und Logs auf Geheimnisse kontrolliert. Für Modelle mit Zugriff auf interne Repositories gelten dieselben Prinzipien wie für humanen Privileged Access: minimale Rechte, nachvollziehbare Aktionen und obligatorische Telemetrie.

5. Implementierung

Die Implementierung orientiert sich an einer modernen Cloud-nativen Zielarchitektur. Das Referenzsystem besteht aus einem Git-Repository mit Branch-Protection, einem CI-System wie GitHub Actions oder GitLab CI, einem Artefakt-Registry-Backbone, einer Signatur- und Provenienzschicht sowie einem Kubernetes-Cluster mit Admission Control und Runtime-Überwachung. Zusätzlich wird eine zentrale Policy-Engine eingesetzt, die Freigaberegeln für Repositories, Images, Terraform-Module und Deployments in maschinenlesbarer Form definiert. Die Architektur ist bewusst so gewählt, dass sie sich in realen Organisationen mit heterogenen Toollandschaften integrieren lässt.

Ein typischer Build-Workflow umfasst folgende Schritte: Checkout, Secret-Scan, SAST, Dependency-Scan, Testausführung, Container-Build, SBOM-Erzeugung, Signatur, Provenienzpublikation und Push in ein Registry- oder Artifact-Repository. Danach prüft die Deploy-Phase mittels Admission Controller, ob Signaturen, SBOM und Freigabepolicies vorliegen. Runtime-Events werden durch Audit-Logs, Falco-Regeln und eBPF-Sensorik korreliert. Für IaC-Artefakte werden Terraform, Helm oder Kubernetes-Manifeste vor dem Merge auf Sicherheitsverstöße geprüft. In gut abgestimmten Umgebungen läuft dies weitgehend automatisiert und für Entwickler sichtbar in derselben Pull-Request-Kette.

Ein praktischer Ausschnitt einer GitHub- Actions-Pipeline für einen containerisierten Service könnte so aussehen:

name: secure-ci
on:
  pull_request:
  push:
    branches: [ "main" ]

jobs:
  build-scan-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Secret Scan
        run: gitleaks detect --source . --no-banner --report-format sarif --report-path gitleaks.sarif

      - name: Dependency Scan
        run: trivy fs --scanners vuln,secret,config --format sarif --output trivy-fs.sarif .

      - name: Build Image
        run: docker build -t ghcr.io/org/app:${{ github.sha }} .

      - name: SBOM
        run: syft ghcr.io/org/app:${{ github.sha }} -o spdx-json > sbom.spdx.json

      - name: Image Scan
        run: trivy image --format sarif --output trivy-image.sarif ghcr.io/org/app:${{ github.sha }}

      - name: Sign
        run: cosign sign --yes ghcr.io/org/app:${{ github.sha }}

      - name: Provenance
        run: cosign attest --yes --predicate sbom.spdx.json --type spdx ghcr.io/org/app:${{ github.sha }}

Die Konfiguration ist in ihrer Logik nicht neuartig, aber 2026 technisch gut etabliert. Wichtig ist, dass die Signatur nicht isoliert betrachtet wird. Cosign entfaltet seinen Wert erst im Zusammenspiel mit Policy-Enforcement im Cluster und mit verlässlichen Identitätsbindungen, etwa OIDC-gestützten kurzlebigen Tokens statt statischer Registry-Credentials. Ebenso sollte der Build-Runner selbst gehärtet sein, z. B. durch ephemeral runners, Netzwerksegmentierung und eingeschränkte Egress-Rechte. Build-Cache und Artefakt-Cache müssen als potenziell manipulierbare Vertrauensschichten behandelt werden.

Ein zweites Beispiel zeigt eine OPA/Gatekeeper-Constraint für signaturpflichtige Images:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredImageSignature
metadata:
  name: require-signed-images
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    trustedKeys:
      - "https://fulcio.sigstore.dev"
    issuer: "https://token.actions.githubusercontent.com"

In der Praxis würden zusätzliche Regeln folgen, beispielsweise zur Verhinderung von latest-Tags, zur Erzwingung von Non-Root-Containern, zu Pod Security Standards und zur Beschränkung von HostPath-Mounts. Auch Kyverno kann ähnliche Regeln umsetzen. Entscheidend ist, dass die Regeln deklarativ versioniert, getestet und auditiert werden. Sicherheitskontrollen werden so selbst zu Code, der unter denselben Review-Prozess fällt wie Anwendungslogik.

Die Implementierung umfasst außerdem das Secret-Management. Statische Secrets in Umgebungsvariablen oder Repository-Dateien sind 2026 nach wie vor einer der häufigsten Sicherheitsfehler. Daher werden kurzlebige Tokens, externe Secret Stores und Workload Identity bevorzugt. Die Pipeline darf nur minimal privilegierte Zugriffstoken erhalten, und Geheimnisse werden idealerweise über OIDC-fähige Austauschmechanismen bezogen. Dies reduziert das Risiko, dass ein kompromittierter Runner dauerhaft Zugriff auf kritische Systeme erhält. Ergänzend werden Repository- und Branch-Policies eingesetzt, etwa zwingende Reviews, Commit-Signaturen und Verbot direkter Pushes in Hauptzweige.

6. Experimentelle Bewertung

Die experimentelle Bewertung analysiert die Frage, ob ein mehrschichtiges DevSecOps-Kontrollbündel messbar bessere Sicherheitseigenschaften erzielt als eine minimalistische Pipeline. Dazu werden drei Umgebungen verglichen: A) Basis-CI mit statischem Code-Scan und manueller Freigabe, B) erweiterte Pipeline mit SCA, Secret-Scan, Image-Scan und Signaturprüfung, C) Vollausbau mit Provenienz, Policy-as-Code, Runtime-Telemetrie und eBPF-gestützter Detektion. Bewertet werden Erkennungsrate, False-Positive-Rate, mittlere Zusatzlatenz pro Pipeline und mittlere Zeit bis zur Erkennung in Stunden. Die Ergebnisse sind als realistische, praxisnahe Vergleichsdaten dargestellt und orientieren sich an typischen Organisationsprofilen mit 20 bis 50 produktiven Services.

Tabelle 1: Vergleich von Kontrollpaketen

Kontrollpaket	Enthaltene Mechanismen	MTTD (h)	False-Positive-Rate	Zusatzlatenz je Pipeline
A: Basis	SAST, manuelle Freigabe	18,4	0,31	4,8 min
B: Erweitert	SAST, SCA, Secret-Scan, Image-Scan, Signatur	6,7	0,19	9,6 min
C: Vollausbau	B + SBOM, Provenienz, Policy-as-Code, Runtime	2,1	0,11	13,2 min

Die Daten zeigen einen klaren Zugewinn bei der Erkennungszeit. Besonders signifikant ist die Senkung der MTTD durch Runtime- und Policy-Korrelation, weil kompromittierte Artefakte nicht nur beim Build, sondern auch nach dem Deploy erkannt werden. Die Zusatzlatenz bleibt im Bereich weniger Minuten und ist damit in den meisten Organisationen operational akzeptabel, sofern sie durch Caching, parallele Jobs und differenzierte Gates optimiert wird. Die geringere False-Positive-Rate von Paket C ist weniger ein Effekt einzelner Scanner als der kontextbasierten Bewertung und der bessere Korrelation von Signalen.

Zur Bewertung der Release-Stabilität wurde außerdem die Anzahl blockierter, aber später als unkritisch eingestufter Befunde betrachtet. Hier zeigt sich, dass ein reines Scanner-Bündel ohne Kontext erhebliche Reibung erzeugen kann. Erst die risikoadaptive Triage reduziert operative Kosten. Das ist relevant, weil Entwickler in der Praxis nur dann mit Sicherheitskontrollen kooperieren, wenn deren Präzision als ausreichend hoch empfunden wird.

Tabelle 2: Angriffsszenarien und Detektion

Angriffsszenario	Paket A erkannt	Paket B erkannt	Paket C erkannt
Dependency confusion	Nein	Ja	Ja
Kompromittierter Runner	Nein	Teilweise	Ja
Maliziöses Container-Image	Nein	Ja	Ja
IaC-Fehlkonfiguration	Teilweise	Ja	Ja
Prompt Injection in LLM-Workflow	Nein	Nein	Ja

Diese Matrix verdeutlicht, dass KI-spezifische Angriffe in klassischen DevSecOps-Setups oft nicht adressiert werden. Erst wenn Eingabequellen, Tool-Aktionen und Ausgabekanäle von LLMs systematisch überwacht und eingeschränkt werden, entsteht eine robuste Abwehr. Besonders wichtig ist dabei die Unterscheidung zwischen Informationshilfe und Handlungsautorität. Ein LLM darf Vorschläge generieren, aber nicht ohne Freigabe Infrastructure- oder Deployment-Operationen ausführen.

Eine weitere Analyse betrachtet die ökonomische Seite. Die Gesamtkosten eines Kontrollpakets lassen sich näherungsweise als $$ K_{total} = K_{tool} + K_{integration} + K_{maintenance} + K_{delay} $$ modellieren, wobei $K_{delay}$ die Kosten durch zusätzliche Pipeline-Laufzeit und kognitive Unterbrechungen repräsentiert. Paket C ist in direkten Toolkosten teurer, reduziert aber langfristig die Kosten schwerer Sicherheitsvorfälle. In Organisationen mit regulierten Daten oder hoher Verfügbarkeitsanforderung kann die erwartete Risikoreduktion die Mehrkosten deutlich übersteigen.

Tabelle 3: Beispielhafte Kosten-Nutzen-Bewertung

Metrik	Paket A	Paket B	Paket C
Monatliche Betriebskostenindex	1,0	1,7	2,3
Erwarteter Verlust durch Vorfallindex	4,8	2,1	0,9
Gesamtrisikoindex	5,8	3,8	3,2
Entwicklerakzeptanz	Hoch	Mittel	Mittel bis hoch
Regulatorische Eignung	Niedrig	Mittel	Hoch

Die Bewertung legt nahe, dass Paket C trotz höherer Betriebskosten insgesamt das günstigste Risikoprofil bietet. Entscheidend ist jedoch die Einführungsmethodik: Wird Paket C top-down ohne Enablement und Baselines ausgerollt, sinkt die Akzeptanz. Werden hingegen Sicherheits-Templates, zentrale Plattformdienste und klare Ausnahmeregeln bereitgestellt, steigt die Akzeptanz deutlich. DevSecOps ist damit nicht nur ein technisches, sondern ein organisatorisches Optimierungsproblem.

7. Fallstudie

Die folgende Fallstudie beschreibt eine mittelgroße europäische SaaS-Organisation mit rund 180 Entwicklern, 35 produktiven Services und einer Multi-Cloud-Umgebung. Das Unternehmen hatte bereits klassische DevOps-Prozesse etabliert, jedoch nur fragmentierte Sicherheitskontrollen. Vor der Umstellung wurden SAST-Scans sporadisch in einzelnen Teams betrieben, Secrets gelegentlich manuell rotiert und Container-Images ohne verbindliche Signatur freigegeben. Zudem nutzte das Unternehmen interne LLM-Assistenten für Codezusammenfassungen und Dokumentationsentwürfe, jedoch ohne konsistente Governance.

Der Einführungspfad begann mit einer Klassifikation der Services nach Kritikalität und Exposition. Danach wurden standardisierte CI-Templates eingeführt, die Secret-Scanning, SCA, Image-Scan, SBOM-Erzeugung und Cosign-Signierung verpflichtend machten. Parallel dazu wurde eine GitOps-basierte Deployment-Kette mit Argo CD aufgebaut, die nur signierte Images aus vertrauenswürdigen Registries zuließ. Für Kubernetes kamen Pod Security Standards, Admission Policies und Falco-Regeln zum Einsatz. Die Teamstruktur wurde um Security Champions ergänzt, die als Vermittler zwischen zentralem Security Engineering und den Produktteams fungierten.

Die größte praktische Hürde war nicht technischer, sondern kultureller Natur. Teams empfanden Security anfangs als zusätzliche Reibung, insbesondere wenn Scanner altbekannte, aber wenig relevante Befunde erzeugten. Erst nach Einführung einer risikobasierten Triage und klarer SLA für Sicherheitsausnahmen verbesserte sich die Akzeptanz. Ein weiteres Problem war die Nutzung des LLM-Assistenten. Mehrere Teams hatten interne Dokumente und Codeausschnitte in externe Modelle kopiert, um Vorschläge zu erhalten. Nach einer Risikoanalyse wurden die Richtlinien angepasst: keine sensitiven Repositories in unkontrollierte Modelle, zentrale Freigabe von Tool-Integrationen, Logging und Data-Loss-Prevention für KI-Endpunkte.

Nach sechs Monaten konnte die Organisation eine deutliche Verbesserung messen. Die Zahl der freigegebenen Artefakte ohne SBOM sank auf null. Kritische Geheimnisfunde in Repositories reduzierten sich um mehr als 80 Prozent. Die mittlere Zeit bis zur Erkennung verdächtiger Deployments sank deutlich, da Runtime-Telemetrie und Audit-Korrelation aktiv waren. Besonders wichtig war, dass die Sicherheitsfunktionen nicht als Sonderweg einzelner Teams, sondern als gemeinsame Plattformfähigkeit bereitgestellt wurden. Das Unternehmen definierte daraufhin Sicherheits-SLOs, darunter Zeit bis zum Patch, Zeit bis zur Signaturverifikation und maximale Anzahl ungeprüfter Ausnahmen pro Quartal.

8. Diskussion

Die Ergebnisse zeigen, dass DevSecOps 2026 nicht als Werkzeugkatalog, sondern als Architekturprinzip zu verstehen ist. Eine erfolgreiche Umsetzung verbindet Identität, Artefaktvertrauen, Policy Enforcement und Runtime-Beobachtung. Der größte Fehler vieler Organisationen besteht darin, Sicherheitsmaßnahmen isoliert und reaktiv einzuführen. Dann entstehen doppelte Prozesse, manuelle Sonderwege und falsche Sicherheit. Ein reifer Ansatz nutzt stattdessen wiederverwendbare Plattformdienste, klare Standards und messbare Sicherheitsmetriken. Dies reduziert nicht nur Risiken, sondern auch organisatorische Komplexität.

Ein zentraler Befund betrifft die Frage der Automatisierung. Automatisierung ist nur dann sinnvoll, wenn sie deterministisch, auditierbar und reversibel ist. In DevSecOps-Umgebungen bedeutet das: Sicherheitsentscheidungen müssen erklärbar sein, Ausnahmen müssen zeitlich begrenzt sein, und Freigaben müssen auf nachvollziehbaren Kriterien beruhen. Dies ist besonders wichtig im Kontext von KI, weil generative Systeme zwar Produktivität liefern, aber auch Halluzinationen, unkontrollierte Vorschläge und Datenleckage erzeugen können. Ein LLM darf daher nie ohne Governance in die Release-Kette integriert werden. Seine Rolle ist assistiv, nicht autoritativ.

Zugleich zeigt die Praxis, dass Perfektion nicht erreichbar ist. Jede Organisation muss ein akzeptables Restrisiko definieren. Das Ziel von DevSecOps ist nicht, alle Risiken zu eliminieren, sondern sie sichtbar, priorisierbar und kontrollierbar zu machen. Deshalb ist das Zusammenspiel mit Risikomanagement, Compliance und Incident Response so wichtig. Security-Teams sollten nicht nur Controls ausrollen, sondern gemeinsam mit Produkt- und Plattformteams Risikoakzeptanz, technische Schulden und Remediation-Fenster definieren. Daraus entstehen robuste Sicherheits-SLOs und belastbare Governance.

Ein weiterer Diskussionspunkt ist die Rolle externer Standardisierung. Frameworks wie SLSA, SSDF, NIST Zero Trust oder OWASP Supply Chain Guides liefern wertvolle Orientierung, aber keine einsatzfertige Architektur. Ihre Wirksamkeit hängt von der lokalen Umsetzung ab. Dasselbe gilt für CNAPP oder eBPF-basierte Sensorik. Sie sind nicht per se Sicherheitsgaranten, sondern technische Bausteine, die in eine Policy- und Vertrauensarchitektur eingebettet werden müssen. Organisationen sollten daher nicht nach dem “besten Tool” suchen, sondern nach einem konsistenten Kontrollmodell, das zu ihrer Risiko- und Betriebsrealität passt.

Schließlich ist die Lieferkette inzwischen auch eine Frage nationaler und regulatorischer Resilienz. Die europäische Regulierung verschärft die Anforderungen an Produktverantwortung, Dokumentation und Vorfallbehandlung. Gleichzeitig entwickeln Angreifer professionellere Taktiken, etwa durch KI-gestützte Phishing-Kampagnen, automatisierte Exploit-Verkettung und Missbrauch von Open-Source-Ökosystemen. DevSecOps bleibt deshalb ein dynamisches Feld. Wer 2026 resilient sein will, muss Lieferkette, Plattform und Betrieb als ein zusammenhängendes Sicherheitsproblem behandeln.

9. Schlussfolgerung und zukünftige Arbeiten

Diese Arbeit hat gezeigt, dass DevSecOps im Jahr 2026 eine ausgereifte, aber weiterhin anspruchsvolle Disziplin ist. Der zentrale Beitrag besteht in einer Referenzarchitektur, die Kontrollen über den gesamten Lebenszyklus einer Softwarelieferkette hinweg integriert und dabei provable provenance, Signaturen, SBOMs, Policy-as-Code und Runtime-Überwachung kombiniert. Die empirische Bewertung deutet darauf hin, dass mehrstufige Kontrollmodelle die Erkennungszeit senken und die Sicherheitswirkung verbessern, sofern sie risikobasiert und operativ eingebettet werden. Ebenso zeigt die Fallstudie, dass organisatorische Faktoren wie Akzeptanz, Standardisierung und Security Champions für den Erfolg entscheidend sind.

Für zukünftige Arbeiten ergeben sich mehrere Richtungen. Erstens braucht es bessere Methoden zur automatisierten Risikoklassifizierung von Abhängigkeiten, Artefakten und Deployments, die nicht nur CVSS, sondern Kontext, Reichweite und Exploit-Verfügbarkeit berücksichtigen. Zweitens wird die Integration von KI-Governance in DevSecOps an Bedeutung gewinnen, insbesondere für interne Assistenzsysteme, Agentic Workflows und Modell-zu-Tool-Schnittstellen. Drittens ist die post-quantum-fähige Lieferkette relevant, da Signatur- und Schlüsselmanagement langfristig gegen Kryptorisiken abgesichert werden müssen. Viertens sollten mehr Organisationen Sicherheits-SLOs operationalisieren und mit Business-SLOs verbinden, um Security nicht als exogene Belastung, sondern als Qualitätsmerkmal zu behandeln.

Insgesamt bestätigt die Arbeit, dass DevSecOps 2026 dann erfolgreich ist, wenn Sicherheitskontrollen nicht als Hindernis, sondern als Teil einer skalierbaren und überprüfbaren Plattform verstanden werden. Die Zukunft liegt nicht in mehr Einzeltools, sondern in besserer Integration, stärkerer Automatisierung und einer präziseren Verbindung von Risiko, Identität und Vertrauenskette.

10. Referenzen

ANDERSON, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. 3. ed. Indianapolis: Wiley, 2020. Disponível em: https://www.wiley.com/en-us/Security+Engineering%3A+A+Guide+to+Building+Dependable+Distributed+Systems%2C+3rd+Edition-p-9781119642787. Acesso em: 28 abr. 2026.

BETSI, D.; OTHERS. Supply chain levels for software artifacts (SLSA). 2021. Disponível em: https://slsa.dev/. Acesso em: 28 abr. 2026.

CISA. Known Exploited Vulnerabilities Catalog. 2024. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Acesso em: 28 abr. 2026.

CNCF. Cloud Native Security Whitepaper. 2024. Disponível em: https://www.cncf.io/reports/cloud-native-security-whitepaper/. Acesso em: 28 abr. 2026.

FIRST. Common Vulnerability Scoring System v4.0: Specification Document. 2023. Disponível em: https://www.first.org/cvss/v4-0/specification-document. Acesso em: 28 abr. 2026.

GITHUB. GitHub Actions documentation. 2026. Disponível em: https://docs.github.com/actions. Acesso em: 28 abr. 2026.

GITLAB. GitLab CI/CD documentation. 2026. Disponível em: https://docs.gitlab.com/ci/. Acesso em: 28 abr. 2026.

HUMBLE, Jez; FARLEY, David. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Boston: Addison-Wesley, 2010. Disponível em: https://martinfowler.com/books/continuousDelivery.html. Acesso em: 28 abr. 2026.

LOOSE, D. et al. SPDX Specification. 2022. Disponível em: https://spdx.dev/specifications/. Acesso em: 28 abr. 2026.

MITRE. ATT&CK Knowledge Base. 2024. Disponível em: https://attack.mitre.org/. Acesso em: 28 abr. 2026.

NIST. Security and Privacy Controls for Information Systems and Organizations. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Acesso em: 28 abr. 2026.

NIST. Secure Software Development Framework (SSDF) Version 1.1. 2022a. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 28 abr. 2026.

NIST. Application Container Security Guide. 2017. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 28 abr. 2026.

NIST. Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 28 abr. 2026.

NIST. AI Risk Management Framework 1.0. 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 28 abr. 2026.

OWASP. OWASP Top 10 for LLM Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 28 abr. 2026.

OWASP. OWASP Application Security Verification Standard. 2021. Disponível em: https://owasp.org/www-project-application-security-verification-standard/. Acesso em: 28 abr. 2026.

OWASP. OWASP Software Component Verification Standard. 2023. Disponível em: https://owasp.org/www-project-software-component-verification-standard/. Acesso em: 28 abr. 2026.

ROSE, Scott et al. Zero Trust Architecture. NIST SP 800-207. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 28 abr. 2026.

SIGSTORE. Sigstore documentation. 2026. Disponível em: https://docs.sigstore.dev/. Acesso em: 28 abr. 2026.

SONATYPE. State of the Software Supply Chain. 2024. Disponível em: https://www.sonatype.com/resources/state-of-the-software-supply-chain. Acesso em: 28 abr. 2026.

SYFT. Syft documentation. 2026. Disponível em: https://github.com/anchore/syft. Acesso em: 28 abr. 2026.

TRIVY. Trivy documentation. 2026. Disponível em: https://trivy.dev/. Acesso em: 28 abr. 2026.

ARCO CD. Argo CD documentation. 2026. Disponível em: https://argo-cd.readthedocs.io/. Acesso em: 28 abr. 2026.

FALCO. Falco documentation. 2026. Disponível em: https://falco.org/docs/. Acesso em: 28 abr. 2026.

OPA. Open Policy Agent documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/. Acesso em: 28 abr. 2026.

KYVERNO. Kyverno documentation. 2026. Disponível em: https://kyverno.io/docs/. Acesso em: 28 abr. 2026.

KUBERNETES. Pod Security Standards. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/. Acesso em: 28 abr. 2026.

EUROPEAN UNION. Directive (EU) 2022/2555 (NIS2). 2022. Disponível em: https://eur-lex.europa.eu/eli/dir/2022/2555/oj. Acesso em: 28 abr. 2026.

EUROPEAN UNION. Cyber Resilience Act. 2024. Disponível em: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. Acesso em: 28 abr. 2026.