Paper Files / DevSecOps

TITEL: Formale Sicherheitsorchestrierung in CI/CD-Pipelines: Quantitatives Risikomodell für DevSecOps mit MITRE ATT&CK-Korrelation und Betriebsmetriken

2008-06-04DevSecOpsDE

TITEL: Formale Sicherheitsorchestrierung in CI/CD-Pipelines: Quantitatives Risikomodell für DevSecOps mit MITRE ATT&CK-Korrelation und Betriebsmetriken ABSTRAKT: Die Einführung von DevOps-Praktiken hat den Softwareentwicklungszyklus tiefgreifend verändert, indem Automatisierung, Continuous Integration und Continuous Delivery priorisiert wurden. Allerdings hat die Beschleunigung von CI/CD-Pipelines die Angriffsfläche von Organisationen erheblich vergrößert, insbesondere im Kontext von Angriffen auf die Software-Lieferkette und der Ausnutzung verwundbarer Abhängigkeiten. Weitgehend dokumentierte Vorfälle wie die Kompromittierung der Vertriebskette von SolarWinds Orion (SUNBURST) und die massive Ausnutzung der Log4Shell-Schwachstelle (CVE‑2021‑44228) zeigen, dass während des Build-Prozesses eingeführte Fehler oder externe Abhängigkeiten Auswirkungen in globalem Ausmaß verbreiten können. Obwohl das DevSecOps-Paradigma die Integration von Sicherheitskontrollen in die Entwicklungspipeline vorsieht, ist die operative Praxis weiterhin durch eine oberflächliche Integration von Werkzeugen, das Fehlen quantitativer Risikometriken und den Mangel an Abstimmung zwischen den Ergebnissen automatisierter Scanner und formalen Bedrohungsmodellen gekennzeichnet. In dieser Arbeit schlagen wir ein quantitatives Modell für die Sicherheitsorchestrierung in CI/CD-Pipelines auf der Grundlage einer inkrementellen Risikoanalyse vor. Das Modell formalisert die Pipeline als gerichteten azyklischen Graphen und definiert eine Funktion des kumulativen Risikos, die CVSS-Bewertung, die mittels EPSS geschätzte Ausnutzungswahrscheinlichkeit, die Kritikalität des Assets und einen zeitlichen Faktor, der mit dem Alter der Schwachstelle verknüpft ist, kombiniert. Auf Basis dieser Formulierung führen wir einen adaptiven Blockierungsmechanismus ein, der dynamische Schwellenwerte verwendet, um während des Build-Prozesses automatisch über die Freigabe oder Ablehnung von Artefakten zu entscheiden. Wir implementierten das Modell in einer Kubernetes-Umgebung unter Verwendung weit verbreiteter Werkzeuge des DevSecOps-Ökosystems, darunter Semgrep, SonarQube, Trivy, Syft/Grype, OWASP ZAP und Checkov, sowie Laufzeitüberwachung mit Falco und Ereigniskorrelation mit der MITRE ATT&CK-Matrix. Die experimentelle Evaluation wurde in 1.200 Pipeline-Durchläufen mit 37 Mikrodiensten durchgeführt. Die Ergebnisse zeigen eine signifikante Reduzierung der Exposition gegenüber kritischen Schwachstellen in der Produktion sowie eine Verringerung der mittleren Remediationszeit ohne wesentliche Auswirkungen auf die Ausführungszeit der Pipeline. Die Studie zeigt, dass die mathematische Formalisierung von Risiko in CI/CD-Pipelines konsistentere automatisierte Entscheidungen ermöglicht und eine operative Grundlage für metrikengetriebene Sicherheitsgovernance in DevSecOps-Umgebungen bereitstellt.

Einleitung

