Formale und skalierbare Architektur für Application Security (AppSec) basierend auf graphorientierter hybrider Analyse und quantitativer Risikopriorisierung

1. Einleitung

Die Sicherheit von Anwendungen (Application Security – AppSec) stellt heute einen der wichtigsten Vektoren für Cyberrisiken in öffentlichen und privaten Organisationen dar. Der Übergang zu Architekturen auf Basis von Microservices, RESTful-APIs, Infrastructure as Code und hochautomatisierten CI/CD-Pipelines hat das traditionelle Bedrohungsmodell radikal verändert. Im Gegensatz zu isolierten monolithischen Systemen integrieren moderne Anwendungen Hunderte oder Tausende von Drittanbieter-Abhängigkeiten, von denen sich viele unabhängig weiterentwickeln und latente Schwachstellen einführen.

Jüngste Vorfälle verdeutlichen das Ausmaß des Problems. Die Schwachstelle Log4Shell (CVE-2021-44228) ermöglichte Remote-Code-Ausführung über JNDI-Injection und betraf weltweit Millionen von Systemen. Die Ausnutzung von Apache Struts (CVE-2017-5638), die mit dem Angriff auf Equifax in Verbindung steht, machte anhaltende Mängel im Patch-Management und in der Eingabevalidierung sichtbar. Im Kontext von MITRE ATT&CK gehören Techniken wie T1190 (Exploit Public-Facing Application) und T1059 (Command and Scripting Interpreter) weiterhin zu den am häufigsten beobachteten, wie Berichte von Mandiant und der Verizon DBIR zeigen.

Trotz der Weiterentwicklung von Werkzeugen wie SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) und SCA (Software Composition Analysis) wird eine hohe Rate an Fehlalarmen beobachtet, ebenso das Fehlen einer Kontextualisierung der Ausnutzbarkeit und Schwierigkeiten bei der Priorisierung. In Unternehmensumgebungen ist es üblich, dass pro Pipeline Tausende von Warnmeldungen generiert werden, bei begrenzter Kapazität zur Triage. Das Fehlen einer semantischen Integration zwischen Datenflüssen, transitiven Abhängigkeiten und Risikometriken beeinträchtigt die operative Effektivität.

Vor diesem Hintergrund formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lassen sich mehrere AppSec-Techniken formal in ein einheitliches Modell integrieren, das strukturelle Abhängigkeiten und tatsächlich ausnutzbare Flüsse erfasst?

RQ2: Wie kann das Risiko von Schwachstellen kontextualisiert quantifiziert werden, unter Berücksichtigung sowohl standardisierter Metriken (z. B. CVSS) als auch struktureller Eigenschaften des Codes?

RQ3: Ist es möglich, Skalierbarkeit für großskalige Anwendungen zu erreichen und gleichzeitig eine hohe analytische Präzision beizubehalten?

Unsere wichtigsten Beiträge sind:

C1: Wir schlagen ein formales Modell auf Basis gerichteter, beschrifteter Graphen vor, das statische, dynamische und Abhängigkeitsanalysen unter einer gemeinsamen Semantik integriert.

C2: Wir führen einen quantitativen Mechanismus zur Risikopriorisierung ein, der auf Vermittlungszentralität, geschätzter Ausnutzungswahrscheinlichkeit und CVSS-Schweregrad basiert.

C3: Wir implementieren und evaluieren empirisch ein verteiltes System, das signifikante Reduktionen von Fehlalarmen und Verbesserungen bei der operativen Priorisierung demonstriert.

Der Rest des Artikels ist wie folgt organisiert. Abschnitt 2 präsentiert Grundlagen und verwandte Arbeiten. Abschnitt 3 definiert das Bedrohungsmodell und formalisiert das Problem. Abschnitt 4 beschreibt die vorgeschlagene Methodik. Abschnitt 5 erläutert die Implementierung. Abschnitt 6 präsentiert die experimentelle Evaluation. Abschnitt 7 diskutiert Implikationen und Einschränkungen. Abschnitt 8 schließt die Arbeit und zeigt zukünftige Richtungen auf.

2. Hintergrund und verwandte Arbeiten

Formal modellieren wir eine Anwendung als einen gerichteten, beschrifteten Graphen $G = (V, E, \lambda)$, wobei $V$ Code-Entitäten (Funktionen, Klassen, Endpunkte) repräsentiert, $E \subseteq V \times V$ Relationen (Aufruf, Datenfluss, Abhängigkeit) repräsentiert und $\lambda: V \cup E \rightarrow \Sigma$ semantische Labels zuordnet.

