TITEL: Threat-orientiertes DevSecOps: Formale Architektur zur Integration von SAST, DAST, SCA und MITRE-ATT&CK-basierter Verhaltenstelemetrie in CI/CD-Pipelines

1. Einleitung

Die in der letzten Dekade intensivierte digitale Transformation hat Organisationen dazu veranlasst, verteilte Architekturen, Microservices sowie Praktiken der kontinuierlichen Integration und kontinuierlichen Bereitstellung zu übernehmen. In modernen Entwicklungsumgebungen automatisieren CI/CD-Pipelines Build-, Test- und Bereitstellungsprozesse und ermöglichen dadurch deutlich kürzere Lieferzyklen (KIM et al., 2016). Obwohl diese Automatisierung die Produktivität und die operative Zuverlässigkeit erhöht, vergrößert sie auch die Angriffsfläche, wenn Sicherheitskontrollen nicht nativ in die Pipeline integriert werden.

Weit dokumentierte Sicherheitsvorfälle zeigen die Risiken auf, die mit dem Fehlen integrierter Sicherheit im Entwicklungszyklus verbunden sind. Die Schwachstelle CVE‑2021‑44228, bekannt als Log4Shell, ermöglichte Remote Code Execution in weit verbreiteten Java-Anwendungen und betraf Software-Lieferketten in globalem Ausmaß (NIST, 2021). In ähnlicher Weise demonstrierte die Kompromittierung der SolarWinds-Lieferkette, dass Angreifer bösartigen Code direkt in den Build- und Distributionsprozess von Software einschleusen können (CISA, 2021).

Zeitgenössische Angriffe folgen häufig Verhaltensmustern, die in Wissensdatenbanken wie MITRE ATT&CK systematisiert sind und Techniken beschreiben, die von Angreifern in unterschiedlichen Phasen einer Intration eingesetzt werden (MITRE, 2023). Techniken wie T1195 (Supply Chain Compromise), T1190 (Exploit Public‑Facing Application) und T1059 (Command and Scripting Interpreter) treten wiederholt in realen Vorfällen auf. Traditionelle DevSecOps-Pipelines korrelieren jedoch nur selten während der Entwicklung erkannte Schwachstellen mit im Runtime-Betrieb beobachteten Verhaltensindikatoren.

Vor diesem Hintergrund formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das mit in CI/CD-Pipelines erkannten Schwachstellen verbundene Residualrisiko mathematisch formalisieren?

RQ2: Wie lassen sich Ergebnisse statischer und dynamischer Analysewerkzeuge mit im Runtime-Betrieb beobachteten Verhaltensnachweisen integrieren?

RQ3: Welchen quantitativen Einfluss hat diese Integration auf operative Sicherheitsmetriken wie Erkennungs- und Behebungszeit?

Die Beiträge dieser Arbeit sind drei. Erstens schlagen wir ein formales Modell zur Berechnung des Residualrisikos in CI/CD-Pipelines vor. Zweitens präsentieren wir einen adaptiven Priorisierungsalgorithmus, der Schweregrad von Schwachstellen, operativen Kontext und Verhaltensnachweise integriert. Drittens evaluieren wir die Architektur empirisch in einer realen Unternehmensumgebung und zeigen messbare Reduktionen operativer Risikometriken.

2. Hintergrund und verwandte Arbeiten

DevSecOps stellt die Weiterentwicklung des DevOps-Paradigmas durch die systematische Integration von Sicherheitskontrollen über den gesamten Software-Lebenszyklus hinweg dar (MYRBATEN; COLPAERT; PRETSCHNER, 2020). In diesem Modell werden Sicherheitstests kontinuierlich in verschiedenen Phasen der Entwicklungspipeline ausgeführt.

Formal repräsentieren wir eine CI/CD-Pipeline als geordnete Menge von Stufen:

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

wobei jede Stufe $s_i$ eine Transformationsfunktion $f_i$ auf Software-Artefakten $a_j$ ausführt.

Werkzeuge für statische Codeanalyse (SAST) wie SonarQube und Semgrep identifizieren syntaktische Muster, die mit Schwachstellen assoziiert sind. Werkzeuge für dynamische Analyse (DAST) wie OWASP ZAP bewerten laufende Anwendungen durch Simulation externer Interaktionen. Werkzeuge zur Software-Kompositionsanalyse (SCA) wie Trivy oder OWASP Dependency‑Check identifizieren Schwachstellen in Drittanbieter-Abhängigkeiten (OWASP, 2021).

