TITEL: Evidenzorientierte AppSec: Ein formales und skalierbares Framework für die Orchestrierung der Anwendungssicherheit auf Basis von Threat Modeling und kontinuierlicher hybrider Analyse

1. Einleitung

Die Sicherheit von Anwendungen (Application Security — AppSec) hat sich zu einem der Grundpfeiler zeitgenössischer Cyberresilienz entwickelt. Die Migration zu verteilten Architekturen, cloud‑nativen Plattformen, öffentlichen APIs und DevSecOps-Pipelines hat die Angriffsfläche moderner Systeme erheblich erweitert. Empirische Berichte zeigen, dass ausnutzbare Schwachstellen in Anwendungen weiterhin zu den Hauptursachen von Sicherheitsvorfällen zählen (VERIZON, 2023).

Insbesondere führen Open‑Source-Abhängigkeitsketten zu systemischen Risiken. Der mit der Schwachstelle Log4Shell (CVE‑2021‑44228) verbundene Vorfall machte deutlich, wie eine einzige weit verbreitete Bibliothek Millionen von Systemen gleichzeitig beeinflussen kann (MITRE, 2021). Darüber hinaus bleiben in Webanwendungen ausgenutzte Schwachstellen ein dominanter Einfallsvektor für Intrusionen, häufig verbunden mit Techniken, die in der MITRE-ATT&CK-Matrix katalogisiert sind, wie T1190 (Exploit Public‑Facing Application) und T1059 (Command and Scripting Interpreter) (MITRE, 2023).

Die Struktur moderner Anwendungen lässt sich als gerichteter Graph formalisieren:

$$ G = (V, E) $$

wobei $V$ Softwarekomponenten (Dienste, Bibliotheken oder APIs) und $E$ Abhängigkeiten oder Datenflüsse zwischen diesen Komponenten repräsentiert. In auf Microservices basierenden Architekturen wächst die Anzahl der Kanten rasch, während Dienste integriert werden, wodurch die Angriffsfläche proportional vergrößert wird. Während die strukturelle Komplexität näherungsweise mit $O(|E|)$ wächst, analysieren viele Sicherheitswerkzeuge jeden Knoten isoliert, ohne Abhängigkeitsbeziehungen zu berücksichtigen.

Zu den traditionellen AppSec-Werkzeugen gehören statische Codeanalyse (SAST), dynamische Analyse (DAST) und Software Composition Analysis (SCA). Obwohl diese Ansätze weit verbreitet sind, erzeugen sie häufig fragmentierte Ergebnisse, die operativ schwer zu priorisieren sind (ANTUNES; VIEIRA, 2010). Das Fehlen formaler Mechanismen zur Korrelation von Evidenzen aus diesen Werkzeugen führt zu hohen Falsch-Positiv-Raten und erschwert die Bestimmung, welche Schwachstellen ein reales Risiko darstellen.

Darüber hinaus führt das jüngste Wachstum von Anwendungen, die Modelle der künstlichen Intelligenz und APIs auf Basis großer Sprachmodelle (LLMs) integrieren, zu neuen Angriffsflächen, wie Prompt Injection und unbeabsichtigter Offenlegung sensibler Daten. Obwohl diese Bedrohungen klassische Schwachstellen nicht ersetzen, erhöhen sie den Bedarf an integrierten, evidenzorientierten Analysemechanismen (OWASP, 2023).

Vor diesem Hintergrund formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das Risiko von Anwendungsschwachstellen formal modellieren, wenn heterogene Evidenzen aus mehreren Analysequellen berücksichtigt werden?

RQ2: Ist es möglich, Falsch-Positive zu reduzieren und die Priorisierung von Schwachstellen zu verbessern, ohne die Erkennungsabdeckung zu beeinträchtigen?

RQ3: Welchen operativen Einfluss hat eine kontinuierliche, auf probabilistischem Risiko basierende Orchestrierung in der DevSecOps-Pipeline?

Die Beiträge dieser Arbeit sind dreifach.

Erstens definieren wir formal eine bedingte Risikofunktion, die auf Bayes’scher Inferenz und kontextualisierten CVSS-Metriken basiert.

Zweitens schlagen wir die Architektur EO‑AppSec vor, die Ergebnisse aus SAST, DAST, SCA und operativer Telemetrie in einen Mechanismus probabilistischer Korrelation integriert.

