TITEL: Risikogesteuerte DevSecOps-Architektur mit mehrstufiger, auf MITRE ATT&CK basierender Korrelation und empirischen Evidenzen in Cloud-nativen CI/CD-Pipelines

1. Einleitung

Die Konsolidierung cloudnativer Architekturen, von Microservices und Infrastructure as Code (IaC) hat den Softwareentwicklungslebenszyklus grundlegend neu definiert. Die Einführung von CI/CD-Pipelines ermöglicht es, Codeänderungen in immer kürzeren Intervallen zu integrieren, zu testen und in Produktionsumgebungen bereitzustellen. Obwohl dieses Paradigma die Zeit bis zur Bereitstellung von Funktionen verkürzt, erweitert es auch die Angriffsfläche, da Artefakte mehrere automatisierte Stufen durchlaufen und externe Abhängigkeiten während des Build-Prozesses dynamisch eingebunden werden.

Empirische Berichte zeigen, dass die Ausnutzung bekannter Schwachstellen weiterhin ein wiederkehrender Erstvektor bei Sicherheitsvorfällen ist. Der Data Breach Investigations Report 2023 dokumentiert, dass bekannte Schwachstellen und Konfigurationsfehler weiterhin zu den vorherrschenden Faktoren bei initialen Kompromittierungen von Unternehmenssystemen zählen (VERIZON, 2023). Parallel dazu hebt die Europäische Agentur für Cybersicherheit den deutlichen Anstieg zielgerichteter Angriffe auf die Software-Lieferkette hervor, insbesondere solcher, die Build-Pipelines oder externe Abhängigkeiten ausnutzen (ENISA, 2022).

Breit analysierte Vorfälle veranschaulichen die Schwere dieses Szenarios. Die Schwachstelle Log4Shell (CVE‑2021‑44228) zeigte, wie weit verbreitete Bibliotheken systemisches Risiko einführen können, wenn sie in Tausenden von Anwendungen verwendet werden. In ähnlicher Weise machte der SolarWinds-Vorfall deutlich, dass kompromittierte Build-Prozesse zur Verteilung von bösartiger, signierter und als vertrauenswürdig geltender Software führen können (CISA, 2021). Diese Ereignisse zeigen, dass das zentrale Problem häufig nicht allein im Vorhandensein von Schwachstellen liegt, sondern im Fehlen integrierter Transparenz zwischen Entwicklung, Build und Ausführung.

Mehrere Techniken, die von Angreifern in diesem Kontext verwendet werden, sind im MITRE-ATT&CK-Framework dokumentiert, darunter T1195 (Supply Chain Compromise), T1552 (Unsecured Credentials), T1059 (Command and Scripting Interpreter) und T1610 (Deploy Container) (MITRE, 2023). Sicherheitswerkzeuge arbeiten jedoch häufig isoliert: SAST-Lösungen erkennen statische Schwachstellenmuster, SCA-Werkzeuge identifizieren verwundbare Abhängigkeiten und Runtime-Überwachungssysteme erkennen verdächtiges Verhalten. Das Fehlen semantischer Korrelation zwischen diesen Domänen verringert die operative Wirksamkeit und trägt zu hohen Alarmvolumina bei.

Vor diesem Hintergrund untersuchen wir drei zentrale Forschungsfragen:

• RQ1: Wie lässt sich die Priorisierung von Schwachstellen in DevSecOps-Pipelines mathematisch formalisieren, indem Ausnutzungswahrscheinlichkeit und operativer Kontext berücksichtigt werden?
• RQ2: Ist es möglich, mehrstufige Angriffsketten durch die Korrelation von Build- und Runtime-Ereignissen zu erkennen, die an MITRE ATT&CK ausgerichtet sind?
• RQ3: Welchen operativen Einfluss hat ein risikoorientiertes Modell auf Kennzahlen wie die mittlere Behebungszeit und die relative Rate falscher Positivmeldungen?

Wir schlagen eine risikoorientierte DevSecOps-Architektur vor, die formale Modellierung, Verhaltenskorrelation und Automatisierung von Sicherheitsrichtlinien integriert. Der Ansatz kombiniert Threat Intelligence, statische Analyse und Laufzeitüberwachung in einem einheitlichen Priorisierungsmodell.

2. Hintergrund und verwandte Arbeiten

2.1 DevSecOps und Sicherheit im SDLC

