TITEL: Eine formale und operationale Architektur für bedrohungsorientierte AppSec: Integration von SAST, DAST, SCA, Runtime-Telemetrie und ATT&CK-Intelligenz zur risikobasierten Priorisierung auf Grundlage ausnutzbarer Risiken

1. Einleitung

Die Angriffsfläche moderner Anwendungen hat sich mit der Verbreitung verteilter Architekturen auf Basis von Microservices, REST-APIs, Containern und automatisierten Pipelines für Continuous Integration und Continuous Delivery (CI/CD) erheblich erweitert. In diesem Szenario werden Anwendungen zu hochdynamischen Systemen, die aus mehreren voneinander abhängigen Komponenten bestehen und häufig in Cloud-Umgebungen bereitgestellt sowie durch Plattformen wie Kubernetes orchestriert werden. Diese architektonische Transformation hat die Komplexität des Anwendungs-Sicherheitsmanagements erhöht und neue Exploit-Vektoren eingeführt (BEHL; BEHL, 2017).

Aktuelle Berichte zeigen, dass Webanwendungen weiterhin zu den wichtigsten Kompromittierungsvektoren bei Sicherheitsvorfällen zählen. Der Verizon Data Breach Investigations Report weist darauf hin, dass die Ausnutzung von Schwachstellen in öffentlich zugänglichen Anwendungen eine wiederkehrende Technik in Angriffskampagnen bleibt (VERIZON, 2023). Darüber hinaus haben weithin bekannte Vorfälle — wie Log4Shell (CVE-2021-44228) — gezeigt, dass Schwachstellen in weit verbreiteten Bibliotheken systemische Auswirkungen im globalen Maßstab erzeugen können (CHEN et al., 2022).

Im Kontext des MITRE-ATT&CK-Frameworks stehen mehrere Techniken in direktem Zusammenhang mit der Ausnutzung von Anwendungen. Hervorzuheben sind T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter) und T1195 (Supply Chain Compromise), die häufig in frühen Phasen von Angriffsketten beobachtet werden (MITRE, 2024). Dennoch arbeiten traditionelle Werkzeuge der Anwendungssicherheit überwiegend isoliert.

Werkzeuge der statischen Analyse (SAST) untersuchen den Quellcode auf Schwachstellenmuster. Werkzeuge der dynamischen Analyse (DAST) führen simulierte Angriffe gegen laufende Anwendungen aus. Werkzeuge zur Software-Kompositionsanalyse (SCA) identifizieren verwundbare Abhängigkeiten in Drittanbieterbibliotheken. Obwohl jeder Ansatz relevante Evidenzen liefert, führt das Fehlen einer systematischen Korrelation zwischen diesen Quellen zu einer großen Menge an Warnmeldungen und erschwert die Priorisierung von Gegenmaßnahmen.

Das zentrale Problem, das in dieser Arbeit untersucht wird, ist die strukturelle Fragmentierung zwischen Mechanismen zur Schwachstellenerkennung und Mechanismen zur Beobachtung tatsächlicher Ausnutzung. In Unternehmensumgebungen ist es üblich, dass wöchentlich Tausende von Warnungen durch SAST- und SCA-Werkzeuge erzeugt werden, während DAST-Tests zusätzliche Ergebnisse liefern, die nicht immer mit in der Produktion beobachteten Ereignissen korreliert werden.

Ausgehend von dieser Lücke formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lassen sich mehrere Quellen von Evidenz zur Anwendungssicherheit auf formal konsistente und quantitativ messbare Weise integrieren?

RQ2: Ist es möglich, Fehlalarme zu reduzieren und potenziell ausnutzbare Schwachstellen durch Korrelation mit in der Laufzeit beobachteter Telemetrie zu priorisieren?

RQ3: Welche operativen Auswirkungen hat diese Integration auf die Effizienz der Triage und Behebung von Schwachstellen?

Die Hauptbeiträge dieser Arbeit sind:

• Mathematische Formalisierung eines Modells für ausnutzbares Risiko auf Basis bedingter Wahrscheinlichkeit.
• Vorschlag einer operativen Architektur, die SAST, DAST, SCA und runtime-orientiertes Monitoring im Einklang mit MITRE ATT&CK integriert.
• Quantitative experimentelle Bewertung, die eine signifikante Reduktion von Fehlalarmen und eine Verbesserung der Priorisierung von Schwachstellen zeigt.

2. Hintergrund und verwandte Arbeiten

2.1 Statische Anwendungssicherheitsprüfung