Die digitale Transformation hat die Einführung von Architekturen auf Basis von Microservices, Containern und Orchestrierungsplattformen wie Kubernetes verstärkt. In diesem Kontext sind Pipelines für Continuous Integration und Continuous Delivery (CI/CD) zum zentralen Mechanismus für den Aufbau, das Testen und die Verteilung von Software in großem Maßstab geworden. Obwohl solche Pipelines die Produktivität von Entwicklungsteams erheblich steigern, führen sie auch neue Angriffsvektoren im Zusammenhang mit der Software-Supply-Chain ein (ENISA, 2023).

Empirische Berichte weisen darauf hin, dass ein großer Teil der Sicherheitsverletzungen aus betrieblichen Fehlern sowie aus der Ausnutzung von Anmeldedaten oder bekannten Schwachstellen resultiert. Der Data Breach Investigations Report 2023 zeigt, dass etwa 74 % der analysierten Verletzungen das menschliche Element oder den Missbrauch kompromittierter Zugangsdaten betreffen (VERIZON, 2023). Parallel dazu sind gezielte Angriffe auf die Software-Supply-Chain seit 2020 deutlich gewachsen und betreffen ganze Ökosysteme der Softwareentwicklung und -verteilung (CISA, 2023).

Groß angelegte Vorfälle veranschaulichen das Ausmaß dieses Problems. Die Kompromittierung der Plattform SolarWinds Orion im Rahmen der SUNBURST-Kampagne zeigte, wie kompromittierte Build-Artefakte an Tausende von Organisationen verteilt werden können. Ebenso machte die Schwachstelle Log4Shell (CVE‑2021‑44228) deutlich, wie schnell weit verbreitete Abhängigkeiten zu globalen Ausnutzungsvektoren werden können (NIST, 2023).

Als Reaktion auf dieses Szenario schlägt das DevSecOps-Paradigma vor, Sicherheitsmechanismen während des gesamten Softwareentwicklungszyklus zu integrieren. Theoretisch sollten Code-Scanner, Abhängigkeitsanalysen, dynamische Tests und Runtime-Monitoring in die CI/CD-Pipeline eingebettet werden. In der Praxis beobachten wir jedoch erhebliche strukturelle Einschränkungen.

Zunächst bleibt die Mehrzahl der DevSecOps-Implementierungen auf isolierte Werkzeuge ausgerichtet, ohne ein formales Modell, das die Ergebnisse mehrerer Scanner zu einer einheitlichen Risikometrik zusammenführt. Zweitens basieren kritische Entscheidungen — etwa das Blockieren oder Zulassen der Promotion eines Artefakts — häufig auf statischen Schwellenwerten und ignorieren kontextuelle Faktoren wie die Exploit-Wahrscheinlichkeit oder die Kritikalität des Dienstes. Schließlich werden Ergebnisse von Sicherheitswerkzeugen nur selten mit operativen Bedrohungsmodellen wie der MITRE-ATT&CK-Matrix korreliert, was die strategische Priorisierung von Gegenmaßnahmen erschwert (STROM et al., 2018).

Vor diesem Hintergrund formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das mit während CI/CD-Pipeline-Ausführungen identifizierten Schwachstellen verbundene Risiko formal modellieren?
RQ2: Ist es möglich, die Exposition gegenüber kritischen Schwachstellen in der Produktion ohne signifikante Erhöhung der Pipeline-Ausführungszeit zu reduzieren?
RQ3: Wie lassen sich die Befunde von DevSecOps-Werkzeugen mit in der MITRE-ATT&CK-Matrix beschriebenen Angriffstechniken korrelieren?

Um diese Fragen zu beantworten, schlagen wir ein quantitatives Modell für inkrementelles Risiko vor, das auf CI/CD-Pipelines angewendet wird. Unser Ansatz kombiniert standardisierte Schwachstellenmetriken mit kontextuellen operativen Faktoren und verwendet einen adaptiven Entscheidungsalgorithmus für die automatisierte Steuerung von Releases.

Die wesentlichen Beiträge dieser Arbeit sind:

formale Definition des akkumulierten Risikos in CI/CD-Pipelines auf Basis von CVSS- und EPSS-Metriken;
adaptiver Blocking-Algorithmus für die Förderung von Artefakten;
experimentelle Implementierung in einer Kubernetes-Umgebung mit weit verbreiteten DevSecOps-Werkzeugen;
empirische Evaluation mit quantitativen Leistungs- und Sicherheitsmetriken.

Hintergrund und verwandte Arbeiten

2.1 Sicherheit in Software-Supply-Chains

Angriffe auf Software-Supply-Chains sind in den letzten zehn Jahren zu einer der wichtigsten Sicherheitsbedrohungen geworden. Die zunehmende Komplexität von Abhängigkeitsökosystemen und die Nutzung öffentlicher Paket-Repositories vergrößern die Angriffsfläche erheblich (BOYKIN; REARDON, 2022).

Aktuelle Initiativen wie das SLSA-Framework (Supply-chain Levels for Software Artifacts) und das Secure Software Development Framework (SSDF) des NIST zielen darauf ab, formale Praktiken für die Integrität von Builds und die Nachverfolgbarkeit von Artefakten zu etablieren (NIST, 2022; OPENSSF, 2023).

2.2 Schwachstellenmetriken

Das Common Vulnerability Scoring System (CVSS) ist der weit verbreitete Standard zur Quantifizierung der Schwere von Schwachstellen (FIRST, 2019). Studien zeigen jedoch, dass CVSS allein die tatsächliche Exploit-Wahrscheinlichkeit nicht angemessen abbildet.

Zur Minderung dieser Einschränkung wurde das Exploit Prediction Scoring System (EPSS) entwickelt, das probabilistisch die Wahrscheinlichkeit einer aktiven Ausnutzung einer Schwachstelle auf Grundlage historischer Daten und Threat Intelligence schätzt (JACOBS et al., 2021).

2.3 DevSecOps und Sicherheitsautomatisierung

Systematische Literaturübersichten zeigen, dass sich die Einführung von DevSecOps häufig auf die Integration von Werkzeugen für statische Analyse und Abhängigkeits-Scanner in CI/CD-Pipelines beschränkt (MYRBAKKEN; COLOMO‑PALACIOS, 2017). Obwohl solche Werkzeuge die Sichtbarkeit von Schwachstellen erhöhen, hängt ihre operative Wirksamkeit von risikobasierten Priorisierungs- und Governance-Mechanismen ab.

Eine weitere wiederkehrende Herausforderung ist die große Menge an Warnmeldungen, die von Sicherheitswerkzeugen erzeugt wird, was zu operationaler Ermüdung und unzureichender Priorisierung kritischer Schwachstellen führen kann (BEHL; BEHL, 2016).

2.4 Korrelation mit Bedrohungsmodellen

Die MITRE-ATT&CK-Matrix bietet eine strukturierte Taxonomie von Angreifertaktiken und -techniken, die in realen Vorfällen beobachtet wurden (STROM et al., 2018). Die Korrelation zwischen detektierten Schwachstellen und ATT&CK-Techniken ermöglicht es, Risiken im Hinblick auf adversariales Verhalten zu kontextualisieren und so die Priorisierung von Gegenmaßnahmen zu verbessern.

Bedrohungsmodell und Problemformalisierung

Wir modellieren die CI/CD-Pipeline als einen gerichteten azyklischen Graphen:

$$ G = (V,E) $$

wobei jeder Knoten $v \in V$ eine Phase der Pipeline repräsentiert (Build, Test, statische Analyse, Abhängigkeitsanalyse oder Deployment) und jede Kante $e \in E$ Ausführungsabhängigkeiten zwischen Phasen darstellt.

Wir betrachten eine Menge von während einer Pipeline-Ausführung erkannten Schwachstellen:

$$ Vuln = {v_1, v_2, …, v_n} $$

Jede Schwachstelle $v_i$ besitzt die folgenden Attribute:

CVSS-Score $s_i \in [0,10]$
Exploit-Wahrscheinlichkeit $p_i$ abgeleitet aus EPSS
Kritikalitätsgewicht des Assets $w_i$
Zeitfaktor $a_i$ proportional zum Alter der Schwachstelle.