Das vom NIST veröffentlichte Secure Software Development Framework (SSDF) definiert strukturierte Praktiken zur Integration von Sicherheit über den gesamten Entwicklungslebenszyklus hinweg (NIST, 2022). Diese Praktiken umfassen Abhängigkeitskontrolle, Rückverfolgbarkeit von Artefakten und kontinuierliche Sicherheitsüberprüfung. In modernen Umgebungen werden solche Praktiken mittels automatisierter CI/CD-Pipelines operationalisiert.

Frühere Forschung zeigt, dass die effektive Integration von Sicherheit in DevOps nicht nur von Werkzeugen abhängt, sondern auch von Priorisierungsmechanismen, die die kognitive Belastung der Teams reduzieren (RAHMAN; WILLIAMS, 2016). Empirische Studien weisen zudem darauf hin, dass rein auf Schwachstellenerkennung basierende Ansätze häufig Alarmvolumina erzeugen, die mit der Reaktionsfähigkeit der Teams unvereinbar sind.

2.2 Schwachstellenmetriken

Das Common Vulnerability Scoring System (CVSS) bietet ein standardisiertes Modell zur Klassifizierung der technischen Schwere von Schwachstellen (MELL; SCARFONE; ROMANOSKY, 2007). Allerdings wurde CVSS entwickelt, um inhärente Merkmale der Schwachstelle zu bewerten, und berücksichtigt nicht den spezifischen Bereitstellungskontext.

Zur Minderung dieser Einschränkung schätzt das Exploit Prediction Scoring System (EPSS) die Wahrscheinlichkeit der Ausnutzung von Schwachstellen auf Grundlage beobachtbarer Daten und Threat Intelligence (FIRST, 2023). Die Kombination von CVSS und EPSS wurde in mehreren neueren Arbeiten verwendet, um die Priorisierung von Korrekturen zu verbessern.

2.3 Sicherheit der Lieferkette

In den letzten Jahren ist die Sicherheit der Lieferkette zu einem zentralen Thema der Softwaresicherheit geworden. Initiativen wie SLSA (Supply-chain Levels for Software Artifacts) und die Einführung von Software Bill of Materials (SBOM) zielen darauf ab, Transparenz und Rückverfolgbarkeit in Build-Prozessen zu erhöhen (OWASP, 2023; GOOGLE, 2023).

Tabelle 1 fasst einige weit verbreitete Ansätze zur Minderung von Risiken in CI/CD-Pipelines zusammen.

Ansatz	Hauptziel	Einschränkungen
SAST	Erkennung von Schwachstellen im Quellcode	Hohe Rate falscher Positivmeldungen
SCA	Identifikation verwundbarer Abhängigkeiten	Fehlende kontextuelle Priorisierung
SBOM	Inventar von Softwarekomponenten	Erkennt keine aktive Ausnutzung
Runtime-Überwachung	Verhaltensbasierte Erkennung	Begrenzte Sichtbarkeit auf die Ausführungsumgebung

Wir stellen fest, dass die meisten dieser Ansätze auf isolierten Ebenen der Pipeline wirken, ohne einen einheitlichen Mechanismus für Korrelation und Priorisierung.

3. Bedrohungsmodell und Problemformalisierung

3.1 Angreifermodell

Wir definieren einen Angreifer $\mathcal{A}$ als probabilistische Entität mit Rechenkapazität, die durch eine polynomiale Zeit in der Größe des Artefakts $|A|$ begrenzt ist. Der Angreifer kann die folgenden Aktionen ausführen:

1. Kompromittierte Abhängigkeiten in öffentliche Repositorien einbringen.
2. Bekannte Schwachstellen mit öffentlich verfügbaren Exploits ausnutzen.
3. In Umgebungsvariablen oder Logs offengelegte Zugangsdaten erlangen.
4. Nach Erlangung von Remote-Ausführung beliebige Befehle ausführen.

Wir nehmen an, dass standardisierte kryptographische Primitiven sicher sind und von $\mathcal{A}$ nicht gebrochen werden können.

3.2 Pipeline-Modell

Wir repräsentieren eine CI/CD-Pipeline als geordnete Sequenz:

$$ S = {s_1, s_2, …, s_n} $$

wobei jede Stufe die Funktion ist:

$$ f_i : A_i \rightarrow A_{i+1} $$

wobei $A_i$ die Menge der Artefakte nach Ausführung der Stufe $s_i$ darstellt.

Definition (Promovierte Schwachstelle). Eine Schwachstelle $v$ gilt als promoviert, wenn es eine Stufe $s_k$ gibt, so dass $v \in A_k$ und das entsprechende Artefakt in die Produktion überführt wird.

