Risikogetriebene DevSecOps-Architektur mit mehrstufiger Korrelation auf Grundlage von MITRE ATT&CK und empirischen Evidenzen in cloudnativen CI/CD-Pipelines

1. Einführung

Die Konsolidierung cloudnativer Architekturen, von Microservices und Infrastructure as Code (Infrastructure as Code – IaC) hat den Softwareentwicklungslebenszyklus tiefgreifend 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 der Produktion 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 deuten darauf hin, dass die Ausnutzung bekannter Schwachstellen weiterhin ein wiederkehrender Erstvektor bei Sicherheitsvorfällen ist. Der Data Breach Investigations Report von 2023 dokumentiert, dass bekannte Schwachstellen und Fehlkonfigurationen unter den dominierenden Faktoren bei initialen Kompromittierungen unternehmensweiter Systeme verbleiben (VERIZON, 2023). Parallel dazu hebt die Europäische Agentur für Cybersicherheit den deutlichen Anstieg von Angriffen 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 Log4Shell-Schwachstelle (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 vertrauenswürdiger Software führen können (CISA, 2021). Diese Ereignisse zeigen, dass das Kernproblem häufig nicht allein in der Existenz von Schwachstellen liegt, sondern im Mangel an integrierter Sichtbarkeit zwischen Entwicklung, Build und Laufzeit.

Mehrere in diesem Kontext von Angreifern genutzte Techniken 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-Monitoring-Systeme entdecken verdächtiges Verhalten. Das Fehlen semantischer Korrelation zwischen diesen Domänen verringert die operative Wirksamkeit und trägt zu hohen Alarmmengen bei.

Vor diesem Hintergrund untersuchen wir drei zentrale Forschungsfragen:

• RQ1: Wie lassen sich Schwachstellen in DevSecOps-Pipelines mathematisch priorisieren, indem Exploit-Wahrscheinlichkeit und operativer Kontext einbezogen werden?
• RQ2: Ist es möglich, mehrstufige Angriffsketten durch die Korrelation von Build- und Runtime-Ereignissen zu erkennen, die mit MITRE ATT&CK ausgerichtet sind?
• RQ3: Welchen operativen Einfluss hat ein risikogesteuertes Modell auf Metriken wie die mittlere Zeit bis zur Behebung 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 (NIST, 2022). Diese Praktiken umfassen Abhängigkeitskontrolle, Rückverfolgbarkeit von Artefakten und kontinuierliche Sicherheitsverifikation. In modernen Umgebungen werden solche Praktiken durch automatisierte CI/CD-Pipelines operationalisiert.

Frühere Forschungsarbeiten zeigen, dass eine wirksame Integration von Sicherheit in DevOps nicht nur von Werkzeugen abhängt, sondern auch von Priorisierungsmechanismen, die die kognitive Belastung der Teams verringern (RAHMAN; WILLIAMS, 2016). Empirische Studien deuten 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 konzipiert, um intrinsische Merkmale der Schwachstelle zu bewerten, und berücksichtigt nicht den spezifischen Bereitstellungskontext.

Um diese Einschränkung zu mildern, schätzt das Exploit Prediction Scoring System (EPSS) die Wahrscheinlichkeit der Ausnutzung von Schwachstellen auf der Grundlage beobachtbarer Daten und Threat Intelligence (FIRST, 2023). Die Kombination aus CVSS und EPSS wird in mehreren neueren Arbeiten verwendet, um die Priorisierung von Patches 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) sollen Transparenz und Rückverfolgbarkeit in Build-Prozessen erhöhen (OWASP, 2023; GOOGLE, 2023).

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

Ansatz	Hauptziel	Einschränkungen
SAST	Erkennung von Schwachstellen im Quellcode	Hohe Rate falscher Positivmeldungen
SCA	Identifizierung verwundbarer Abhängigkeiten	Fehlende kontextuelle Priorisierung
SBOM	Inventar der Softwarekomponenten	Erkennt keine aktive Ausnutzung
Runtime-Monitoring	Verhaltensbasierte Erkennung	Eingeschränkte Sichtbarkeit auf die Laufzeitumgebung

