Paper Files / AppSec
TITEL: Eine quantitative und operative Architektur für Application Security auf Basis der Integration von SAST, DAST, SCA und Threat Intelligence im DevSecOps-Zyklus
TITEL: Eine quantitative und operative Architektur für Application Security auf Basis der Integration von SAST, DAST, SCA und Threat Intelligence im DevSecOps-Zyklus ABSTRAKT: Die Anwendungssicherheit (Application Security – AppSec) ist zu einer zentralen Komponente des Risikomanagements in modernen digitalen Umgebungen geworden. Die zunehmende Verbreitung von auf Microservices basierenden Architekturen, exponierten APIs, Containern und Continuous-Delivery-Pipelines hat die Angriffsfläche von Organisationen erheblich vergrößert. Obwohl verschiedene Tools zur Sicherheitsanalyse weithin verfügbar sind, haben viele Organisationen weiterhin Schwierigkeiten, Schwachstellen anhand des tatsächlichen Ausnutzungsrisikos zu priorisieren. Werkzeuge für statische Analyse (SAST), dynamische Analyse (DAST) und Software-Composition-Analysis (SCA) erzeugen häufig große Mengen an Findings, von denen viele nur geringe operative Auswirkungen oder eine hohe False-Positive-Rate aufweisen. Diese Arbeit schlägt eine quantitative Architektur für risikoorientierte AppSec-Programme vor, die Ergebnisse aus SAST, DAST und SCA mit externen Threat-Intelligence-Quellen integriert. Wir präsentieren ein formales Priorisierungsmodell auf der Grundlage einer Risikofunktion, die CVSS-Scores, Hinweise auf öffentlich verfügbare Exploits, den Kontext der Anwendungs-Exposition und die Zuordnung zu Techniken des MITRE-ATT&CK-Frameworks kombiniert. Die vorgeschlagene Architektur ist in DevSecOps-Pipelines integriert und nutzt Mechanismen zur Korrelation und Normalisierung von Schwachstellen über Management-Plattformen wie DefectDojo. Wir bewerten den Ansatz empirisch anhand eines Satzes von 42 realen Anwendungen, die in Java, Python und Node.js entwickelt wurden. Die Ergebnisse zeigen eine signifikante Reduktion doppelter Schwachstellen, eine Verringerung der False-Positive-Rate und eine deutliche Verbesserung der durchschnittlichen Zeit bis zur Behebung (MTTR). Es wurde eine Reduktion des MTTR um 63 % und eine Verringerung des Findings-Volumens um 44,7 % nach der Korrelation zwischen Scannern beobachtet. Darüber hinaus zeigen wir, dass die Einbeziehung von Threat Intelligence — einschließlich des Vorhandenseins öffentlicher Exploits und der Beobachtung adversarialer Aktivitäten — die Priorisierung von Remediations verbessert und Ressourcen auf tatsächlich ausnutzbare Schwachstellen lenkt. Die Ergebnisse legen nahe, dass risikoorientierte AppSec-Programme, wenn sie in den DevSecOps-Zyklus integriert werden, messbare Gewinne bei der Reduzierung der Angriffsfläche und der operativen Effizienz von Sicherheitsteams bieten.
- Einleitung
Die Sicherheit von Anwendungen (Application Security – AppSec) hat sich in modernen Unternehmensumgebungen als einer der wichtigsten Risikovektoren etabliert. Die beschleunigte digitale Transformation, kombiniert mit der Einführung von Architekturen auf Basis von Mikrodiensten, Containern und exponierten APIs, hat die Angriffsfläche von Organisationen erheblich vergrößert. In diesem Kontext sind Webanwendungen und verteilte Dienste zum zentralen Interaktionspunkt zwischen legitimen Nutzern und potenziellen Angreifern geworden.
Empirische Berichte belegen die zentrale Bedeutung dieses Vektors. Der Verizon Data Breach Investigations Report zeigt, dass Schwachstellen in Webanwendungen weiterhin zu den häufigsten Ursachen von Sicherheitsvorfällen gehören (VERIZON, 2023). Darüber hinaus bleiben Angriffe, die bekannte Schwachstellen in internetexponierten Anwendungen ausnutzen, eine der dominierenden Intrusionstechniken (MITRE, 2023).
Jüngste Vorfälle unterstreichen die Kritikalität der Softwareabhängigkeitskette. Die Log4Shell-Schwachstelle (CVE‑2021‑44228) beispielsweise zeigte, wie weit verbreitet eingesetzte Bibliotheken systemische Risiken in großem Maßstab einführen können (NIST, 2023). Die Ausnutzung dieser Schwachstelle ermöglichte die Ausführung von Remotecode durch JNDI-Injektion und betraf Millionen von Systemen in verschiedenen Wirtschaftssektoren.
Trotz der weit verbreiteten Nutzung automatisierter Sicherheitsanalysetools haben viele Organisationen Schwierigkeiten bei der effektiven Priorisierung von Schwachstellen. Werkzeuge zur statischen Analyse erzeugen häufig eine große Anzahl von Befunden mit hoher False-Positive-Rate, während Ansätze, die ausschließlich auf dynamischer Analyse beruhen, latente Schwachstellen im Quellcode übersehen können.
Vor diesem Hintergrund untersuchen wir das folgende Forschungsproblem: Wie lässt sich ein AppSec-Programm strukturieren, das das tatsächliche ausnutzbare Risiko wirksam reduziert und nicht nur die nominale Anzahl identifizierter Schwachstellen.
Wir formulieren die folgenden Forschungsfragen:
RQ1: Wie lassen sich Ergebnisse aus SAST, DAST und SCA korrelieren, um False Positives zu reduzieren und gleichzeitig die Detektionsabdeckung zu erhalten?
RQ2: Wie lässt sich das ausnutzbare Risiko von Schwachstellen unter Berücksichtigung aktiver Threat Intelligence quantitativ modellieren?
RQ3: Welchen operativen Einfluss hat diese Integration auf die Reduktion der mittleren Behebungszeit (MTTR)?
Die zentralen Beiträge dieser Arbeit sind:
• Vorschlag einer formalen Risikofunktion zur Priorisierung von Schwachstellen.
• Integrierte, risikoorientierte AppSec-Architektur im DevSecOps-Kontext.
• Experimentelle Evaluation auf Basis realer Produktivanwendungen.
- Hintergrund und verwandte Arbeiten
Tools für Static Application Security Testing (SAST) analysieren den Quellcode ohne Ausführung des Programms und verwenden Datenfluss- und Kontrollflussanalysen, um Schwachstellenmuster zu identifizieren (SCANDARIATO et al., 2013). Weit verbreitete Werkzeuge sind SonarQube, Semgrep und Checkmarx.
Dynamic Application Security Testing (DAST) bewertet laufende Anwendungen, indem adversarielle Interaktionen simuliert werden, um zur Laufzeit ausnutzbare Schwachstellen zu identifizieren. Werkzeuge wie OWASP ZAP und Burp Suite werden in diesem Kontext häufig eingesetzt (OWASP, 2023).
Software Composition Analysis (SCA) konzentriert sich auf die Identifikation von Schwachstellen in Open-Source-Abhängigkeiten. Diese Werkzeuge korrelieren Bibliotheksversionen mit Schwachstellendatenbanken wie der National Vulnerability Database (NVD) (NIST, 2023). Beispiele sind Trivy, Snyk und OWASP Dependency-Check.
Empirische Studien zeigen erhebliche Limitationen statischer Analysewerkzeuge in realen Umgebungen. Johnson et al. (2013) zeigen, dass Entwickler Warnungen aufgrund der geringen Präzision der Werkzeuge häufig ignorieren. Weitere Studien deuten darauf hin, dass nur ein Bruchteil der veröffentlichten Schwachstellen tatsächlich in realen Angriffen ausgenutzt wird (SHARMA; SHARMA, 2020).
Reifegrad-Frameworks wie OWASP SAMM und das NIST Secure Software Development Framework (SSDF) bieten strukturierte Leitlinien für AppSec-Programme, definieren jedoch keine quantitativen Formalisierungen zur Priorisierung von Schwachstellen (OWASP, 2023; NIST, 2022).
In den letzten Jahren ist die Integration von Threat Intelligence in das Schwachstellenmanagement zu einer empfohlenen Praxis geworden. Datenquellen wie Exploit‑DB, CISA Known Exploited Vulnerabilities (KEV) und Threat-Intelligence-Feeds ermöglichen die Identifikation von Schwachstellen mit aktiver Ausnutzung (CISA, 2024).
- Bedrohungsmodell und Problemformalisierung
Wir betrachten einen Angreifer mit den folgenden operativen Fähigkeiten:
• Automatisierte Scans internetexponierter Dienste durchführen.
• Bekannte Schwachstellen mit öffentlich verfügbaren Exploits ausnutzen.
• Mehrere Schwachstellen zu Angriffsketten kombinieren.
Im Kontext von MITRE ATT&CK entsprechen solche Verhaltensweisen Techniken wie Exploit Public‑Facing Application (T1190) und Active Scanning (T1595) (MITRE, 2023).
Wir definieren die Menge der erkannten Schwachstellen als:
$V = {v_1, v_2, …, v_n}$
Für jede Schwachstelle $v$ betrachten wir die folgenden Attribute:
• $C(v)$ — normalisierter CVSS-Wert im Intervall $[0,1]$
• $E(v)$ — Indikator für einen verfügbaren öffentlichen Exploit
• $X(v)$ — Expositionsfaktor der Anwendung
• $T(v)$ — Kritikalität, die der MITRE-ATT&CK-Technik zugeordnet ist
Die Risikofunktion ist definiert als:
$$ R(v) = \alpha C(v) + \beta E(v) + \gamma X(v) + \delta T(v) $$
unter der Nebenbedingung:
$$ \alpha + \beta + \gamma + \delta = 1 $$
Das Priorisierungsproblem besteht darin, die Menge $V$ so zu ordnen, dass die Reduktion des aggregierten Risikos nach der Behebung maximiert wird:
$$ \max \sum_{v \in V_{remediadas}} R(v) $$
Dieses Modell ermöglicht es, neben der traditionellen, allein auf CVSS basierenden Schweregradbewertung auch Kontextinformationen einzubeziehen.
- Vorgeschlagene Methodik
Die vorgeschlagene Architektur besteht aus fünf operativen Schichten, die in die DevSecOps-Pipeline integriert sind:
| Schicht | Funktion |
|---|---|
| Ingestion | Sammlung von SAST-, DAST- und SCA-Ergebnissen |
| Normalisierung | Standardisierung von Schwachstellen auf einer zentralen Plattform |
| Anreicherung | Integration mit Threat-Intelligence-Feeds |
| Priorisierung | Berechnung des quantitativen Risikos |
| Orchestrierung | Automatisierung von Korrekturen über die CI/CD-Pipeline |
Die Plattform DefectDojo wird als Mechanismus zur Aggregation und Deduplication von Befunden verwendet.
Der Priorisierungsalgorithmus ist wie folgt definiert:
Algorithm RiskScore(V)
for each vulnerability v in V:
C = normalize(CVSS(v))
E = exploitPresence(v)
X = exposureLevel(v)
T = mitreCriticality(v)
R[v] = alphaC + betaE + gammaX + deltaT
return sortDescending(R)
Die Rechenkomplexität des Algorithmus beträgt aufgrund des Sortierschritts $O(n \log n)$.
Wir integrieren Scanner direkt in die CI/CD-Pipeline. Ein Ausführungsbeispiel für Semgrep ist unten dargestellt:
semgrep --config auto --json --output semgrep.json
Die dynamische Analyse mit OWASP ZAP kann automatisiert ausgeführt werden:
zap-baseline.py -t https://app.test -J zap-report.json
- Implementierung
Die Architektur wurde in einem Kubernetes-Cluster der Version 1.28 implementiert, bestehend aus sechs Knoten mit jeweils 32 vCPUs und 128 GB Speicher.
Der verwendete Werkzeugkatalog ist nachfolgend dargestellt:
| Kategorie | Werkzeug |
|---|---|
| SAST | Semgrep 1.45, SonarQube 10 |
| DAST | OWASP ZAP 2.14 |
| SCA | Trivy 0.48 |
| Orchestrierung | GitLab CI |
| Verwaltung | DefectDojo 2.25 |
Ein Beispiel einer benutzerdefinierten Semgrep-Regel zur Identifikation unsicherer Deserialisierung in Python ist unten dargestellt:
rules:
- id: insecure-deserialization
pattern: pickle.loads(...)
message: Mögliche unsichere Deserialisierung
languages: [python]
severity: ERROR
- Experimentelle Evaluation
Das Experiment wurde in einem Set von 42 Unternehmensanwendungen durchgeführt.
| Sprache | Anzahl der Anwendungen |
|---|---|
| Java | 18 |
| Python | 14 |
| Node.js | 10 |
Zu Beginn wurden durch die Kombination der drei Scanner 12.842 Schwachstellen identifiziert.
Nach Deduplication und Korrelation zwischen den Werkzeugen reduzierte sich die Gesamtzahl auf 7.103 eindeutige Befunde, was einer Reduktion von 44,7 % entspricht.
Die False-Positive-Rate wurde auf Grundlage der manuellen Analyse einer Stichprobe von 600 Schwachstellen geschätzt.
| Ansatz | False-Positive-Rate |
|---|---|
| Isoliertes SAST | 38% ± 4,2 |
| Vorgeschlagene Architektur | 20% ± 3,1 |
Es wurde außerdem eine signifikante Reduktion der mittleren Behebungszeit beobachtet.
| Metrik | Baseline | Vorgeschlagene Architektur |
|---|---|---|
| MTTR | 18,4 Tage | 6,8 Tage |
Darüber hinaus reduzierten sich Schwachstellen in Abhängigkeiten mit aktiv verfügbarem öffentlichem Exploit nach der risikobasierten Priorisierung deutlich.
| Metrik | Vorher | Nach 60 Tagen |
|---|---|---|
| Ausnutzbare kritische Abhängigkeiten | 312 | 87 |
- Fallstudie
Wir führten eine Fallstudie in einer öffentlich exponierten Finanzanwendung durch.
Während der Analyse identifizierte SAST die Verwendung der Bibliothek Jackson Databind, die für CVE‑2020‑36518 anfällig ist. Das SCA-Werkzeug bestätigte das Vorhandensein der Abhängigkeit zur Laufzeit.
Die Integration mit Intelligence-Feeds zeigte das Vorhandensein eines öffentlichen Proof-of-Concept. Die Risikoberechnung ergab:
$$ R(v) = 0.87 $$
Dieser Wert ordnete die Schwachstelle unter die drei kritischsten des Systems ein, was zur Einspielung des Patches in weniger als 48 Stunden führte.
Ohne risikoorientierte Priorisierung war die Schwachstelle lediglich als „Hoch“ unter mehr als 240 Befunden klassifiziert.
- Diskussion
Die experimentellen Ergebnisse deuten darauf hin, dass die Integration mehrerer Analysetechniken mit Threat Intelligence die Priorisierung von Schwachstellen erheblich verbessert.
Der wichtigste operative Vorteil ist die Reduktion des durch automatisierte Scanner erzeugten Rauschens. Durch die Berücksichtigung des tatsächlichen Ausnutzungskontexts und der Exposition der Anwendung können Teams ihre Anstrengungen auf Schwachstellen mit höherer Ausnutzungswahrscheinlichkeit konzentrieren.
Allerdings weist der Ansatz auch Limitationen auf. Die Qualität der Priorisierung hängt von der Verfügbarkeit und Aktualität der Threat-Intelligence-Feeds ab. Zudem erhalten Zero-Day-Schwachstellen, die nicht in öffentlichen Datenbanken enthalten sind, möglicherweise keine angemessene Priorisierung.
Die Integration mit eBPF-basiertem Runtime-Monitoring und Verhaltensdetektionstools kann den Ansatz ergänzen, indem sie Sichtbarkeit hinsichtlich aktiver Ausnutzung in der Produktion bietet (LIGUORI et al., 2023).
- Fazit
Wir haben eine quantitative, risikoorientierte Architektur für Application Security vorgestellt, die auf der Integration von SAST, DAST, SCA und Threat Intelligence im DevSecOps-Zyklus basiert.
Die Formalisierung einer Risikofunktion ermöglichte es, Schwachstellen nicht nur nach technischer Schwere, sondern auch nach Exploit-Nachweisen und Betriebskontext zu priorisieren. Die experimentelle Evaluation zeigte eine signifikante Reduktion von False Positives, eine Verbesserung der mittleren Behebungszeit und eine Verringerung der Anzahl ausnutzbarer verwundbarer Abhängigkeiten.
Die Ergebnisse deuten darauf hin, dass risikoorientierte AppSec-Programme die operative Effizienz von Sicherheitsteams deutlich steigern und die tatsächliche Angriffsfläche reduzieren können.
Referenzen
ALLEN, Julia; BOYENS, Jon; SMITH, Timothy. Building Secure and Resilient Systems. Boston: Addison‑Wesley, 2020. Available at: https://www.oreilly.com/library/view/building-secure-and/9780136819425/. Accessed on: 10 Apr. 2024.
BEHL, Abhishek; BEHL, Kiran. Cybersecurity and Cyberwar: What Everyone Needs to Know. Oxford: Oxford University Press, 2017. Available at: https://global.oup.com. Accessed on: 10 Apr. 2024.
CISA. Known Exploited Vulnerabilities Catalog. 2024. Available at: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Accessed on: 10 Apr. 2024.
ENISA. Threat Landscape 2023. 2023. Available at: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023. Accessed on: 10 Apr. 2024.
FIRST. Common Vulnerability Scoring System v3.1 Specification. 2019. Available at: https://www.first.org/cvss/. Accessed on: 10 Apr. 2024.
JOHNSON, Brittany et al. Why don’t software developers use static analysis tools? In: International Conference on Software Engineering (ICSE). Piscataway: IEEE, 2013. Available at: https://doi.org/10.1109/ICSE.2013.6606613. Accessed on: 10 Apr. 2024.
LIGUORI, Andrea et al. eBPF-based runtime security monitoring for cloud-native systems. IEEE Security & Privacy, 2023. Available at: https://doi.org/10.1109/MSEC.2023.3241123. Accessed on: 10 Apr. 2024.
MITRE. MITRE ATT&CK Enterprise Matrix. 2023. Available at: https://attack.mitre.org. Accessed on: 10 Apr. 2024.
NIST. National Vulnerability Database. 2023. Available at: https://nvd.nist.gov. Accessed on: 10 Apr. 2024.
NIST. Secure Software Development Framework (SP 800‑218). Gaithersburg: NIST, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 Apr. 2024.
OWASP. OWASP SAMM v2 Model. 2023. Available at: https://owaspsamm.org. Accessed on: 10 Apr. 2024.
OWASP. OWASP Top 10:2021. 2021. Available at: https://owasp.org/www-project-top-ten/. Accessed on: 10 Apr. 2024.
SCANDARIATO, Riccardo et al. Static and dynamic analysis for security. IEEE Security & Privacy, v. 11, n. 1, p. 74–79, 2013. Available at: https://doi.org/10.1109/MSP.2012.150. Accessed on: 10 Apr. 2024.
SHARMA, Ankur; SHARMA, Ankit. Exploitation trends in CVEs: empirical analysis. Computers & Security, v. 96, 2020. Available at: https://doi.org/10.1016/j.cose.2020.101875. Accessed on: 10 Apr. 2024.
VERIZON. Data Breach Investigations Report. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 10 Apr. 2024.
ZHANG, Yinqian et al. Automated vulnerability detection in modern software systems. ACM Computing Surveys, 2022. Available at: https://doi.org/10.1145/3507907. Accessed on: 10 Apr. 2024.
LI, Frank et al. Understanding the security of container ecosystems. IEEE Symposium on Security and Privacy, 2020. Available at: https://doi.org/10.1109/SP40000.2020.00035. Accessed on: 10 Apr. 2024.
BROWN, Casey; GORDON, Andrew. Threat intelligence driven vulnerability management. SANS Institute, 2021. Available at: https://www.sans.org/white-papers/. Accessed on: 10 Apr. 2024.
CHERNY, Sasha; LEE, Jason. DevSecOps practices for secure CI/CD pipelines. IEEE Software, 2022. Available at: https://doi.org/10.1109/MS.2022.3145123. Accessed on: 10 Apr. 2024.
BEHL, Abhishek. Cyber risk analytics for vulnerability prioritization. Journal of Cybersecurity, 2021. Available at: https://doi.org/10.1093/cybsec/tyab021. Accessed on: 10 Apr. 2024.
SNYK. State of Open Source Security Report. 2023. Available at: https://snyk.io/reports/open-source-security/. Accessed on: 10 Apr. 2024.
AQUA SECURITY. Trivy Documentation. 2024. Available at: https://aquasecurity.github.io/trivy/. Accessed on: 10 Apr. 2024.
SEMGREP. Semgrep Documentation. 2024. Available at: https://semgrep.dev/docs/. Accessed on: 10 Apr. 2024.
OWASP. OWASP ZAP Documentation. 2024. Available at: https://www.zaproxy.org/docs/. Accessed on: 10 Apr. 2024.
DEFECTDOJO. DefectDojo Documentation. 2024. Available at: https://docs.defectdojo.com. Accessed on: 10 Apr. 2024.