TITEL: Evidenzorientierte AppSec: Ein formaler und skalierbarer Rahmen für die Orchestrierung der Anwendungssicherheit auf Basis von Threat Modeling und kontinuierlicher hybrider Analyse

1. Einleitung

Die Sicherheit von Anwendungen (Application Security — AppSec) ist zu einem der Grundpfeiler der heutigen Cyber-Resilienz geworden. Der Übergang zu verteilten Architekturen, cloud‑nativen Plattformen, öffentlichen APIs und DevSecOps-Pipelines hat die Angriffsfläche moderner Systeme erheblich vergrößert. Empirische Berichte zeigen, dass ausnutzbare Schwachstellen in Anwendungen nach wie vor zu den Hauptursachen von Sicherheitsvorfällen zählen (VERIZON, 2023).

Insbesondere Open-Source-Abhängigkeitsketten führen systemische Risiken ein. Der mit der Schwachstelle Log4Shell (CVE‑2021‑44228) verbundene Vorfall machte deutlich, wie eine einzelne, weit verbreitete Bibliothek Millionen von Systemen gleichzeitig beeinflussen kann (MITRE, 2021). Darüber hinaus bleiben in Webanwendungen ausgenutzte Schwachstellen ein dominanter Vektor für Intrusionen, häufig verbunden mit im MITRE-ATT&CK-Matrix katalogisierten Techniken 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 mikroservicebasierten Architekturen wächst die Anzahl der Kanten schnell, sobald Dienste integriert werden, wodurch die Angriffsfläche proportional erweitert wird. Während die strukturelle Komplexität ungefähr 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-Analyse (SCA). Obwohl sie weit verbreitet sind, liefern diese Ansätze 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 False-Positive-Raten und erschwert die Bestimmung, welche Schwachstellen ein reales Risiko darstellen.

Darüber hinaus führt das jüngste Wachstum von Anwendungen, die Modelle künstlicher Intelligenz und APIs auf Basis großer Sprachmodelle (LLMs) einbinden, zu neuen Angriffsflächen wie Prompt Injection und unbeabsichtigter Exposition sensibler Daten. Obwohl diese Bedrohungen klassische Schwachstellen nicht ersetzen, verstärken sie die Notwendigkeit integrierter und evidenzorientierter Analysemethoden (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, False Positives 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 bayesscher Inferenz und kontextualisierter CVSS-Metriken.

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

Drittens evaluieren wir das System empirisch in industriellem 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 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 bedingte Wahrscheinlichkeit einer Ausnutzung angesichts der beobachteten Evidenzen und $I(v)$ die potenzielle Auswirkung der Ausnutzung repräsentiert.

Unter Verwendung bayesscher Inferenz kann die 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 Exploit-Historie von Schwachstellen.

2.2 Werkzeuge und Detektionsansätze

Techniken zur Erkennung von Schwachstellen lassen sich in vier Hauptkategorien einteilen.

Ansatz	Merkmale	Beispiele für Werkzeuge
SAST	Quellcodeanalyse ohne Ausführung	SonarQube, Coverity
DAST	Dynamische Tests in Laufzeitumgebungen	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 Adoption 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 führen zusätzliche Herausforderungen für AppSec ein. Anwendungen werden häufig in Kubernetes-Clustern bereitgestellt, mit dynamischen Abhängigkeiten und automatischer Skalierung. Moderne Sicherheitsplattformen für die Cloud, oft als CNAPP (Cloud-Native Application Protection Platform) klassifiziert, zielen darauf ab, die Sicherheit von Infrastruktur, Workloads und Anwendungen 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 damit eine präzisere verhaltensbasierte Erkennung anomaler Aktivitäten (HÖGSTRÖM, 2023).

2.4 Einschränkungen bestehender Ansätze

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

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

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

Drittens das Fehlen einer Priorisierung auf Grundlage der tatsächlichen Wahrscheinlichkeit einer Ausnutzung, 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
• Ausführung von in der ATT&CK-Matrix katalogisierten Techniken wie T1190, T1059 und T1071

Wir nehmen weder eine anfängliche Kompromittierung interner Benutzer noch vorherigen privilegierten Zugriff an.

Gegeben eine Menge von Schwachstellen:

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

ist unser Ziel, eine optimale Teilmenge $V^$ von Schwachstellen zur Priorisierung für die Behebung auszuwählen:

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

unter der Nebenbedingung eines Budgets:

$$ C(S) \le B $$

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

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

Zu den Sicherheitskriterien gehören:

• Minimierung des Restrisikos
• Erhaltung einer minimalen Detektionsabdeckung $\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
Bayesianisches Modul	Schätzt die Wahrscheinlichkeit einer Ausnutzung
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. Anschließend berechnet das bayesianische Modul bedingte Wahrscheinlichkeiten einer 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 rechnerische Komplexität beträgt ungefähr $O(n \cdot m)$, wobei $m$ die durchschnittliche Anzahl an Evidenzen bezeichnet, die mit jeder Schwachstelle verbunden sind.

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 äquivalent zum 0‑1-Knapsack ist, 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:

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 mithilfe von GitHub Actions integriert, mit automatisierten Scannern, die bei jedem Build ausgeführt wurden.

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

6. Experimentelle Evaluierung

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 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, False-Positive-Rate (FPR) und mittlere Zeit bis zur Behebung (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 False-Positive-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 Reduktion von False Positives ermöglicht es Engineering-Teams, ihre Anstrengungen auf Schwachstellen mit höherer Ausnutzungswahrscheinlichkeit 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, wie sie im OWASP Top 10 beschrieben sind, bleiben vorherrschend, doch neue, mit APIs und Sprachmodellen verbundene Angriffsflächen erweitern das Risikospektrum (OWASP, 2023).

Das vorgeschlagene Framework weist außerdem Synergien mit den von sicheren Entwicklungsframeworks 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 sind einige Einschränkungen zu berücksichtigen. 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 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 die evidenzbasierte Orchestrierung von Anwendungssicherheit. Das Modell integriert mehrere Analysequellen und verwendet bayessche Inferenz zur Schätzung der Ausnutzungswahrscheinlichkeiten von Schwachstellen.

Die empirische Evaluierung zeigte signifikante Verbesserungen bei der Priorisierung von Schwachstellen, einschließlich einer deutlichen Reduktion von False Positives und einer Verringerung der mittleren Zeit bis zur Behebung.

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.

Referenzen

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.