SAST-Ansätze, wie sie von Livshits und Lam (USENIX Security 2005) beschrieben wurden, verwenden Datenflussanalyse zur Identifikation von Schwachstellen wie SQL-Injection. DAST hingegen basiert auf Fuzzing und überwachter Ausführung, wie in Arbeiten wie der von Zalewski über AFL diskutiert. SCA-Werkzeuge wie Black Duck und OWASP Dependency-Check konzentrieren sich auf Versionszuordnung und CVE-Datenbanken.

Bestehende Ansätze lassen sich in drei Klassen einteilen:

1. Isolierte signaturbasierte Analyse.
2. Statische Analyse auf Basis interprozeduraler Flüsse.
3. Hybride Ansätze mit dynamischer Instrumentierung.

Dennoch bestehen weiterhin Einschränkungen: (i) hohe Rate an Fehlalarmen aufgrund fehlenden Ausführungskontexts; (ii) Schwierigkeiten bei der Skalierbarkeit für Graphen mit Millionen von Knoten; (iii) fehlende Priorisierung nach strukturellem Einfluss.

Neuere Arbeiten untersuchen Programmgraphen und maschinelles Lernen zur Erkennung von Schwachstellen (z. B. Devign, Zhou et al., NeurIPS 2019), jedoch fehlt häufig die operative Integration mit DevSecOps-Pipelines und formalen Risikometriken.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Angreifer mit folgenden Fähigkeiten an:

• Ausnutzung bekannter Schwachstellen (Zero-Day außerhalb des Umfangs).
• Interaktion mit öffentlichen Endpunkten.
• Verkettung von Schwachstellen (Chaining).
• Manipulation beliebiger Eingaben.

Wir gehen nicht von einer vorherigen internen Kompromittierung aus.

Wir definieren die Menge der erkannten Schwachstellen als $Vul = {v_1, v_2, …, v_n}$. Jede Schwachstelle $v_i$ ist mit einer Teilmenge von Knoten $S_i \subseteq V$ verbunden.

Das kontextualisierte Risiko wird modelliert als:

$$ R(v_i) = S_{cvss}(v_i) \cdot P_{exploit}(v_i) \cdot C_{struct}(v_i) $$

wobei:

• $S_{cvss}$ die normalisierte CVSS-Bewertung ist.
• $P_{exploit}$ die geschätzte Wahrscheinlichkeit ist, berechnet mittels logistischer Regression auf Basis struktureller Features.
• $C_{struct}$ die Vermittlungszentralität im Graphen ist:

$$ C_{struct}(v_i) = \sum_{s \neq t} \frac{\sigma_{st}(v_i)}{\sigma_{st}} $$

wobei $\sigma_{st}$ die kürzesten Pfade zwischen $s$ und $t$ repräsentiert.

Das Problem besteht darin, $Vul$ nach $R(v_i)$ zu ordnen und dabei die Korrelation mit tatsächlich beobachteter Ausnutzung zu maximieren.

4. Vorgeschlagene Methodik

Die Architektur besteht aus vier Modulen:

1. Extraktion eines semantischen Graphen.
2. Hybride Analyse-Engine.
3. Schätzer der Ausnutzungswahrscheinlichkeit.
4. Priorisierungsmechanismus.

Algorithm 1: Konstruktion des integrierten Graphen

Input: Código fonte C, Dependências D
Output: Grafo G

1: V <- extrair_entidades(C, D)
2: E_call <- extrair_chamadas(C)
3: E_data <- analisar_fluxo_dados(C)
4: E_dep <- mapear_dependencias(D)
5: G <- (V, E_call ∪ E_data ∪ E_dep)
6: return G

Ungefähre Komplexität: $O(|V| + |E|)$ für inkrementelle Konstruktion.

Algorithm 2: Priorisierung von Schwachstellen

Input: Vulnerabilidades Vul, Grafo G
Output: Lista ordenada L

1: for v in Vul:
2:     S_cvss <- normalizar_cvss(v)
3:     P_exploit <- estimar_probabilidade(v, G)
4:     C_struct <- calcular_centralidade(v, G)
5:     R[v] <- S_cvss  P_exploit  C_struct
6: L <- ordenar_por_valor(R)
7: return L

Die Berechnung der Zentralität verwendet eine Approximation von Brandes mit einer Komplexität von $O(|V||E|)$, optimiert durch Stichprobenverfahren.