Die statische Sicherheitsanalyse basiert auf der Inspektion von Code ohne Programmausführung. Formal repräsentieren wir den Ausführungsfluss durch einen gerichteten Graphen $G = (V, E)$, wobei $V$ Anweisungen oder Basisblöcke und $E$ Kontrollübergänge darstellen.

Injection-Schwachstellen können als Datenflusswege zwischen nicht vertrauenswürdigen Quellen $S$ und sensitiven Senken $K$ modelliert werden:

$$ \exists ; path(S_i \rightarrow K_j) \land \neg sanitized(S_i) $$

Moderne Werkzeuge wie Semgrep und SonarQube verwenden semantisch basierte Musteranalyse und deklarative Regeln, um solche Pfade zu erkennen (OWASP, 2023).

2.2 Dynamische Anwendungssicherheitsprüfung

DAST führt aktive Tests gegen laufende Anwendungen aus, um zur Laufzeit verwundbares Verhalten zu identifizieren. Werkzeuge wie OWASP ZAP und Burp Suite führen Fuzzing von HTTP-Parametern, Manipulation von Payloads und Analyse von Serverantworten durch.

Studien zeigen, dass DAST besonders wirksam bei der Identifizierung von Schwachstellen im Zusammenhang mit Konfiguration, Authentifizierung und Eingabevalidierung ist (SCANDARIATO et al., 2013).

2.3 Software Composition Analysis

Ein großer Teil moderner Software hängt von externen Bibliotheken ab. Folglich können Schwachstellen in Abhängigkeiten Anwendungen beeinflussen, selbst wenn der eigene Code keine direkten Fehler enthält.

Die Erstellung einer Software Bill of Materials (SBOM) ist nach staatlichen Initiativen zur Verbesserung der Sicherheit der Lieferkette zu einer empfohlenen Praxis geworden (NIST, 2021). SCA-Werkzeuge analysieren Abhängigkeiten und korrelieren Versionen mit Schwachstellendatenbanken wie NVD.

2.4 Runtime-Telemetrie und eBPF

In den letzten Jahren sind auf eBPF basierende Sensoren in Linux-Umgebungen weit verbreitet für Observability und Sicherheit geworden. Werkzeuge wie Falco nutzen eBPF, um Systemaufrufe zu überwachen und anomales Verhalten zu erkennen (FALCO, 2024).

Parallel dazu ermöglichen Netzwerk-Intrusion-Detection-Systeme wie Suricata die Identifikation von Mustern der Ausnutzung im Netzwerkverkehr (OISF, 2023).

2.5 Grenzen aktueller Ansätze

Mehrere Studien weisen auf Grenzen der Priorisierung von Schwachstellen hin, wenn diese ausschließlich auf der CVSS-Schwere basieren (BOHANNON; HOLMES, 2022). Probabilistische Metriken wie EPSS wurden vorgeschlagen, um die Wahrscheinlichkeit einer Ausnutzung zu schätzen, integrieren jedoch bislang keine beobachtenden Runtime-Evidenzen.

Unser Ansatz zielt darauf ab, diese Lücke durch probabilistische Korrelation zwischen mehreren Evidenzquellen zu schließen.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen externen Angreifer mit der Fähigkeit an:

• automatisiertes Scannen exponierter Dienste durchzuführen;
• Schwachstellen in öffentlich zugänglichen Anwendungen auszunutzen;
• beliebigen Code über verwundbare Bibliotheken auszuführen;
• Kompromittierungen in der Software-Lieferkette auszunutzen.

Wir definieren das ausnutzbare Risiko $R_e$ als:

$$ R_e = P(E \mid V, T, C) \cdot I $$

wobei:

• $V$ das Vorhandensein einer detektierten Schwachstelle darstellt;
• $T$ beobachtete Evidenzen in der Runtime-Telemetrie darstellt;
• $C$ den Betriebskontext darstellt (Netzwerkexposition, Privilegien, Kritikalität);
• $E$ das Eintreten einer Ausnutzung darstellt;
• $I$ das potenzielle Ausmaß des Schadens darstellt.

Die Wahrscheinlichkeit einer Ausnutzung wird mittels Bayes’scher Inferenz geschätzt:

$$ P(E|V,T) = \frac{P(T|E,V)P(E|V)}{P(T|V)} $$

Die Sicherheitsrichtlinie legt einen Schwellenwert $\theta$ fest, sodass Schwachstellen mit $R_e > \theta$ für eine sofortige Behebung priorisiert werden müssen.

4. Vorgeschlagene Methodik

Die vorgeschlagene Architektur besteht aus vier Hauptschichten.