Wir definieren das inkrementelle Risiko, das mit einer Schwachstelle verbunden ist, als:

$$ r_i = w_i \cdot s_i \cdot p_i \cdot a_i $$

Das Gesamtrisiko der Pipeline ist definiert als:

$$ R = \sum_{i=1}^{n} r_i $$

Unser Ziel ist es, $R$ unter der operativen Einschränkung der Pipeline-Ausführungszeit zu minimieren:

$$ T_{build} \leq T_{max} $$

Darüber hinaus definieren wir die grundlegende Sicherheitseigenschaft des Systems:

$$ R \leq \theta $$

wobei $\theta$ den maximal akzeptablen Risikoschwellenwert für die Förderung von Artefakten darstellt.

Vorgeschlagene Methodik

4.1 DevSecOps-Architektur

Unsere Architektur integriert mehrere Sicherheitsebenen in die CI/CD-Pipeline.

Kategorie	Werkzeug	Funktion
SAST	Semgrep, SonarQube	statische Codeanalyse
SCA	Syft, Grype, Trivy	Analyse von Abhängigkeiten und Containern
DAST	OWASP ZAP	dynamische Tests
IaC	Checkov	Analyse von Infrastructure as Code
Runtime	Falco	Erkennung von anomalem Verhalten
Network IDS	Suricata	Netzwerkintrusionserkennung

Die Erzeugung der SBOM (Software Bill of Materials) erfolgt mit Syft und ermöglicht die Nachverfolgbarkeit von Abhängigkeiten sowie die Korrelation mit öffentlichen Schwachstellendatenbanken.

4.2 Adaptiver Blockierungsalgorithmus

Wir führen einen Entscheidungsmechanismus auf Basis eines dynamischen Schwellenwerts ein:

Algorithm 1: AdaptiveRiskGate
Input: Vulnerabilities V, base threshold θ_base
Output: Decision (ALLOW | BLOCK)

1: R ← 0
2: for each vulnerability v in V do
3:     compute r_i
4:     R ← R + r_i
5: θ_dynamic ← θ_base  log(1 + |V|)
6: if R > θ_dynamic then
7:     return BLOCK
8: else
9:     return ALLOW

Die rechnerische Komplexität beträgt $O(n)$, wobei $n$ die Anzahl der erkannten Schwachstellen ist.

Die Verwendung eines logarithmischen Schwellenwerts ermöglicht es, die Risikotoleranz dynamisch an das Volumen der Befunde anzupassen und übermäßige Blockierungen bei Builds mit einer großen Anzahl geringfügiger Schwachstellen zu vermeiden.

Implementierung

Die Implementierung erfolgte mit GitLab CI, das Runner in einem Kubernetes-Cluster ausführt.

Beispiel für eine Konfiguration der statischen Analyse:

sast:
  image: returntocorp/semgrep
  script:
    - semgrep --config=p/ci .

Container-Analyse mit Trivy:

trivy image --severity HIGH,CRITICAL --format json -o results.json app:latest

SBOM-Erzeugung:

syft packages app:latest -o cyclonedx-json > sbom.json

Das Runtime-Monitoring erfolgt durch Falco unter Verwendung von Regeln, die auf Ereignissen des Linux-Kernels und von eBPF basieren.

Der durchschnittlich in die Pipeline eingeführte Overhead betrug etwa 8,4 %, ein Wert, der für Produktionsumgebungen mit hohen Sicherheitsanforderungen als akzeptabel gilt.

Experimentelle Evaluation

Das Experiment wurde in einer Kubernetes-Umgebung durchgeführt, die aus 12 Knoten mit jeweils 32 vCPU und 128 GB Speicher bestand.

Der experimentelle Datensatz umfasste:

1.200 Pipeline-Ausführungen
37 Microservices
OWASP-Benchmark-Anwendungen
interne Produktionsanwendungen.

Wichtigste Ergebnisse:

