TITEL: Evidenzorientierte AppSec: Ein formales und skalierbares Framework zur Orchestrierung der Anwendungssicherheit auf Basis von Bedrohungsmodellierung und kontinuierlicher hybrider Analyse

1. Einleitung

Die Sicherheit von Anwendungen (Application Security — AppSec) ist zu einer der Säulen der gegenwärtigen Cyberresilienz geworden. Der Übergang zu verteilten Architekturen, cloud-native 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 Open-Source-Abhängigkeitsketten führen systemische Risiken ein. Der mit der Log4Shell-Schwachstelle (CVE‑2021‑44228) verbundene Vorfall machte deutlich, wie eine einzelne weit verbreitete Bibliothek Millionen von Systemen gleichzeitig beeinträchtigen kann (MITRE, 2021). Darüber hinaus bleiben in Webanwendungen ausgenutzte Schwachstellen ein dominanter Einfallsvektor, der häufig mit Techniken in der MITRE-ATT&CK-Matrix in Verbindung steht, wie T1190 (Exploit Public‑Facing Application) und T1059 (Command and Scripting Interpreter) (MITRE, 2023).

Die Struktur moderner Anwendungen kann als gerichteter Graph formalisiert werden:

$$ G = (V, E) $$

wobei $V$ Softwarekomponenten (Dienste, Bibliotheken oder APIs) und $E$ Abhängigkeiten oder Datenflüsse zwischen diesen Komponenten repräsentiert. In mikroservicebasierten Architekturen wächst die Anzahl der Kanten rasch, sobald Dienste integriert werden, wodurch die Angriffsfläche proportional zunimmt. 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 und operativ schwer priorisierbare Ergebnisse (ANTUNES; VIEIRA, 2010). Das Fehlen formaler Mechanismen zur Korrelation von Evidenzen aus diesen Werkzeugen führt zu hohen Fehlalarmraten und erschwert die Bestimmung, welche Schwachstellen ein reales Risiko darstellen.

Darüber hinaus bringt das jüngste Wachstum von Anwendungen, die Modelle künstlicher Intelligenz und APIs auf Basis großer Sprachmodelle (LLMs) integrieren, neue Angriffsflächen mit sich, etwa Prompt Injection und die unbeabsichtigte Offenlegung sensibler Daten. Obwohl diese Bedrohungen klassische Schwachstellen nicht ersetzen, erhöhen sie die Notwendigkeit integrierter, evidenzorientierter Analysemechanismen (OWASP, 2023).

Vor diesem Hintergrund formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das Risiko von Anwendungsschwachstellen formal modellieren, unter Berücksichtigung heterogener Evidenzen aus mehreren Analysequellen?

RQ2: Ist es möglich, Fehlalarme zu reduzieren und die Priorisierung von Schwachstellen zu verbessern, ohne die Detektionsabdeckung 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 drei.

Erstens definieren wir formal eine bedingte Risikofunktion auf der Grundlage bayesianischer Inferenz und kontextualisierter CVSS-Metriken.

Zweitens schlagen wir die Architektur EO‑AppSec vor, die Ergebnisse von 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 (z. B. eine CWE-Klassifikation), $s$ die Basis-Schwere 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 Wahrscheinlichkeit einer Ausnutzung unter den beobachteten Evidenzen und $I(v)$ den potenziellen Einfluss der Ausnutzung darstellt.

Unter Verwendung bayesianischer Inferenz kann die a-posteriori-Wahrscheinlichkeit einer Ausnutzung dynamisch aktualisiert werden:

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

Dieses Modell ermöglicht die Kombination mehrerer Evidenzquellen, einschließlich Scanner-Ergebnissen, Laufzeitdaten und der Historie von Schwachstellenausnutzungen.

2.2 Erkennungswerkzeuge und -ansätze

Techniken zur Schwachstellenerkennung können in vier Hauptkategorien eingeteilt werden.

Ansatz	Merkmale	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 Codemuster (CHESS; WEST, 2007). DAST-Werkzeuge führen hingegen 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 Unterschiede in Präzision und Abdeckung zwischen den Werkzeugen (ANTUNES; VIEIRA, 2010). Diese Heterogenität unterstreicht die Notwendigkeit von Mechanismen zur Evidenzkorrelation.