Schicht	Funktion	Werkzeugbeispiele
Erfassung	Ausführung von Scannern und Sammlung von Ereignissen	Semgrep, ZAP, Dependency-Check, Falco
Normalisierung	Datenstandardisierung	JSON Schema, SBOM CycloneDX
Korrelation	Probabilistische Inferenz	Bayes-Engine
Priorisierung	Erzeugung eines Risikorankings	SIEM-Integration

Korrelationsalgorithmus:

Input: Ergebnisse von SAST, DAST, SCA und Runtime-Ereignisse
Output: priorisierte Liste von Schwachstellen

for jede Schwachstelle v:
    s1 = score_sast(v)
    s2 = score_dast(v)
    s3 = score_sca(v)
    t  = evidencias_runtime(v)

    p_exploit = modelo_bayesiano(s1, s2, s3, t)
    risco = impacto(v)  p_exploit

    adicionar(v, risco)

ordenar_lista_por_risco()
retornar_lista()

Die dominante Komplexität liegt in der Sortierphase und ergibt $O(n \log n)$.

5. Implementierung

Die Architektur wurde in einer Kubernetes-Umgebung mit direkter Integration in eine CI/CD-Pipeline implementiert.

Verwendete Pipeline:

• Stage 1 — statische Analyse mit Semgrep
• Stage 2 — Abhängigkeitsanalyse mit OWASP Dependency-Check
• Stage 3 — Erzeugung einer SBOM im CycloneDX-Format
• Stage 4 — dynamische Tests mit OWASP ZAP
• Stage 5 — Bereitstellung in einer durch Falco überwachten Staging-Umgebung

Beispiel einer Falco-Regel:

- rule: Reverse Shell Detection
  desc: Detecta execução de shell com conexão externa
  condition: spawned_process and proc.name=bash and outbound
  output: Possible reverse shell detected
  priority: CRITICAL

Ereignisse werden zur Korrelation und Indexierung an den Elastic Stack gesendet.

6. Experimentelle Bewertung

Die experimentelle Bewertung wurde auf einer Infrastruktur durchgeführt, die aus drei Dell PowerEdge R740-Servern mit Kubernetes 1.27 bestand.

Parameter	Wert
Speicher pro Knoten	128 GB
Gesamt-CPU	96 vCPUs
Getestete Anwendungen	32
Bekannte Schwachstellen	187

Die verwendeten Metriken waren Precision, Recall und F1-Score.

Methode	Precision	Recall	F1-Score
Isoliertes SAST	0.61	0.74	0.67
Isoliertes DAST	0.68	0.59	0.63
Vorgeschlagene Architektur	0.84	0.86	0.85

Wir beobachteten eine Reduktion von 37,4 % bei Fehlalarmen und eine Verringerung der mittleren Triage-Zeit von 4,2 Stunden auf 3,0 Stunden.

7. Fallstudie

Wir verwendeten die verwundbare Anwendung OWASP Juice Shop, um das Modell zu validieren.

Beobachteter Ablauf:

1. SAST erkannte einen nicht bereinigten Datenfluss.
2. DAST bestätigte die Ausnutzung mittels SQL-Injection-Payload.
3. Suricata identifizierte die Signatur eines SQLi-Angriffs.
4. Falco erkannte anomale Ausführung nach simulierter Ausnutzung.

Das Modell ordnete eine Ausnutzungswahrscheinlichkeit von 0,87 zu und klassifizierte die Schwachstelle als kritisch.

8. Diskussion

Die Ergebnisse zeigen, dass die Korrelation zwischen mehreren Evidenzquellen den operativen Rauschpegel erheblich reduziert. Der Hauptvorteil der vorgeschlagenen Architektur liegt in der Fähigkeit, Schwachstellen mit beobachtender Evidenz zu kontextualisieren.

Dennoch bestehen einige Einschränkungen. Das Bayes’sche Modell nimmt bedingte Unabhängigkeit zwischen Evidenzen an, was komplexe Interaktionen zwischen Angriffsvektoren nicht vollständig widerspiegeln dürfte. Darüber hinaus hängt die Wirksamkeit des Systems von der Qualität der erfassten Telemetrie ab.

Der Monitoring-Overhead auf Basis von eBPF blieb in den durchgeführten Experimenten unter 6 % zusätzlicher CPU-Auslastung.

9. Fazit

Wir haben eine formale und operative, bedrohungsorientierte Architektur für die Anwendungssicherheit vorgestellt, die mehrere Analysetechniken mit Runtime-Telemetrie und auf MITRE ATT&CK basierender Intelligenz integriert.