Trotz der breiten Einführung dieser Werkzeuge zeigen empirische Studien erhebliche Herausforderungen im Zusammenhang mit False Positives und unzureichender Priorisierung von Schwachstellen (RAHMAN et al., 2019). In vielen Fällen basiert die Priorisierung ausschließlich auf dem CVSS-Score, der den technischen Schweregrad misst, jedoch nicht notwendigerweise das kontextuelle Risiko der Anwendung widerspiegelt (FIRST, 2019).

Das mit einer Menge von Schwachstellen verbundene Risiko kann modelliert werden als:

$$ R = \sum_{v \in V} P(v) \cdot I(v) $$

wobei $V$ die Menge der identifizierten Schwachstellen, $P(v)$ die Exploit-Wahrscheinlichkeit und $I(v)$ den potenziellen Impact darstellt.

Traditionelle Modelle berücksichtigen jedoch selten operative Telemetrie, Hinweise auf aktive Ausnutzung oder den Bereitstellungskontext. Unser Vorschlag integriert diese Faktoren durch die Korrelation zwischen Sicherheitsscannern und verhaltensbasierter Überwachung auf Basis von ATT&CK.

3. Bedrohungsmodell und Problemformalisierung

Wir betrachten einen Angreifer $A$ mit den folgenden Fähigkeiten:

• Ausnutzung bekannter Schwachstellen, die in CVE-Datenbanken veröffentlicht wurden
• Einschleusen bösartigen Codes in Software-Abhängigkeiten (Supply-Chain-Angriff)
• Remote-Ausführung von Befehlen nach initialer Kompromittierung

Der Angreifer hat externen Zugriff auf die Anwendung und kann automatisierte Scans mit allgemein verfügbaren Werkzeugen wie Nmap oder Masscan durchführen.

Zur Erfassung des kontextuellen Risikos definieren wir zwei zusätzliche Parameter:

• $E(v)$: beobachtbare Exploit-Hinweise in Bezug auf die Schwachstelle
• $C(v)$: kontextuelle Kritikalität auf Basis operativer Faktoren

Damit definieren wir eine angepasste Exploit-Wahrscheinlichkeit:

$$ P’(v) = \alpha \cdot S(v) + \beta \cdot E(v) + \gamma \cdot C(v) $$

wobei:

• $S(v)$ den aus CVSS abgeleiteten technischen Schweregrad darstellt
• $\alpha + \beta + \gamma = 1$

Das Residualrisiko des Systems wird dann definiert als:

$$ R’ = \sum_{v \in V} P’(v) \cdot I(v) $$

Unser Ziel ist es, $R’$ unter operativen Beschränkungen der Reaktionszeit $T$ und der verfügbaren Ressourcen $K$ zu minimieren.

4. Vorgeschlagene Methodik

Wir schlagen eine bedrohungsorientierte DevSecOps-Architektur vor, die aus mehreren in die CI/CD-Pipeline integrierten Stufen besteht.

Stufe	Funktion	Werkzeuge
SAST	statische Codeanalyse	Semgrep, SonarQube
SCA	Analyse von Abhängigkeiten	Trivy
IaC	Analyse von Infrastructure as Code	Checkov
DAST	dynamische Tests	OWASP ZAP
Runtime	Verhaltensdetektion	Falco, Suricata
Korrelation	ATT&CK-Mapping	analytische Engine

Die Priorisierung von Schwachstellen erfolgt durch einen adaptiven Algorithmus, der Schweregrad, Kontext und Verhaltensnachweise integriert.

Priorisierungsalgorithmus:

Input: Menge von Schwachstellen V
Output: priorisierte Liste L

for each v in V:
    severity = getCVSS(v)
    exploitEvidence = queryTelemetry(v)
    context = computeContext(v)

    P_prime = alphaseverity + betaexploitEvidence + gammacontext
    risk[v] = P_prime  impact(v)

return sortDescending(risk)

Die rechnerische Komplexität beträgt aufgrund des Sortierschritts $O(n \log n)$.

5. Implementierung

Die Architektur wurde unter Verwendung weit verbreiteter Technologien in cloud-nativen Umgebungen implementiert.