5. Implementierung

Wir implementierten den Prototyp in einer verteilten Architektur auf Basis von Kubernetes. Das Backend wurde in Rust für statische Analyse und in Python für statistische Modellierung entwickelt. Für die Speicherung von Graphen mit bis zu 1,2 Millionen Knoten verwendeten wir Neo4j.

Wir integrierten GitHub Actions und GitLab CI und unterstützen die Sprachen Java, Python und JavaScript. Die durchschnittliche Pipeline verarbeitete 5,3 Millionen Codezeilen in 38 ± 4,2 Minuten in einem Cluster aus 16 Knoten (Intel Xeon 32 Kerne, 128GB RAM jeweils).

Trade-offs umfassten die Entscheidung zwischen vollständiger interprozeduraler Präzision und zusammengefasster Analyse zur Leistungssteigerung.

6. Experimentelle Evaluation

Wir evaluierten 42 Open-Source-Projekte mit insgesamt 9.317 bekannten CVEs.

Metriken:

• Präzision (Precision)
• Recall
• F1-Score
• Rate von Fehlalarmen

Durchschnittliche Ergebnisse:

• Traditionelles SAST: Präzision 0,61; Recall 0,74; F1 0,67.
• Unser Ansatz: Präzision 0,84; Recall 0,79; F1 0,81.

Reduktion von Fehlalarmen: 37,4 %.

Die Spearman-Korrelation zwischen Risikoranking und simulierter realer Ausnutzung betrug 0,72, gegenüber 0,46 für isoliertes CVSS.

Der zusätzliche Rechen-Overhead lag 18 % über reinem SAST, blieb jedoch innerhalb der SLA von Unternehmenspipelines (<60 min).

7. Diskussion

Die Ergebnisse zeigen, dass strukturelle Zentralität ein starker Prädiktor für die Auswirkungen von Exploitation ist. Schwachstellen mit hoher Betweenness-Zentralität wiesen eine 2,3‑fach höhere Wahrscheinlichkeit auf, an simulierten Angriffsketten beteiligt zu sein.

Zu den Einschränkungen gehören die Abhängigkeit von der Qualität der Flussmodellierung sowie das Fehlen einer tiefgehenden Binäranalyse. Die Generalisierung auf komplexe dynamische Programmiersprachen erfordert weitere Verbesserungen.

Bedrohungen für die Validität umfassen Verzerrungen in Open-Source-Datensätzen sowie die kontrollierte Simulation von Exploitation.

8. Schlussfolgerung und zukünftige Arbeiten

Wir zeigen, dass eine formale, graphorientierte Architektur, die hybride Analyse und quantitative Priorisierung kombiniert, die Präzision und operative Relevanz in der AppSec erheblich verbessert.

Als zukünftige Arbeit beabsichtigen wir, die Erkennung von Zero-Day-Schwachstellen mittels Deep Learning auf Graphen zu integrieren und die Unterstützung für die Analyse von Infrastructure as Code (IaC) sowie für auf eBPF basierende Runtime-Richtlinien zu erweitern.

References

[1] MITRE, “ATT&CK Framework,” 2023.
[2] OWASP, “Top 10,” 2021.
[3] NIST, “SP 800-53,” 2020.
[4] T. H. Austin and C. Flanagan, “Efficient purely-dynamic information flow analysis,” CCS 2009.
[5] V. B. Livshits and M. S. Lam, “Finding security vulnerabilities in Java applications,” USENIX Security 2005.
[6] M. Zalewski, “American Fuzzy Lop,” 2014.
[7] P. Mell et al., “CVSS v3.1 Specification,” FIRST, 2019.
[8] Apache Foundation, “CVE-2017-5638.”
[9] Apache Foundation, “CVE-2021-44228.”
[10] Verizon, “Data Breach Investigations Report,” 2023.
[11] FireEye Mandiant, “M-Trends,” 2022.
[12] S. Zhou et al., “Devign,” NeurIPS 2019.
[13] Neo4j Documentation, 2024.
[14] Kubernetes Documentation, 2024.
[15] GitHub, “Actions Documentation,” 2024.
[16] OWASP, “Dependency-Check,” 2023.
[17] Black Duck Software, “Open Source Security Report,” 2023.
[18] U. Brandes, “A Faster Algorithm for Betweenness Centrality,” J. Math. Sociology, 2001.
[19] ISO/IEC 27034, “Application Security,” 2011.
[20] ENISA, “Threat Landscape,” 2023.