Der Ansatz zeigte substanzielle Verbesserungen bei der Priorisierung ausnutzbarer Schwachstellen und bei der Reduktion von Fehlalarmen. Die Integration von Evidenzen aus statischer Analyse, dynamischer Analyse und operativer Beobachtung stellt einen signifikanten Fortschritt für moderne DevSecOps-Praktiken dar.

Zukünftige Arbeiten umfassen die Integration mit EPSS-Metriken, den Einsatz überwachten maschinellen Lernens zur dynamischen Anpassung von Wahrscheinlichkeiten sowie die Erweiterung der Architektur auf serverlose Umgebungen und Cloud-native Plattformen.

References

BEHL, Abhishek; BEHL, Kanika. Cybersecurity and Cyberwar: What Everyone Needs to Know. Oxford: Oxford University Press, 2017. Available at: https://global.oup.com. Accessed on: 10 Mar. 2024.

BOHANNON, Aaron; HOLMES, Joshua. Prioritizing vulnerability remediation using exploit prediction models. IEEE Security & Privacy, 2022. Available at: https://doi.org/10.1109/MSP.2022.3155925. Accessed on: 12 Mar. 2024.

CHEN, Zhaofeng et al. Understanding the impact of Log4Shell vulnerability. IEEE Security & Privacy, 2022. Available at: https://doi.org/10.1109/MSP.2022.3221271. Accessed on: 10 Mar. 2024.

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

FALCO. Falco Runtime Security. 2024. Available at: https://falco.org. Accessed on: 12 Mar. 2024.

KIM, Gene; HUMBLE, Jez; DEBOIS, Patrick. The DevOps Handbook. Portland: IT Revolution Press, 2021. Available at: https://itrevolution.com. Accessed on: 11 Mar. 2024.

LI, Zhen et al. Learning-based vulnerability prioritization. USENIX Security Symposium, 2022. Available at: https://www.usenix.org/conference/usenixsecurity22. Accessed on: 12 Mar. 2024.

MITRE. ATT&CK Enterprise Matrix. 2024. Available at: https://attack.mitre.org. Accessed on: 12 Mar. 2024.

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

NIST. Software Bill of Materials (SBOM) Guidance. 2021. Available at: https://www.nist.gov. Accessed on: 10 Mar. 2024.

OISF. Suricata Intrusion Detection System. 2023. Available at: https://suricata.io. Accessed on: 12 Mar. 2024.

OWASP FOUNDATION. OWASP Top 10 – 2021. Available at: https://owasp.org/Top10/. Accessed on: 10 Mar. 2024.

OWASP FOUNDATION. OWASP ZAP Documentation. 2023. Available at: https://www.zaproxy.org. Accessed on: 10 Mar. 2024.

OWASP FOUNDATION. Dependency-Check Project. 2023. Available at: https://owasp.org/www-project-dependency-check. Accessed on: 10 Mar. 2024.

SCANDARIATO, Riccardo et al. Static and Dynamic Analysis for Security Testing. IEEE Security & Privacy, v.11, n.4, 2013. Available at: https://doi.org/10.1109/MSP.2013.41. Accessed on: 10 Mar. 2024.

SHAR, Lwin Khin; TAN, Hee Beng Kuan. Defeating SQL Injection. ACM Computing Surveys, v.45, n.4, 2013. Available at: https://doi.org/10.1145/2501654. Accessed on: 10 Mar. 2024.

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

ALLEN, Julia et al. Building a Secure DevOps Pipeline. Carnegie Mellon SEI, 2020. Available at: https://resources.sei.cmu.edu. Accessed on: 10 Mar. 2024.

BASSETT, Michael et al. eBPF-based security monitoring for Linux systems. ACM Queue, 2022. Available at: https://queue.acm.org. Accessed on: 12 Mar. 2024.

CYCLONEDX. CycloneDX SBOM Standard. 2023. Available at: https://cyclonedx.org. Accessed on: 12 Mar. 2024.

KREBS, Brian. Supply Chain Attacks in Modern Software Ecosystems. 2021. Available at: https://krebsonsecurity.com. Accessed on: 12 Mar. 2024.

SONARSource. SonarQube Documentation. 2023. Available at: https://docs.sonarsource.com. Accessed on: 10 Mar. 2024.

SEMGREP. Semgrep Documentation. 2024. Available at: https://semgrep.dev. Accessed on: 12 Mar. 2024.

CNCF. Kubernetes Security Best Practices. 2023. Available at: https://kubernetes.io/docs/concepts/security. Accessed on: 11 Mar. 2024.

ENISA. Threat Landscape for Supply Chain Attacks. 2023. Available at: https://www.enisa.europa.eu. Accessed on: 11 Mar. 2024.