Drittens bewerten wir das System empirisch im industriellen Maßstab und zeigen signifikante quantitative Verbesserungen bei der Priorisierung von Schwachstellen und der operativen Effizienz von Remediationsprozessen.

2. Hintergrund und verwandte Arbeiten

2.1 Formale Grundlagen der Schwachstellenbewertung

Wir formalisieren eine Schwachstelle als ein Tupel:

$$ v = (c, s, e) $$

wobei $c$ die Kategorie der Schwachstelle repräsentiert (zum Beispiel eine CWE-Klassifikation), $s$ die Basisschwere gemäß CVSS und $e$ eine Menge beobachtbarer Evidenzen aus Analysewerkzeugen oder operativer Telemetrie.

Das mit der Schwachstelle verbundene Risiko kann modelliert werden als:

$$ R(v) = P(E \mid v) \cdot I(v) $$

wobei $P(E \mid v)$ die bedingte Exploit-Wahrscheinlichkeit unter den beobachteten Evidenzen und $I(v)$ die potenzielle Auswirkung der Ausnutzung repräsentiert.

Unter Verwendung Bayes’scher Inferenz kann die a-posteriori-Exploit-Wahrscheinlichkeit dynamisch aktualisiert werden:

$$ P(v \mid E) = \frac{P(E \mid v) P(v)}{P(E)} $$

Dieses Modell erlaubt die Kombination mehrerer Evidenzquellen, einschließlich Scanner-Ergebnissen, Laufzeitdaten und der Historie von Schwachstellenausnutzung.

2.2 Werkzeuge und Erkennungsansätze

Techniken zur Schwachstellenerkennung lassen sich in vier Hauptkategorien einteilen.

Ansatz	Eigenschaften	Beispielwerkzeuge
SAST	Quellcodeanalyse ohne Ausführung	SonarQube, Coverity
DAST	Dynamische Tests in einer Laufzeitumgebung	OWASP ZAP, Burp Suite
SCA	Identifikation verwundbarer Abhängigkeiten	Snyk, Dependabot
Runtime/Observability	Laufzeittelemetrie und Verhaltensanalyse	eBPF observability, Falco

SAST-Werkzeuge analysieren Datenflüsse und potenziell unsichere Code-Muster (CHESS; WEST, 2007). DAST-Werkzeuge führen automatisierte Tests gegen laufende Anwendungen aus, um ausnutzbare Schwachstellen zu identifizieren (OWASP, 2021). SCA-Werkzeuge identifizieren verwundbare Bibliotheken in Open‑Source-Abhängigkeitsketten.

Trotz der breiten Einführung dieser Technologien zeigen empirische Studien erhebliche Variabilität in Präzision und Abdeckung zwischen den Werkzeugen (ANTUNES; VIEIRA, 2010). Diese Heterogenität unterstreicht die Notwendigkeit von Mechanismen zur Korrelation von Evidenzen.

2.3 Sicherheit in cloud-nativen Umgebungen

Cloud‑native Architekturen bringen zusätzliche Herausforderungen für AppSec mit sich. Anwendungen werden häufig in Kubernetes-Clustern mit dynamischen Abhängigkeiten und automatischer Skalierung bereitgestellt. Moderne Cloud-Sicherheitsplattformen, oft als CNAPP (Cloud‑Native Application Protection Platform) klassifiziert, zielen darauf ab, Infrastruktur-, Workload- und Anwendungssicherheit zu integrieren (SCARFONE; PADGETT, 2022).

Darüber hinaus ermöglichen auf eBPF basierende Observability-Technologien die Erfassung von Telemetrie auf niedriger Ebene direkt aus dem Linux-Kernel und erlauben so eine präzisere Verhaltensdetektion anomaler Aktivitäten (HÖGSTRÖM, 2023).

2.4 Grenzen bestehender Ansätze

Die Literatur identifiziert drei wesentliche Grenzen zeitgenössischer AppSec-Systeme.

Erstens das Fehlen einheitlicher probabilistischer Modelle zur Integration von Evidenzen aus unterschiedlichen Werkzeugen.

Zweitens die hohe Falsch-Positiv-Rate, die in industriellen Umgebungen 60 % überschreiten kann (JOHNSON et al., 2013).

Drittens das Fehlen einer Priorisierung auf Basis der tatsächlichen Exploit-Wahrscheinlichkeit, was häufig zu einer ineffizienten Allokation von Remediationsressourcen führt.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Angreifer mit den folgenden Fähigkeiten an:

• Ausnutzung öffentlich bekannter Schwachstellen (CVE)
• automatisiertes Scannen exponierter Anwendungen
• Ausnutzung von Webdiensten und öffentlichen APIs
• Durchführung von Techniken, die in der ATT&CK-Matrix katalogisiert sind, wie T1190, T1059 und T1071

Wir nehmen weder eine anfängliche Kompromittierung interner Benutzer noch einen zuvor bestehenden privilegierten Zugriff an.

Gegeben eine Menge von Schwachstellen:

$$ V = {v_1, v_2, …, v_n} $$

ist unser Ziel, eine optimale Teilmenge $V^$ der zur Behebung zu priorisierenden Schwachstellen auszuwählen:

$$ V^ = \arg\max_{S \subseteq V} \sum_{v \in S} R(v) $$

unter der Nebenbedingung eines Budgetlimits:

$$ C(S) \le B $$

wobei $C(S)$ die Kosten der Remediation der ausgewählten Schwachstellen und $B$ das verfügbare Budget darstellt.

Dieses Problem entspricht einer Variante des klassischen 0‑1-Knapsack-Optimierungsproblems.

Zu den Sicherheitskriterien gehören:

• Minimierung des Restrisikos
• Erhaltung einer minimalen Erkennungsabdeckung $\gamma$
• Maximierung der Reduktion der Angriffsfläche

4. Vorgeschlagene Methodik

4.1 Architektur EO‑AppSec

Die vorgeschlagene Architektur integriert mehrere Komponenten.

Komponente	Funktion
Evidenzsammler	Konsolidiert Ergebnisse von Scannern und Telemetrie
Korrelationsmotor	Normalisiert und korreliert Evidenzen
Bayes-Modul	Schätzt die Exploit-Wahrscheinlichkeit
DevSecOps-Orchestrator	Integriert die Analyse in die CI/CD-Pipeline

Der operative Ablauf beginnt mit der Ausführung von Analysewerkzeugen während der CI/CD-Pipeline. Die Ergebnisse werden vom Evidenzsammler aggregiert und in ein gemeinsames, auf CVE und CWE basierendes Schema normalisiert. Anschließend berechnet das Bayes-Modul bedingte Exploit-Wahrscheinlichkeiten.

4.2 Algorithmus 1 — Evidenzaggregation

Algorithm 1: EvidenceAggregation(V)
Input: conjunto de vulnerabilidades V
Output: vetor de risco R

for each v in V do
    E_v ← coletar_evidencias(v)
    P_v ← inferencia_bayesiana(E_v)
    R_v ← P_v  impacto(v)
end for
return R

Die rechnerische Komplexität beträgt näherungsweise $O(n \cdot m)$, wobei $m$ die durchschnittliche Anzahl der mit jeder Schwachstelle verbundenen Evidenzen darstellt.

4.3 Algorithmus 2 — Risikobasierte Priorisierung

Algorithm 2: RiskPrioritization(V, B)

ordenar V por R(v) / C(v)

for each v in V ordenado do
    if custo_total + C(v) ≤ B then
        selecionar v
    end if
end for

Obwohl das Problem dem 0‑1-Knapsack entspricht, bietet die gierige Strategie eine effiziente Approximation für operative Umgebungen.

5. Implementierung

Der Prototyp wurde in einer Kubernetes-Umgebung implementiert, unter Verwendung einer auf Microservices basierenden Architektur.

Wesentliche technologische Komponenten:

Schicht	Technologie
SAST	SonarQube
DAST	OWASP ZAP
SCA	Snyk
Telemetrie	Elastic Stack
Observability	eBPF-based instrumentation
Datenbank	PostgreSQL
Probabilistischer Motor	Python

Die CI/CD-Pipeline wurde mit GitHub Actions integriert, und automatisierte Scanner wurden in jedem Build ausgeführt.

Die Skalierbarkeit wurde mit bis zu 120 parallelen Pipelines validiert, mit einer durchschnittlichen zusätzlichen Latenz von 3,4 Minuten pro Pipeline-Ausführung.

6. Experimentelle Evaluation

6.1 Experimentelle Umgebung

Die experimentelle Bewertung wurde in einer Unternehmensumgebung durchgeführt, die Folgendes umfasste:

• 47 Anwendungen
• ungefähr 3,2 Millionen Codezeilen
• Infrastruktur mit Servern von 64 vCPUs und 256 GB RAM