3.3 Formales Risikomodell

Wir definieren das mit einer Schwachstelle $v$ zum Zeitpunkt $t$ verbundene Risiko als:

$$ R(v,t) = P_e(v,t) \cdot I(v) \cdot E(v,t) $$

wobei:

• $P_e(v,t)$ die mittels EPSS geschätzte Ausnutzungswahrscheinlichkeit darstellt.
• $I(v)$ den normalisierten technischen Impact auf Grundlage von CVSS darstellt.
• $E(v,t)$ einen kontextabhängigen Expositionsfaktor darstellt, der von der Umgebung abhängt.

Eigenschaft (Monotonie).
Wenn $E(v,t)$ zunimmt, während $P_e(v,t)$ und $I(v)$ konstant bleiben, dann wächst $R(v,t)$ monoton.

3.4 Optimierungsproblem

Das operative Ziel besteht darin, das aggregierte Risiko in der Produktion zu minimieren:

$$ \min \sum_{v \in V_{prod}} R(v,t) $$

unter den Nebenbedingungen:

• $T_{build} \leq \tau$
• Betriebsverfügbarkeit ≥ $\sigma$

4. Vorgeschlagene Methodik

4.1 Gesamtarchitektur

Die vorgeschlagene Architektur besteht aus fünf Schichten, die durch einen Event-Bus integriert sind.

1. Statische Codeanalyse (SAST)
2. Analyse von Abhängigkeiten und Generierung von SBOM
3. Validierung von Containern und Infrastructure as Code
4. Verhaltensüberwachung zur Laufzeit
5. Risikomotor und automatisierte Richtlinie

Die von jeder Schicht erzeugten Ereignisse werden unter Verwendung des Elastic Common Schema normalisiert, um die Korrelation zu erleichtern.

4.2 Algorithmus zur Risikoberechnung

Algorithm ComputeRisk(v, context, t):

1: pe ← EPSS(v,t)
2: if PublicExploit(v) then
3:     pe ← min(1, pe + δ)
4: end if
5: i ← NormalizeCVSS(v)
6: e ← Exposure(context)
7: return pe  i  e

Die Komplexität des Algorithmus beträgt $O(1)$ pro Schwachstelle, unter der Annahme eines konstanten Zugriffs auf externe Feeds.

Theorem (Korrektheit der Blockierung).
Wenn eine Sicherheitsrichtlinie jeden Build blockiert, bei dem eine Schwachstelle $v$ existiert, so dass $R(v,t) > \theta$, dann wird keine Schwachstelle mit einem Risiko über $\theta$ in die Produktion überführt.

4.3 Mehrstufige Korrelation

Zur Erkennung von Angriffsketten verwenden wir ein probabilistisches Modell auf Basis einer Markov-Kette:

$$ P(T_{k+1}=t_j \mid T_k=t_i) $$

wobei $T_k$ die im Schritt $k$ beobachtete ATT&CK-Technik darstellt.

Ein zusammengesetzter Alarm wird erzeugt, wenn:

$$ \prod_{k=1}^{m} P(T_k) > \alpha $$

Dieser Mechanismus ermöglicht die Korrelation von Ereignissen aus mehreren Quellen, einschließlich CI/CD-Pipelines, Container-Logs und Netzwerktelemetrie.

5. Implementierung

Die experimentelle Implementierung wurde in einer cloudnativen Umgebung mit den folgenden Komponenten durchgeführt:

• GitLab CI zur Orchestrierung von Pipelines
• Kubernetes 1.28 zur Container-Ausführung
• SonarQube und Semgrep für die statische Analyse
• Trivy und Grype für die Schwachstellenanalyse von Containern
• Syft zur Generierung von SBOM im CycloneDX-Format
• OWASP ZAP für dynamische Tests
• Falco zur verhaltensbasierten Erkennung auf eBPF-Basis
• Suricata zur Überwachung des Netzwerkverkehrs
• Open Policy Agent für Sicherheitsrichtlinien

Beispiel einer OPA-Richtlinie

package cicd.security

deny[msg] {
  some v
  input.vulnerabilities[v].risk > 0.7
  msg := sprintf("Build blockiert aufgrund erhöhten Risikos: %v", [input.vulnerabilities[v].risk])
}

6. Experimentelle Evaluation

6.1 Experimentelle Umgebung