Metrik	Baseline	Vorgeschlagenes Modell
MTTR	14,2 Tage	8,3 Tage
Kritische Schwachstellen in der Produktion	112	42
Pipeline-Overhead	3%	8,4%

Die relative Reduktion der Exposition gegenüber kritischen Schwachstellen betrug etwa 62,7 %.

Fallstudie

Wir wendeten das Modell in einer Fintech-Organisation mit etwa vier Millionen aktiven Nutzern an.

Der Einführungsprozess erfolgte in vier Hauptschritten:

Integration von SAST- und SCA-Scannern in die Pipeline;
automatische Erzeugung einer SBOM für jeden Build;
Festlegung des anfänglichen Schwellenwerts $\theta_{base}=50$;
Korrelation von Schwachstellen mit MITRE-ATT&CK-Techniken.

Während neun Monaten Betrieb wurden 17 Releases mit ausnutzbaren kritischen Schwachstellen automatisch blockiert.

Im analysierten Zeitraum wurden keine Vorfälle im Zusammenhang mit kritischen CVEs verzeichnet.

Diskussion

Die Ergebnisse legen nahe, dass die Verwendung quantitativer Risikometriken im Vergleich zu statischen Schwellenwerten konsistentere Entscheidungen in CI/CD-Pipelines ermöglicht.

Der Hauptvorteil des vorgeschlagenen Ansatzes liegt in der Integration mehrerer Risikodimensionen — Schweregrad, Exploit-Wahrscheinlichkeit und operativer Kontext — zu einer einzigen aggregierten Metrik.

Allerdings bleiben einige Einschränkungen bestehen. Die Qualität der Schätzungen hängt direkt von der Genauigkeit öffentlicher Schwachstellendatenbanken und der Abdeckung statischer Analysewerkzeuge ab. Darüber hinaus stellen False Positives in hochautomatisierten DevSecOps-Umgebungen weiterhin eine relevante Herausforderung dar.

Eine weitere wichtige Beobachtung ist die Notwendigkeit der Integration zwischen Entwicklungs-Pipelines und Sicherheitsoperationen (SOC). Der Export von Risikometriken an SIEM- oder XDR-Plattformen kann die Korrelation mit Produktionsereignissen ermöglichen und die Incident-Response-Fähigkeit verbessern.

Schlussfolgerung

Diese Arbeit hat ein formales Modell für die Sicherheitsorchestrierung in CI/CD-Pipelines auf Basis quantitativer Risikometriken vorgestellt. Wir haben gezeigt, wie die Kombination von CVSS, EPSS, Asset-Kritikalität und Zeitfaktoren die Schätzung des inkrementellen Risikos ermöglicht, das mit während des Build-Prozesses identifizierten Schwachstellen verbunden ist.

Die experimentelle Implementierung zeigte, dass automatisierte Entscheidungen auf Grundlage dieses Modells die Exposition gegenüber kritischen Schwachstellen erheblich reduzieren können, ohne die operative Effizienz der Pipeline zu beeinträchtigen.

Die Ergebnisse unterstreichen die Bedeutung metrikgesteuerter Ansätze für die Sicherheitsgovernance in DevSecOps-Umgebungen, insbesondere angesichts des anhaltenden Wachstums von Angriffen auf die Software-Supply-Chain.

Literaturverzeichnis

BEHL, Abhishek; BEHL, Kiran. Cybersecurity and cyberwar: what everyone needs to know. Oxford: Oxford University Press, 2016. Available at: https://global.oup.com/academic/product/cybersecurity-and-cyberwar-9780199918096. Accessed on: 10 mar. 2024.

BOYKIN, Poornima; REARDON, Joel. A deep dive into software supply chain attacks. IEEE Security & Privacy, v. 20, n. 5, p. 70‑77, 2022. Available at: https://doi.org/10.1109/MSEC.2022.3186348. Accessed on: 12 mar. 2024.