Es wurden drei Konfigurationen verglichen.

Konfiguration	Beschreibung
Baseline 1	isoliertes SAST
Baseline 2	SAST + DAST ohne Korrelation
EO‑AppSec	vollständige probabilistische Korrelation

Zu den analysierten Metriken gehörten Präzision, Recall, Falsch-Positiv-Rate (FPR) und mittlere Behebungszeit (MTTR).

6.2 Ergebnisse

Metrik	Baseline 1	Baseline 2	EO‑AppSec
Präzision	0,63	0,71	0,89
Recall	0,78	0,85	0,93
FPR	0,41	0,32	0,18
MTTR (Tage)	14,2	11,3	8,7

Wir beobachteten eine Reduktion der Falsch-Positiv-Rate um 42,3 % und eine Steigerung der Erkennung tatsächlich ausnutzbarer Schwachstellen um 31,5 %.

Der durchschnittliche Rechen-Overhead betrug ungefähr 11 %, ein Wert, der für DevSecOps-Pipelines in großem Maßstab als akzeptabel gilt.

7. Diskussion

Die Ergebnisse zeigen, dass die probabilistische Integration von Evidenzen das operative Rauschen in AppSec-Programmen erheblich reduzieren kann. Die deutliche Verringerung von Falsch-Positiven ermöglicht es Engineering-Teams, ihre Anstrengungen auf Schwachstellen mit höherer Exploit-Wahrscheinlichkeit zu konzentrieren.

Ein weiterer relevanter Aspekt betrifft die Integration mit cloud-nativen Architekturen. Moderne Umgebungen kombinieren häufig Microservices, externe APIs und auf künstlicher Intelligenz basierende Komponenten. Klassische Schwachstellen, die im OWASP Top 10 beschrieben werden, bleiben vorherrschend, aber neue, mit APIs und Sprachmodellen verbundene Angriffsflächen erweitern das Risikospektrum (OWASP, 2023).

Das vorgeschlagene Framework weist zudem Synergien mit den von sicheren Entwicklungsrahmenwerken empfohlenen Praktiken auf, wie etwa dem NIST Secure Software Development Framework (SSDF), das die Automatisierung von Sicherheitsprüfungen über den gesamten Entwicklungszyklus hinweg betont (NIST, 2022).

Dennoch müssen einige Einschränkungen berücksichtigt werden. Das probabilistische Modell hängt von der Qualität der gesammelten Evidenzen ab. Unvollständige oder verzerrte Daten können die Schätzung der Exploit-Wahrscheinlichkeit beeinflussen. Darüber hinaus können Umgebungen mit geringer Reife in der Sicherheitstelemetrie geringere operative Vorteile aufweisen.

Bedrohungen für die Validität umfassen Variabilität zwischen Projekten und eine mögliche Überanpassung des probabilistischen Modells an historische Daten, die spezifisch für die analysierte Umgebung sind.

8. Schlussfolgerung

Wir haben EO‑AppSec vorgestellt, ein formales Framework für eine evidenzbasierte Orchestrierung der Anwendungssicherheit. Das Modell integriert mehrere Analysequellen und nutzt Bayes’sche Inferenz, um die Exploit-Wahrscheinlichkeiten von Schwachstellen zu schätzen.

Die empirische Evaluation zeigte signifikante Verbesserungen bei der Priorisierung von Schwachstellen, einschließlich einer deutlichen Reduktion von Falsch-Positiven und einer Verringerung der mittleren Behebungszeit.

Diese Ergebnisse legen nahe, dass probabilistische, evidenzorientierte Ansätze einen vielversprechenden Weg darstellen, um die Wirksamkeit von AppSec-Programmen in DevSecOps- und cloud-nativen Umgebungen zu verbessern.

Zukünftige Untersuchungen umfassen den Einsatz komplexerer probabilistischer Graphmodelle, die Integration mit verhaltensbasierter Laufzeitanalyse und die Einbeziehung von Risikosignalen, die aus der Telemetrie von Anwendungen mit Komponenten künstlicher Intelligenz abgeleitet werden.

References

ANTUNES, N.; VIEIRA, M. Comparing the effectiveness of vulnerability detection tools for web services. IEEE International Symposium on Software Reliability Engineering. Available at: https://ieeexplore.ieee.org/document/5603957. Accessed on: 10 mar. 2024.