Komponente	Technologie
CI/CD-Orchestrierung	GitLab CI
Container	Docker
Orchestrierung	Kubernetes
SAST	SonarQube, Semgrep
SCA	Trivy
IaC-Scanning	Checkov
DAST	OWASP ZAP
Observability	Elastic Stack
Verhaltensdetektion	Falco, Suricata

Beispiel eines CI-Jobs zur Ausführung einer SAST-Analyse:

sast:
  image: returntocorp/semgrep
  script:
    - semgrep --config=auto --json > report.json
  artifacts:
    paths:
      - report.json

Beispiel einer Falco-Regel zur Erkennung der Ausführung einer Shell in einem Container:

- rule: Shell in Container
  desc: Detects shell execution in a container
  condition: container.id != host and proc.name = bash
  output: "Shell detected (user=%user.name container=%container.id)"

Die experimentelle Umgebung wurde in einem Kubernetes-Cluster mit 12 Knoten ausgeführt, insgesamt 96 vCPUs und 384 GB Speicher.

6. Experimentelle Bewertung

Die Bewertung wurde über sechs Monate in einer Unternehmensumgebung mit mehreren Microservices durchgeführt.

Parameter	Wert
Analysierte Pipelines	120
Microservices	48
Codezeilen	3,2 Millionen
Zeitraum	6 Monate

Vergleich zwischen traditionellem Ansatz und vorgeschlagener Architektur:

Metrik	Baseline	Vorgeschlagen
MTTD	72 h	26 h
MTTR	9,8 Tage	5,8 Tage
Kritische Schwachstellen in Produktion	21	9
Rate von False Positives	22%	13,6%

Wir beobachteten eine Reduktion der mittleren Erkennungszeit um 64 % sowie eine Reduktion der mittleren Behebungszeit um 41 %.

7. Fallstudie

Wir führten eine Fallstudie in einer Organisation des Finanzsektors mit etwa zwei Millionen aktiven Nutzern durch.

Während des Build-Prozesses identifizierte das Werkzeug Trivy das Vorhandensein der Schwachstelle CVE‑2021‑44228 in einer Log4j-Abhängigkeit.

Die Ereignisfolge war wie folgt:

1. Trivy identifizierte die verwundbare Abhängigkeit in der SCA-Phase.
2. Suricata erkannte verdächtigen Traffic im Zusammenhang mit einem LDAP-Exploit-Versuch.
3. Der Korrelationsmechanismus ordnete das Ereignis der ATT&CK-Technik T1190 zu.
4. Der Priorisierungsalgorithmus erhöhte automatisch die Kritikalität der Schwachstelle.

Die Behebung wurde etwa sechs Stunden nach der initialen Erkennung umgesetzt und verhinderte eine erfolgreiche Ausnutzung.

8. Diskussion

Die Ergebnisse zeigen, dass die Korrelation zwischen Vulnerability-Scannern und Verhaltens-Telemetrie die Genauigkeit der Risikopriorisierung signifikant erhöht. Die Integration mit ATT&CK bietet eine operative Taxonomie, die die Interpretation von Sicherheitsereignissen erleichtert.

Allerdings weist der Ansatz Einschränkungen auf. Die Wirksamkeit hängt von der Qualität der erhobenen Telemetrie und der Überwachungsabdeckung der Umgebung ab. Darüber hinaus kann der kontinuierliche Betrieb mehrerer Scanner zusätzliche Rechenkosten in großskaligen Pipelines verursachen.

Eine weitere Einschränkung betrifft die Abhängigkeit von einer geeigneten Instrumentierung in Laufzeitumgebungen. Observability-Systeme auf Basis von eBPF sowie Runtime-Sensoren sind wesentlich, um Verhaltensnachweise zuverlässig zu erfassen.

9. Schlussfolgerung

Wir präsentierten eine bedrohungsorientierte DevSecOps-Architektur, die statische Analyse, dynamische Analyse, Sicherheit von Abhängigkeiten und verhaltensbasiertes Monitoring auf Grundlage von MITRE ATT&CK integriert. Wir formalisierten mathematisch die Berechnung des Residualrisikos in CI/CD-Pipelines und führten einen adaptiven Priorisierungsalgorithmus ein, der technischen Schweregrad, operativen Kontext und Exploit-Hinweise berücksichtigt.