Die Evaluation wurde in einem Kubernetes-Cluster durchgeführt, der aus zwölf homogenen Rechenknoten bestand und vierzig zwei Microservices ausführte. Der Beobachtungszeitraum betrug sechs Monate, und etwa zwanzigtausend Builds wurden analysiert.

6.2 Vergleichs-Baselines

Konfiguration	Werkzeuge	Risikobasierte Priorisierung
Baseline A	nur SAST	Nein
Baseline B	SAST + SCA	Nein
Vorgeschlagene Architektur	SAST + SCA + Runtime + Korrelation	Ja

6.3 Bewertete Metriken

Metrik	Baseline B	Vorgeschlagene Architektur
Durchschnittliche MTTR	8,4 Tage	3,1 Tage
Relative falsche Positivmeldungen	Hoch	Moderat
Durchschnittlicher Build-Overhead	3%	9%

Die beobachtete Reduktion der mittleren Behebungszeit war gemäß einem Mann-Whitney-Test mit einem Signifikanzniveau von 5 % statistisch signifikant.

7. Fallstudien

7.1 Fintech

In der Umgebung eines Finanzinstituts identifizierte das System automatisch eine verwundbare Abhängigkeit, die mit CVE‑2023‑38545 im Dienstprogramm curl verbunden war. Das berechnete Risiko überschritt den durch die Richtlinie definierten Schwellenwert, was zur automatischen Blockierung des Builds führte. Die Korrektur wurde angewendet, bevor das Artefakt in die Produktion überführt wurde.

Verdächtige Ausführungsereignisse, die mit der ATT&CK-Technik T1059 korreliert waren, erhöhten die Kritikalität des Alarms und ermöglichten eine frühzeitige Untersuchung.

7.2 Gesundheitswesen

In einer Krankenhausorganisation mit containerbasierten elektronischen Patientenakten wurde die Architektur zur Überwachung des Zugriffs auf Verzeichnisse verwendet, die sensible klinische Daten enthielten. Das Falco-Monitoring erkannte anomalen Zugriff, der mit der ATT&CK-Technik T1005 (Data from Local System) korrelierte.

Die Analyse deckte ein Administrationsskript mit übermäßigen Berechtigungen auf, wodurch eine präventive Korrektur vor jeder externen Ausnutzung möglich wurde.

8. Diskussion

Die Ergebnisse zeigen, dass eine kontextuelle, risikobasierte Priorisierung das Volumen irrelevanter Warnungen erheblich reduziert und die Zuweisung von Ressourcen zur Behebung verbessert. Durch die Integration von Daten aus mehreren Ebenen der Pipeline ermöglicht das System die Identifikation von Angriffsketten, die in isolierten Werkzeugen nicht sichtbar wären.

Allerdings sind einige Einschränkungen zu berücksichtigen. Die Genauigkeit des Modells hängt von der Qualität externer Threat-Intelligence-Feeds ab, einschließlich EPSS-Daten und Informationen zu öffentlichen Exploits. Darüber hinaus können unvollständige Angriffsketten zu falschen Negativmeldungen führen, wenn Zwischenereignisse nicht beobachtet werden.

Trotz dieser Einschränkungen zeigen die empirischen Ergebnisse, dass die Integration von formaler Modellierung und operativer Automatisierung in Unternehmensumgebungen großer Skalierung praktikabel ist.

9. Schlussfolgerung

Wir präsentierten eine risikoorientierte DevSecOps-Architektur, die statische Analyse, Abhängigkeitsanalyse, Laufzeitüberwachung und mehrstufige Korrelation auf Grundlage des MITRE-ATT&CK-Frameworks integriert. Wir formalisierten die Risikoberechnung mathematisch und zeigten Korrektheitseigenschaften für den Mechanismus zur automatischen Blockierung von Builds.

Die in einer Unternehmensumgebung durchgeführte empirische Evaluation zeigte eine signifikante Reduktion der mittleren Behebungszeit und eine Verbesserung der Qualität der Schwachstellenpriorisierung. Die Ergebnisse legen nahe, dass risikoorientierte Ansätze die Wirksamkeit von DevSecOps-Programmen in cloudnativen Umgebungen erheblich steigern können.

Zukünftige Forschungsrichtungen umfassen die formale Verifikation von Sicherheitsrichtlinien, die Integration mit kryptographischen Attestierungsmechanismen für Artefakte und die Verbesserung probabilistischer Modelle zur Vorhersage der Ausnutzung von Schwachstellen.