Wir beobachten, dass die meisten dieser Ansätze auf isolierten Ebenen der Pipeline wirken, ohne einen einheitlichen Mechanismus zur Korrelation und Priorisierung.

3. Bedrohungsmodell und Problemformalisierung

3.1 Angreifermodell

Wir definieren einen Angreifer $\mathcal{A}$ als probabilistische Entität mit Rechenkapazität, die in polynomieller 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 Protokollen offengelegte Zugangsdaten erlangen.
4. Nach Erlangung von Remote Execution beliebige Befehle ausführen.

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

3.2 Pipeline-Modell

Wir stellen eine CI/CD-Pipeline als geordnete Folge dar:

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

wobei jede Stufe eine Funktion ist:

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

wobei $A_i$ die Menge der Artefakte nach Ausführung der Stufe $s_i$ repräsentiert.

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 der Produktion bereitgestellt 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 darstellt, abgeleitet aus CVSS.
• $E(v,t)$ den kontextuellen 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$
• Operative Verfügbarkeit ≥ $\sigma$

4. Vorgeschlagene Methodik

4.1 Gesamtarchitektur

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

1. Statische Codeanalyse (SAST)
2. Abhängigkeitsanalyse und SBOM-Erzeugung
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, vorausgesetzt, der konstante Zugriff auf externe Feeds ist gegeben.

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

4.3 Mehrstufige Korrelation

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

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

wobei $T_k$ eine beobachtete ATT&CK-Technik in Stufe $k$ darstellt.

Ein zusammengesetzter Alarm wird ausgelöst, wenn:

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

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

5. Implementierung

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

• GitLab CI zur Pipeline-Orchestrierung
• Kubernetes 1.28 für die Container-Ausführung
• SonarQube und Semgrep für die statische Analyse
• Trivy und Grype zur Schwachstellenanalyse von Containern
• Syft zur SBOM-Erzeugung 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 Bewertung wurde in einem Kubernetes-Cluster durchgeführt, bestehend aus zwölf homogenen Rechenknoten mit vierzig zwei Microservices. Der Beobachtungszeitraum betrug sechs Monate, und ungefähr 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 durchschnittlichen Behebungszeit war gemäß 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 Behebung wurde vor der Übernahme des Artefakts in die Produktion vorgenommen.

Mit der ATT&CK-Technik T1059 korrelierte verdächtige Ausführungsereignisse erhöhten die Kritikalität des Alarms und ermöglichten eine frühzeitige Untersuchung.

7.2 Gesundheitswesen

In einer Krankenhausorganisation mit containerbasierten Anwendungen für elektronische Patientenakten wurde die Architektur zur Überwachung des Zugriffs auf Verzeichnisse mit sensiblen klinischen Daten eingesetzt. Das Falco-Monitoring erkannte einen anomalen Zugriff, der mit der ATT&CK-Technik T1005 (Data from Local System) korrelierte.

Die Analyse offenbarte ein Administrationsskript mit übermäßigen Privilegien, 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 Alarme erheblich reduziert und die Zuweisung von Remediationsressourcen verbessert. Durch die Integration von Daten aus mehreren Pipeline-Schichten kann das System Angriffsketten identifizieren, die in isolierten Werkzeugen nicht sichtbar wären.

Dennoch müssen einige Einschränkungen berücksichtigt werden. Die Genauigkeit des Modells hängt von der Qualität externer Threat-Intelligence-Feeds ab, einschließlich EPSS-Daten und Informationen über öffentliche Exploits. Darüber hinaus können unvollständige Angriffsketten zu False Negatives 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 großskaligen Unternehmensumgebungen realisierbar ist.

9. Schlussfolgerung

Wir haben eine risikoorientierte DevSecOps-Architektur vorgestellt, die statische Analyse, Abhängigkeitsanalyse, Laufzeitüberwachung und mehrstufige Korrelation auf Basis des MITRE-ATT&CK-Frameworks integriert. Wir haben die Risikoberechnung mathematisch formalisiert und Korrektheitseigenschaften für den Mechanismus zur automatisierten Blockierung von Builds demonstriert.

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 sowie die Verbesserung probabilistischer Modelle zur Vorhersage der Ausnutzung von Schwachstellen.

Referenzen

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.