2.3 Sicherheit in cloud-native 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 das Sammeln von Telemetrie auf niedriger Ebene direkt aus dem Linux-Kernel und damit eine präzisere verhaltensbasierte Erkennung anomaler Aktivitäten (HÖGSTRÖM, 2023).

2.4 Grenzen bestehender Ansätze

Die Literatur identifiziert drei Hauptbeschränkungen in zeitgenössischen AppSec-Systemen.

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

Zweitens die hohe Fehlalarmrate, die in industriellen Umgebungen 60 % übersteigen kann (JOHNSON et al., 2013).

Drittens das Fehlen einer Priorisierung auf Basis der tatsächlichen Ausnutzungswahrscheinlichkeit, 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)
• automatisierte Erkundung exponierter Anwendungen
• Ausnutzung von Webdiensten und öffentlichen APIs
• Ausfü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 bereits vorhandenen privilegierten Zugriff an.

Gegeben eine Menge von Schwachstellen:

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

ist es unser Ziel, eine optimale Teilmenge $V^$ von Schwachstellen auszuwählen, die für die Behebung priorisiert werden sollen:

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

unter einer Budgetrestriktion:

$$ C(S) \le B $$

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

Dieses Problem ist äquivalent zu einer Variante des klassischen 0‑1-Knapsack-Optimierungsproblems.

Sicherheitskriterien umfassen:

• Minimierung des Restrisikos
• Wahrung einer minimalen Detektionsabdeckung $\gamma$
• Maximierung der Reduktion der Angriffsfläche

4. Vorgeschlagene Methodik

4.1 EO‑AppSec-Architektur

Die vorgeschlagene Architektur integriert mehrere Komponenten.

Komponente	Funktion
Evidenzsammler	Konsolidiert Ergebnisse von Scannern und Telemetrie
Korrelationsmotor	Normalisiert und korreliert Evidenzen
Bayessches Modul	Schätzt die Ausnutzungswahrscheinlichkeit
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 Schema auf Grundlage von CVE und CWE normalisiert. Das bayessche Modul berechnet anschließend bedingte Wahrscheinlichkeiten für eine Ausnutzung.

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 Rechenkomplexitä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 mikroservicebasierten Architektur.

Wesentliche technologische Komponenten:

Ebene	Technologie
SAST	SonarQube
DAST	OWASP ZAP
SCA	Snyk
Telemetrie	Elastic Stack
Observability	eBPF-based instrumentation
Datenbank	PostgreSQL
Probabilistische Engine	Python

Die CI/CD-Pipeline wurde mittels GitHub Actions integriert, wobei automatisierte Scanner bei jedem Build ausgeführt wurden.

Die Skalierbarkeit wurde mit bis zu 120 gleichzeitigen 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 Evaluation wurde in einer Unternehmensumgebung durchgeführt, die Folgendes umfasste:

• 47 Anwendungen
• ungefähr 3,2 Millionen Codezeilen
• Infrastruktur mit 64-vCPU-Servern 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, Fehlalarmrate (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 Fehlalarmrate 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 im großen Maßstab als akzeptabel angesehen wird.

7. Diskussion

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

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

Das vorgeschlagene Framework steht auch in Synergie zu empfohlenen Praktiken von Frameworks für sichere Softwareentwicklung, wie 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 Ausnutzungswahrscheinlichkeit beeinflussen. Darüber hinaus können Umgebungen mit geringer Reife in der Sicherheits-Telemetrie einen geringeren operativen Nutzen aufweisen.

Bedrohungen für die Validität umfassen Variabilität zwischen Projekten und eine mögliche Überanpassung des probabilistischen Modells an spezifische historische Daten der analysierten Umgebung.

8. Schlussfolgerung

Wir haben EO‑AppSec vorgestellt, ein formales Framework für eine evidenzbasierte Orchestrierung der Anwendungssicherheit. Das Modell integriert mehrere Analysequellen und verwendet bayesianische Inferenz zur Schätzung der Ausnutzungswahrscheinlichkeit von Schwachstellen.

Die empirische Evaluation zeigte signifikante Verbesserungen bei der Priorisierung von Schwachstellen, einschließlich einer deutlichen Reduktion von Fehlalarmen 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-native-Umgebungen zu verbessern.

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

Literaturverzeichnis

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.