Eine quantitative und operative Architektur für Application Security auf Grundlage der Integration von SAST, DAST, SCA und Threat Intelligence im DevSecOps-Zyklus

1. Einleitung

Die Anwendungssicherheit (Application Security – AppSec) hat sich als einer der wichtigsten Risikotreiber in modernen Unternehmensumgebungen etabliert. Die beschleunigte digitale Transformation, kombiniert mit der Einführung von Architekturen auf Basis von Microservices, 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 unterstreichen 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 zählen (VERIZON, 2023). Darüber hinaus bleiben Angriffe, die bekannte Schwachstellen in internetexponierten Anwendungen ausnutzen, eine der dominierenden Techniken für Eindringversuche (MITRE, 2023).

Aktuelle Vorfälle verdeutlichen die Kritikalität der Abhängigkeitskette von Software. Die Schwachstelle Log4Shell (CVE‑2021‑44228) beispielsweise zeigte, wie weit verbreitet genutzte Bibliotheken systemische Risiken in großem Maßstab einführen können (NIST, 2023). Die Ausnutzung dieser Schwachstelle ermöglichte Remote Code Execution durch JNDI-Injection 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 Zahl 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 ausnutzungsbezogene Risiko wirksam reduziert und nicht lediglich die nominale Anzahl identifizierter Schwachstellen.

Wir formulieren die folgenden Forschungsfragen:

RQ1: Wie lassen sich Ergebnisse von SAST, DAST und SCA korrelieren, um False Positives zu reduzieren und gleichzeitig die Erkennungsabdeckung beizubehalten?
RQ2: Wie lässt sich das ausnutzungsbezogene 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 Hauptbeiträge dieser Arbeit sind:

• Vorschlag einer formalen Risikofunktion zur Priorisierung von Schwachstellen.
• Integrierte, risikoorientierte AppSec-Architektur im DevSecOps-Kontext.
• Experimentelle Bewertung auf Basis realer Produktionsanwendungen.

2. Hintergrund und verwandte Arbeiten

Tools für Static Application Security Testing (SAST) analysieren den Quellcode ohne Programmausführung und verwenden Datenfluss- und Kontrollflussanalyse, um Schwachstellenmuster zu identifizieren (SCANDARIATO et al., 2013). Weit verbreitete Werkzeuge sind unter anderem 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 Einschränkungen statischer Analysewerkzeuge in realen Umgebungen. Johnson et al. (2013) zeigen, dass Entwickler Warnungen aufgrund der geringen Präzision der Werkzeuge häufig ignorieren. Zusätzliche 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) liefern 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. Quellen wie Exploit‑DB, CISA Known Exploited Vulnerabilities (KEV) und Threat-Intelligence-Feeds ermöglichen die Identifikation von Schwachstellen mit aktiver Ausnutzung (CISA, 2024).

3. 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 Bereich $[0,1]$
• $E(v)$ — Indikator für einen verfügbaren öffentlichen Exploit
• $X(v)$ — Expositionsfaktor der Anwendung
• $T(v)$ — Kritikalität im Zusammenhang mit der MITRE-ATT&CK-Technik

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 CVSS-basierten Schwere auch Kontextinformationen zu berücksichtigen.

4. 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 in 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 Deduplizierung 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 rechnerische Komplexität des Algorithmus beträgt aufgrund der Sortierphase $O(n \log n)$.

Wir integrieren Scanner direkt in die CI/CD-Pipeline. Ein Beispiel für die Ausführung von Semgrep ist unten dargestellt:

semgrep --config auto --json --output semgrep.json

Die dynamische Analyse mit OWASP ZAP kann im automatisierten Modus ausgeführt werden:

zap-baseline.py -t https://app.test -J zap-report.json

5. Implementierung

Die Architektur wurde in einem Kubernetes-Cluster Version 1.28 implementiert, bestehend aus sechs Knoten mit jeweils 32 vCPUs und 128 GB Speicher.

Der verwendete Werkzeugsatz 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 für eine benutzerdefinierte Semgrep-Regel zur Erkennung unsicherer Deserialisierung in Python ist nachfolgend dargestellt:

rules:
- id: insecure-deserialization
  pattern: pickle.loads(...)
  message: Mögliche unsichere Deserialisierung
  languages: [python]
  severity: ERROR

6. Experimentelle Evaluation

Das Experiment wurde an einem Satz von 42 Unternehmensanwendungen durchgeführt.

Sprache	Anzahl der Anwendungen
Java	18
Python	14
Node.js	10

Zu Beginn wurden 12.842 Schwachstellen durch die Kombination der drei Scanner identifiziert.

Nach Deduplizierung 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 anhand einer 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 reduzierte sich die Anzahl verwundbarer, ausnutzbarer Abhängigkeiten mit aktivem öffentlichem Exploit nach der risikobasierten Priorisierung signifikant.

Metrik	Vorher	Nach 60 Tagen
Kritische ausnutzbare Abhängigkeiten	312	87

7. Fallstudie

Wir führten eine Fallstudie an einer öffentlich zugänglichen Finanzanwendung durch.

Während der Analyse identifizierte SAST die Nutzung der Bibliothek Jackson Databind, die gegenüber CVE‑2020‑36518 verwundbar ist. Das SCA-Tool 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 positionierte die Schwachstelle unter den drei kritischsten des Systems, was zur Anwendung eines Patches in weniger als 48 Stunden führte.

Ohne risikoorientierte Priorisierung war die Schwachstelle lediglich als „Hoch“ unter mehr als 240 Befunden eingestuft.

8. Diskussion

Die experimentellen Ergebnisse zeigen, dass die Integration mehrerer Analysetechniken mit Threat Intelligence die Priorisierung von Schwachstellen signifikant verbessert.

Der wichtigste operative Vorteil ist die Reduktion des durch automatisierte Scanner erzeugten Rauschens. Durch die Berücksichtigung des realen Ausnutzungskontexts und der Exposition der Anwendung können Teams ihre Bemühungen auf Schwachstellen mit höherer Ausnutzungswahrscheinlichkeit konzentrieren.

Die Vorgehensweise weist jedoch auch Einschränkungen auf. Die Qualität der Priorisierung hängt von der Verfügbarkeit und Aktualität der Threat-Intelligence-Feeds ab. Zudem werden Zero-Day-Schwachstellen, die nicht in öffentlichen Datenbanken enthalten sind, möglicherweise nicht angemessen priorisiert.

Die Integration mit eBPF-basiertem Runtime-Monitoring und Werkzeugen zur Verhaltensdetektion kann den Ansatz ergänzen, indem sie Sichtbarkeit in aktive Ausnutzung in Produktionsumgebungen فراهمstellt (LIGUORI et al., 2023).

9. Schlussfolgerung

Wir haben eine quantitative, risikoorientierte Architektur für Application Security vorgestellt, die auf der Integration von SAST, DAST, SCA und Threat Intelligence im DevSecOps-Lebenszyklus basiert.

Die Formalisierung einer Risikofunktion ermöglichte die Priorisierung von Schwachstellen unter Berücksichtigung nicht nur der technischen Schwere, sondern auch von Ausnutzungsnachweisen und des operativen Kontexts. Die experimentelle Bewertung 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.

References

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.