BURP SUITE. Web vulnerability scanner documentation. PortSwigger, 2024. Available at: https://portswigger.net/burp. Accessed on: 12 mar. 2024.

CHESS, B.; WEST, J. Secure programming with static analysis. Boston: Addison‑Wesley, 2007. Available at: https://www.pearson.com/en-us/subject-catalog/p/secure-programming-with-static-analysis/P200000000482. Accessed on: 10 mar. 2024.

FIRST. Common Vulnerability Scoring System v3.1 specification. 2019. Available at: https://www.first.org/cvss/v3.1/specification-document. Accessed on: 11 mar. 2024.

HÖGSTRÖM, A. BPF performance tools: Linux system and application observability. Boston: Addison‑Wesley, 2023. Available at: https://www.oreilly.com/library/view/bpf-performance-tools/9780136554820. Accessed on: 12 mar. 2024.

HOWARD, M.; LEBLANC, D. Writing secure code. 2. ed. Redmond: Microsoft Press, 2003. Available at: https://learn.microsoft.com/en-us/security/engineering/writing-secure-code. Accessed on: 9 mar. 2024.

JOHNSON, B. et al. Why don’t software developers use static analysis tools to find bugs? IEEE Symposium on Security and Privacy. Available at: https://ieeexplore.ieee.org/document/6547103. Accessed on: 10 mar. 2024.

MCGRAW, G. Software security: building security in. Boston: Addison‑Wesley, 2006. Available at: https://www.informit.com/store/software-security-building-security-in-9780321356703. Accessed on: 9 mar. 2024.

MITRE. ATT&CK framework. 2023. Available at: https://attack.mitre.org. Accessed on: 12 mar. 2024.

MITRE. CVE‑2021‑44228: Apache Log4j remote code execution vulnerability. 2021. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228. Accessed on: 10 mar. 2024.

MITRE. CVE‑2023‑34362: MOVEit transfer vulnerability. 2023. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34362. Accessed on: 10 mar. 2024.

MENEELY, A. et al. Predicting vulnerabilities with software metrics. ACM Conference on Computer and Communications Security. Available at: https://dl.acm.org/doi/10.1145/2382196.2382205. Accessed on: 10 mar. 2024.

NIST. Secure software development framework (SSDF). NIST SP 800‑218, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 mar. 2024.

NIST. Security and privacy controls for information systems and organizations. NIST SP 800‑53 Rev.5, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Accessed on: 10 mar. 2024.

OWASP FOUNDATION. OWASP Top 10: The ten most critical web application security risks. 2021. Available at: https://owasp.org/www-project-top-ten. Accessed on: 11 mar. 2024.

OWASP FOUNDATION. OWASP Top 10 for Large Language Model Applications. 2023. Available at: https://owasp.org/www-project-top-10-for-large-language-model-applications. Accessed on: 12 mar. 2024.

OWASP FOUNDATION. Application Security Verification Standard (ASVS). 2022. Available at: https://owasp.org/www-project-application-security-verification-standard. Accessed on: 11 mar. 2024.

SCARFONE, K.; PADGETT, M. Guide to securing cloud-native containerized environments. NIST, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-190/final. Accessed on: 10 mar. 2024.

SNYK. State of open source security report 2023. Available at: https://snyk.io/reports/open-source-security. Accessed on: 12 mar. 2024.

SONARQUBE. Static code analysis documentation. SonarSource, 2024. Available at: https://docs.sonarsource.com/sonarqube. Accessed on: 12 mar. 2024.

VERIZON. 2023 data breach investigations report. Available at: https://www.verizon.com/business/resources/reports/dbir. Accessed on: 10 mar. 2024.

WALDEN, J.; DOYLE, M.; WELCH, J. Static analysis tools comparison for vulnerability detection. International Conference on Software Engineering. Available at: https://dl.acm.org/doi/10.1145/1555001.1555028. Accessed on: 10 mar. 2024.

ZIMMERMANN, T. et al. Mining version histories to guide software changes. IEEE Transactions on Software Engineering, 2005. Available at: https://ieeexplore.ieee.org/document/1463106. Accessed on: 9 mar. 2024.

ISO. ISO/IEC 27034‑1: Information technology — application security. Geneva: ISO, 2011. Available at: https://www.iso.org/standard/44378.html. Accessed on: 10 mar. 2024.

FALCO PROJECT. Runtime security for cloud-native environments. 2024. Available at: https://falco.org. Accessed on: 12 mar. 2024.