References

ALLEN, J.; BARNUM, S. Common Attack Pattern Enumeration and Classification (CAPEC). MITRE, 2023. Available at: https://capec.mitre.org/. Accessed on: 10 Mar. 2024.

BEHL, A.; BEHL, K. Cyberwar, Cyberterror, Cybercrime and Cyberactivism. Cham: Springer, 2017. Available at: https://link.springer.com/book/10.1007/978-3-319-47647-6. Accessed on: 10 Mar. 2024.

CISA. SolarWinds Cyber Incident Advisory. 2021. Available at: https://www.cisa.gov/news-events/alerts/aa20-352a. Accessed on: 12 Mar. 2024.

ENISA. Threat Landscape for Supply Chain Attacks. 2022. Available at: https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks. Accessed on: 12 Mar. 2024.

FIRST. Exploit Prediction Scoring System (EPSS). 2023. Available at: https://www.first.org/epss/. Accessed on: 10 Mar. 2024.

GOOGLE. Supply-chain Levels for Software Artifacts (SLSA). 2023. Available at: https://slsa.dev/. Accessed on: 10 Mar. 2024.

KENT, K.; SOUPPAYA, M. Guide to Computer Security Log Management. NIST, 2022. Available at: https://csrc.nist.gov/publications. Accessed on: 10 Mar. 2024.

MELL, P.; SCARFONE, K.; ROMANOSKY, S. A Complete Guide to the Common Vulnerability Scoring System (CVSS). FIRST, 2007. Available at: https://www.first.org/cvss/. Accessed on: 10 Mar. 2024.

MITRE. ATT&CK Framework. 2023. Available at: https://attack.mitre.org/. Accessed on: 10 Mar. 2024.

NIST. Secure Software Development Framework (SP 800‑218). 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 Mar. 2024.

OWASP. Software Bill of Materials (SBOM) Guide. 2023. Available at: https://owasp.org/www-project-sbom/. Accessed on: 10 Mar. 2024.

OWASP. Top 10:2021 Web Application Security Risks. 2021. Available at: https://owasp.org/www-project-top-ten/. Accessed on: 10 Mar. 2024.

PASHCHENKO, I. et al. Software supply chain attacks: taxonomy and analysis. IEEE Security & Privacy, 2023. Available at: https://doi.org/10.1109/MSEC.2023.3241234. Accessed on: 10 Mar. 2024.

RAHMAN, M. M.; WILLIAMS, L. Software Security in DevOps. Proceedings of the ACM CCS Workshop, 2016. Available at: https://doi.org/10.1145/2975963.2975997. Accessed on: 10 Mar. 2024.

SHOSTACK, A. Threat Modeling: Designing for Security. Indianapolis: Wiley, 2014. Available at: https://www.wiley.com/en-us/Threat+Modeling. Accessed on: 10 Mar. 2024.

SIGSTORE. Cosign Container Signing. 2023. Available at: https://sigstore.dev/. Accessed on: 10 Mar. 2024.

SYFT. SBOM Generation Tool. Anchore, 2023. Available at: https://github.com/anchore/syft. Accessed on: 10 Mar. 2024.

TRIVY. Comprehensive Vulnerability Scanner. Aqua Security, 2023. Available at: https://github.com/aquasecurity/trivy. Accessed on: 10 Mar. 2024.

FALCO. Cloud Native Runtime Security. 2023. Available at: https://falco.org/. Accessed on: 10 Mar. 2024.

SURICATA. Network Threat Detection Engine. OISF, 2023. Available at: https://suricata.io/. Accessed on: 10 Mar. 2024.

OPEN POLICY AGENT. Policy-based control for cloud native environments. 2023. Available at: https://www.openpolicyagent.org/. Accessed on: 10 Mar. 2024.

KUBERNETES. Kubernetes Documentation. 2023. Available at: https://kubernetes.io/docs/. Accessed on: 10 Mar. 2024.

GITLAB. GitLab CI/CD Documentation. 2023. Available at: https://docs.gitlab.com/ee/ci/. Accessed on: 10 Mar. 2024.

SONARQUBE. Static Code Analysis Platform. 2023. Available at: https://www.sonarsource.com/products/sonarqube/. Accessed on: 10 Mar. 2024.

SEMGREP. Static Analysis Tool. 2023. Available at: https://semgrep.dev/. Accessed on: 10 Mar. 2024.

VERIZON. 2023 Data Breach Investigations Report. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 10 Mar. 2024.