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 modernen Cyber-Resilienz geworden. 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 Open-Source-Abhängigkeitsketten führen systemische Risiken ein. Der mit der Schwachstelle Log4Shell (CVE‑2021‑44228) verbundene Vorfall machte deutlich, wie eine einzige weit verbreitete Bibliothek Millionen von Systemen gleichzeitig beeinträchtigen kann (MITRE, 2021). Darüber hinaus bleiben in Webanwendungen ausgenutzte Schwachstellen ein dominanter Vektor für Eindringversuche, häufig in Verbindung 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 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, wenn 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 zählen statische Codeanalyse (SAST), dynamische Analyse (DAST) und Software Composition Analysis (SCA). Obwohl sie weit verbreitet sind, erzeugen 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 Fehlalarmraten und erschwert die Bestimmung, welche Schwachstellen ein reales Risiko darstellen.

Darüber hinaus bringt das jüngste Wachstum von Anwendungen, die Modelle der künstlichen Intelligenz und APIs auf Basis großer Sprachmodelle (LLMs) integrieren, neue Angriffsflächen mit sich, wie Prompt Injection und die unbeabsichtigte Offenlegung sensibler Daten. Auch wenn diese Bedrohungen klassische Schwachstellen nicht ersetzen, erhöhen sie doch 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: Welche operativen Auswirkungen 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 auf 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 probabilistischen Korrelationsmechanismus 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 Behebungsprozessen.

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 (beispielsweise eine CWE-Klassifikation), $s$ die Grundschwere 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 Exploit-Wahrscheinlichkeit unter den beobachteten Evidenzen und $I(v)$ die potenzielle Auswirkung der Ausnutzung darstellt.

Unter Verwendung bayesscher 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	Werkzeugbeispiele
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 Code-Muster (CHESS; WEST, 2007). DAST-Werkzeuge hingegen 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 weit verbreiteten Nutzung dieser Technologien zeigen empirische Studien eine erhebliche Variabilität 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‑nativen Umgebungen

Cloud‑native Architekturen bringen zusätzliche Herausforderungen für AppSec mit sich. Anwendungen werden häufig in Kubernetes-Clustern bereitgestellt, mit dynamischen Abhängigkeiten und automatischer Skalierung. Moderne Cloud-Sicherheitsplattformen, häufig 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 wesentliche Einschränkungen zeitgenössischer AppSec-Systeme.

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

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

Drittens das Fehlen einer Priorisierung auf Basis der tatsächlichen Exploit-Wahrscheinlichkeit, was häufig zu einer ineffizienten Zuweisung von Behebungsressourcen 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 einen 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 einer Budgetrestriktion:

$$ C(S) \le B $$

wobei $C(S)$ die Behebungskosten 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 zählen:

• 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
Bayessches 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. Das bayessche Modul berechnet dann 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 Rechenkomplexität beträgt ungefähr $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 äquivalent zum 0‑1-Knapsack ist, bietet die gierige Strategie in operativen Umgebungen eine effiziente Approximation.

5. Implementierung

Der Prototyp wurde in einer Kubernetes-Umgebung implementiert und verwendet eine auf Mikroservices basierende Architektur.

Wesentliche technologische Komponenten:

Ebene	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 bei jedem Build ausgeführt.

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 mit folgenden Merkmalen durchgeführt:

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

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 einen Anstieg der Erkennung tatsächlich ausnutzbarer Schwachstellen um 31,5 %.

Der durchschnittliche Rechen-Overhead betrug ungefähr 11 %, ein Wert, der für großskalige DevSecOps-Pipelines 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 Fehlalarmen ermöglicht es Engineering-Teams, ihre Anstrengungen auf Schwachstellen mit höherer Exploit-Wahrscheinlichkeit zu konzentrieren.

Ein weiterer relevanter Aspekt betrifft die Integration in cloud‑native Architekturen. Moderne Umgebungen kombinieren häufig Mikroservices, externe APIs und auf künstlicher Intelligenz basierende Komponenten. Klassische Schwachstellen, die im OWASP Top 10 beschrieben sind, bleiben vorherrschend, doch neue Angriffsflächen im Zusammenhang mit APIs und Sprachmodellen erweitern das Risikospektrum (OWASP, 2023).

Das vorgeschlagene Framework zeigt auch Synergien mit den von sicheren Entwicklungsframeworks empfohlenen Praktiken, wie dem NIST Secure Software Development Framework (SSDF), das die Automatisierung von Sicherheitsprüfungen entlang des Entwicklungszyklus 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 Exploit-Wahrscheinlichkeit beeinflussen. Darüber hinaus können Umgebungen mit geringem Reifegrad 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 historische Daten der analysierten Umgebung.

8. Schlussfolgerung

Wir haben EO‑AppSec vorgestellt, ein formales Framework zur evidenzbasierten Orchestrierung der Anwendungssicherheit. Das Modell integriert mehrere Analysequellen und verwendet bayessche Inferenz, um Exploit-Wahrscheinlichkeiten von Schwachstellen zu schätzen.

Die empirische Evaluation zeigte signifikante Verbesserungen bei der Priorisierung von Schwachstellen, einschließlich einer deutlichen Reduktion von Fehlalarmen und einer Verringerung der durchschnittlichen Behebungszeit.

Diese Ergebnisse legen nahe, dass evidenzorientierte probabilistische 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 graphischer Modelle, die Integration von Verhaltensanalyse zur Laufzeit sowie 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.