TÍTEL: Eine formale und operative Architektur für threat-orientierte AppSec: Integration von SAST, DAST, SCA, Runtime-Telemetrie und ATT&CK-Intelligenz zur risikobasierten Priorisierung ausnutzbarer Schwachstellen

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 Integration und Continuous Delivery (CI/CD) erheblich erweitert. In diesem Szenario werden Anwendungen zu hochdynamischen Systemen, die aus mehreren voneinander abhängigen Komponenten bestehen, die häufig in Cloud-Umgebungen bereitgestellt und von Plattformen wie Kubernetes orchestriert werden. Diese architektonische Transformation hat die Komplexität des Managements der Anwendungssicherheit erhöht und neue Ausnutzungspfade 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 bekannt gewordene Vorfälle – wie Log4Shell (CVE-2021-44228) – gezeigt, dass Schwachstellen in weit verbreiteten Bibliotheken systemische Auswirkungen in globalem 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 den frühen Phasen von Angriffsketten beobachtet werden (MITRE, 2024). Dennoch arbeiten traditionelle Sicherheitswerkzeuge für Anwendungen überwiegend isoliert.

Werkzeuge für die statische Analyse (SAST) untersuchen Quellcode auf Muster von Schwachstellen. Werkzeuge für die dynamische Analyse (DAST) führen simulierte Angriffe gegen laufende Anwendungen aus. Werkzeuge zur Software Composition Analysis (SCA) identifizieren hingegen verwundbare Abhängigkeiten in Bibliotheken von Drittanbietern. Obwohl jeder Ansatz relevante Hinweise liefert, erzeugt das Fehlen einer systematischen Korrelation zwischen diesen Quellen ein großes Volumen an Warnungen und erschwert die Priorisierung von Gegenmaßnahmen.

Das zentrale Problem, das in dieser Arbeit untersucht wird, ist die strukturelle Fragmentierung zwischen Mechanismen zur Erkennung von Schwachstellen 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.

Aus dieser Lücke heraus formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lassen sich mehrere Quellen von Evidenz zur Anwendungssicherheit formal konsistent und quantitativ messbar integrieren?

RQ2: Ist es möglich, Fehlalarme zu reduzieren und potenziell ausnutzbare Schwachstellen durch Korrelation mit im Runtime-Betrieb beobachteter Telemetrie zu priorisieren?

RQ3: Welchen operativen Einfluss hat diese Integration auf die Effizienz von Triagierung und Mitigierung 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-Monitoring im Einklang mit MITRE ATT&CK integriert.
• Quantitative experimentelle Bewertung, die eine signifikante Reduktion von Fehlalarmen und eine verbesserte Priorisierung von Schwachstellen demonstriert.

2. Hintergrund und verwandte Arbeiten

2.1 Statische Anwendungssicherheitsanalyse

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

Einschleusungsschwachstellen können als Datenflusswege zwischen nicht vertrauenswürdigen Quellen $S$ und sensiblen Senken $K$ modelliert werden:

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

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

2.2 Dynamische Anwendungssicherheitsanalyse

DAST führt aktive Tests gegen laufende Anwendungen aus, um verwundbares Verhalten zur Laufzeit 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 beeinträchtigen, 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 der NVD.

2.4 Runtime-Telemetrie und eBPF

In den letzten Jahren sind eBPF-basierte 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).

Gleichzeitig ermöglichen netzwerkbasierte Intrusion-Detection-Systeme wie Suricata die Identifikation von Ausnutzungsmustern, die im Netzwerkverkehr beobachtet werden (OISF, 2023).

2.5 Grenzen aktueller Ansätze

Mehrere Studien weisen auf Grenzen der Priorisierung von Schwachstellen hin, die 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 noch keine beobachtenden Runtime-Evidenzen.

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

3. Bedrohungsmodell und Problemformalierung

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

• automatisiertes Scanning exponierter Dienste durchzuführen;
• Schwachstellen in öffentlichen 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 erkannten Schwachstelle darstellt;
• $T$ beobachtete Evidenz in der Runtime-Telemetrie darstellt;
• $C$ den Betriebskontext darstellt (Netzwerkexposition, Privilegien, Kritikalität);
• $E$ das Eintreten einer Ausnutzung darstellt;
• $I$ den potenziellen Impact 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	Beispiele für Werkzeuge
Erfassung	Ausführung von Scannern und Sammlung von Ereignissen	Semgrep, ZAP, Dependency-Check, Falco
Normalisierung	Standardisierung von Daten	JSON Schema, SBOM CycloneDX
Korrelation	Probabilistische Inferenz	Bayes’sche Engine
Priorisierung	Erstellung eines Risikorankings	SIEM-Integration

Korrelationsalgorithmus:

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

for each vulnerability 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)
    risiko = impacto(v)  p_exploit

    adicionar(v, risiko)

ordenar_lista_por_risco()
retornar_lista()

Die dominierende Komplexität liegt in der Sortierphase, was zu $O(n \log n)$ führt.

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 — Analyse von Abhängigkeiten mit OWASP Dependency-Check
• Stage 3 — Generierung von SBOM im CycloneDX-Format
• Stage 4 — dynamische Tests mit OWASP ZAP
• Stage 5 — Deployment in einer von Falco überwachten Staging-Umgebung

Beispiel für eine 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: Possível reverse shell detectado
  priority: CRITICAL

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

6. Experimentelle Evaluation

Die experimentelle Evaluation wurde in einer Infrastruktur durchgeführt, die aus drei Dell PowerEdge R740-Servern bestand, auf denen Kubernetes 1.27 lief.

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 der Fehlalarme um 37,4 % sowie eine Verringerung der durchschnittlichen Triagierungszeit von 4,2 Stunden auf 3,0 Stunden.

7. Fallstudie

Wir verwendeten die verwundbare Anwendung OWASP Juice Shop zur Validierung des Modells.

Beobachteter Ablauf:

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

Das Modell wies eine Ausnutzungswahrscheinlichkeit von 0,87 zu und stufte die Schwachstelle als kritisch ein.

8. Diskussion

Die Ergebnisse zeigen, dass die Korrelation mehrerer Evidenzquellen das operative Rauschen erheblich reduziert. Der Hauptvorteil der vorgeschlagenen Architektur liegt in der Fähigkeit, Schwachstellen durch beobachtbare Evidenz zu kontextualisieren.

Dennoch bleiben einige Einschränkungen bestehen. Das Bayes’sche Modell nimmt bedingte Unabhängigkeit zwischen Evidenzen an, was komplexe Wechselwirkungen zwischen Angriffspfaden möglicherweise nicht vollständig abbildet. Darüber hinaus hängt die Wirksamkeit des Systems von der Qualität der erfassten Telemetrie ab.

Der Overhead des eBPF-basierten Monitorings blieb in den durchgeführten Experimenten unter 6 % zusätzlicher CPU-Auslastung.

9. Schlussfolgerung

Wir präsentierten eine formale und operative, bedrohungsorientierte Architektur für Anwendungssicherheit, 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 in modernen 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.