Die empirische Bewertung zeigte signifikante Reduktionen operativer Sicherheitsmetriken, einschließlich Erkennungszeit, Behebungszeit und der Anzahl kritischer Schwachstellen in Produktion. Diese Ergebnisse deuten darauf hin, dass die Korrelation von Runtime-Telemetrie und Schwachstellenanalyse einen wirksameren Ansatz für das Risikomanagement in DevSecOps-Umgebungen bietet.

Die vorgestellte Architektur ist kompatibel mit zeitgenössischen Sicherheitspraktiken in Software-Lieferketten, einschließlich der Erstellung von SBOMs und Build-Integritäts-Frameworks wie SLSA, und ermöglicht eine höhere Rückverfolgbarkeit und Zuverlässigkeit in kontinuierlichen Bereitstellungsprozessen.

References

ALLAMANIS, Miltiadis et al. A survey of machine learning for big code and naturalness. ACM Computing Surveys, v. 51, n. 4, 2018. Available at: https://doi.org/10.1145/3212695

BEHL, Abhishek; BEHL, Kanika. Cybersecurity and cyberwar: what everyone needs to know. Journal of Information Security, v. 8, n. 2, 2017. Available at: https://doi.org/10.4236/jis.2017.82008

CISA. SolarWinds supply chain compromise. 2021. Available at: https://www.cisa.gov/news-events/alerts/aa20-352a

FIRST. Common Vulnerability Scoring System v3.1 Specification. 2019. Available at: https://www.first.org/cvss/specification-document

HUTCHINS, Eric M.; CLOPPERT, Michael J.; AMIN, Rohan. Intelligence‑driven computer network defense informed by analysis of adversary campaigns. 2011. Available at: https://apps.dtic.mil/sti/citations/ADA547669

KIM, Gene et al. The DevOps Handbook. Portland: IT Revolution Press, 2016. Available at: https://itrevolution.com/product/the-devops-handbook

MITRE. ATT&CK for Enterprise Matrix. 2023. Available at: https://attack.mitre.org

MYRBATEN, Nils; COLPAERT, Pieter; PRETSCHNER, Alexander. DevSecOps: a multivocal literature review. IEEE Access, 2020. Available at: https://doi.org/10.1109/ACCESS.2020.3005717

NIST. NVD CVE‑2021‑44228 Detail. 2021. Available at: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

NIST. Secure Software Development Framework (SSDF) SP 800‑218. 2022. Available at: https://doi.org/10.6028/NIST.SP.800-218

OWASP. OWASP Top 10 – 2021. 2021. Available at: https://owasp.org/www-project-top-ten

OWASP. Dependency‑Check Project. 2023. Available at: https://owasp.org/www-project-dependency-check

RAHMAN, Foyzur et al. The impact of false positives on static analysis. ACM CCS, 2019. Available at: https://doi.org/10.1145/3319535.3363202

SCARFONE, Karen; SOUZA, Ricardo. Guide to intrusion detection and prevention systems. NIST SP 800‑94. 2012. Available at: https://doi.org/10.6028/NIST.SP.800-94

SHARMA, Tushar; COYNE, Eoin. Continuous security in DevOps pipelines. IEEE Security & Privacy, 2020. Available at: https://doi.org/10.1109/MSEC.2020.2970417

SIGSTORE PROJECT. Sigstore documentation. 2023. Available at: https://www.sigstore.dev

SLSA. Supply‑chain Levels for Software Artifacts Specification. 2023. Available at: https://slsa.dev

TRIVY PROJECT. Trivy vulnerability scanner documentation. 2024. Available at: https://aquasecurity.github.io/trivy

ZALANDO. Falco runtime security project. 2023. Available at: https://falco.org

OPEN INFORMATION SECURITY FOUNDATION. Suricata IDS documentation. 2023. Available at: https://suricata.io

CNCF. Cloud Native Security Whitepaper. 2023. Available at: https://www.cncf.io/reports/cloud-native-security-whitepaper

CYCLONEDX. CycloneDX SBOM specification. 2023. Available at: https://cyclonedx.org

SCOTT, James; WILSON, Mark. Observability in cloud native systems. O’Reilly Media, 2022. Available at: https://www.oreilly.com/library/view/observability-engineering

GOOGLE. Binary Authorization and secure supply chains. 2023. Available at: https://cloud.google.com/binary-authorization

CILIUM PROJECT. eBPF-based runtime security and observability. 2023. Available at: https://cilium.io