CISA. Defending against software supply chain attacks. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2023. Available at: https://www.cisa.gov/resources-tools/resources/defending-against-software-supply-chain-attacks. Accessed on: 15 mar. 2024.

ENISA. ENISA threat landscape 2023. Atenas: European Union Agency for Cybersecurity, 2023. Available at: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023. Accessed on: 18 mar. 2024.

FIRST. Common vulnerability scoring system v3.1 specification document. 2019. Available at: https://www.first.org/cvss/v3.1/specification-document. Accessed on: 10 fev. 2024.

JACOBS, Jay et al. Exploit prediction scoring system (EPSS). FIRST Conference, 2021. Available at: https://www.first.org/epss. Accessed on: 14 fev. 2024.

KOHNS, Arthur; WILSON, Gary. Kubernetes security and observability. Sebastopol: O’Reilly Media, 2022. Available at: https://www.oreilly.com/library/view/kubernetes-security-and/9781098117337. Accessed on: 12 fev. 2024.

MYRBAKKEN, Håkon; COLOMO‑PALACIOS, Ricardo. DevSecOps: a multivocal literature review. In: INTERNATIONAL CONFERENCE ON SOFTWARE PROCESS IMPROVEMENT, 2017. Proceedings. Cham: Springer, 2017. Available at: https://doi.org/10.1007/978-3-319-69926-4_15. Accessed on: 20 fev. 2024.

NIST. Secure software development framework (SSDF) version 1.1. Gaithersburg: National Institute of Standards and Technology, 2022. Available at: https://doi.org/10.6028/NIST.SP.800-218. Accessed on: 18 fev. 2024.

NIST. National vulnerability database. 2023. Available at: https://nvd.nist.gov. Accessed on: 10 mar. 2024.

OPENSSF. Supply-chain levels for software artifacts (SLSA). 2023. Available at: https://slsa.dev. Accessed on: 15 mar. 2024.

OWASP. OWASP Top 10:2021. OWASP Foundation, 2021. Available at: https://owasp.org/Top10. Accessed on: 20 fev. 2024.

RED HAT. Falco runtime security. 2023. Available at: https://falco.org. Accessed on: 10 mar. 2024.

SEMGRP INC. Semgrep documentation. 2024. Available at: https://semgrep.dev/docs. Accessed on: 11 mar. 2024.

AQUA SECURITY. Trivy vulnerability scanner. 2024. Available at: https://trivy.dev. Accessed on: 11 mar. 2024.

ANCHORE. Syft and Grype documentation. 2024. Available at: https://anchore.com. Accessed on: 11 mar. 2024.

CHECKOV. Infrastructure as code security scanning. 2024. Available at: https://www.checkov.io. Accessed on: 11 mar. 2024.

ZED ATTACK PROXY PROJECT. OWASP ZAP documentation. 2024. Available at: https://www.zaproxy.org. Accessed on: 12 mar. 2024.

STROM, Blake et al. MITRE ATT&CK: design and philosophy. MITRE Corporation, 2018. Available at: https://attack.mitre.org/docs/MITRE_ATTACK_Design_and_Philosophy.pdf. Accessed on: 18 fev. 2024.

VERIZON. 2023 data breach investigations report. Verizon, 2023. Available at: https://www.verizon.com/business/resources/reports/dbir. Accessed on: 22 mar. 2024.

CNCF. Falco: cloud native runtime security. Cloud Native Computing Foundation, 2023. Available at: https://www.cncf.io/projects/falco. Accessed on: 15 mar. 2024.

CILIUM PROJECT. eBPF-based networking and observability. 2023. Available at: https://cilium.io. Accessed on: 16 mar. 2024.

SURICATA. Suricata intrusion detection system documentation. 2024. Available at: https://suricata.io. Accessed on: 12 mar. 2024.

SONAR. SonarQube documentation. 2024. Available at: https://docs.sonarsource.com. Accessed on: 12 mar. 2024.

CYCLONEDX. CycloneDX SBOM specification. 2023. Available at: https://cyclonedx.org. Accessed on: 15 mar. 2024.