Application Security Audit

Ein Application Security Audit ist die systematische Sicherheitsüberprüfung einer Anwendung, ihrer Schnittstellen (APIs) und ihrer abhängigen Komponenten. Es dient dazu, Schwachstellen, Fehlkonfigurationen und Designrisiken zu erkennen, zu bewerten und priorisiert zu beheben. Grundlage bilden etablierte Rahmenwerke wie OWASP ASVS und deutschsprachige Leitfäden des BSI. [Q1][Q2]

Hintergrund und Entstehung

Mit der zunehmenden Digitalisierung sind Web- und Mobile-Anwendungen zu zentralen Angriffszielen geworden. Das BSI publiziert seit Jahren Leitfäden und Grundschutz-Bausteine, um Auftraggebern und Entwicklern konkrete Anforderungen an sichere Webanwendungen an die Hand zu geben. Ziel ist ein nachvollziehbarer, wiederholbarer Prüf- und Verbesserungsprozess entlang des Lebenszyklus. [Q1]

Parallel entstand der OWASP Application Security Verification Standard (ASVS) als international anerkanntes, frei verfügbares Anforderungskatalog- und Prüfrahmenwerk. ASVS standardisiert Prüftiefe und -abdeckung und hilft, Audits entlang definierter Kontrollziele (z. B. Authentifizierung, Sitzungsmanagement, Datenvalidierung) auszurichten. [Q2]

In der Praxis kombinieren Auditoren diese Normierungen mit einem klar beschriebenen Vorgehen: Informationsaufnahme, Threat Modeling, automatisierte Scans, manuelle Verifikation, Exploitation-Versuche im sicheren Rahmen sowie ein risikoorientiertes Reporting mit Remediation-Plan. SCHUTZWERK bezeichnet dieses Vorgehen als Web Application Security Assessment (WASA). [Q4]

Wichtigste Merkmale und Kernelemente

Risikobasierter Rahmen:
Ein Application Security Audit orientiert sich an Risiko und Schutzbedarf der Anwendung. BSI-Grundschutz und Leitfäden für Webanwendungen empfehlen eine systematische Vorgehensweise über Konzeption, Umsetzung und Betrieb hinweg. [Q1][Q3]

Methodenmix: automatisiert und manuell:
Automatisierte Schwachstellenscans werden durch manuelle Prüfungen ergänzt. So lassen sich Logikfehler, Autorisierungsumgehungen oder Ketten aus Teilrisiken aufdecken. Das Vorgehen umfasst White-, Grey- oder Black-Box-Perspektiven. [Q4]

Referenzstandards (ASVS):
Die Prüftiefe lässt sich entlang der OWASP-ASVS-Level (z. B. L1–L3) festlegen. So werden Kontrollen zu Authentifizierung, Kryptografie, Fehlerbehandlung, API-Sicherheit und Supply Chain reproduzierbar verifiziert. [Q2]

Prüfumfang einschließlich Abhängigkeiten:
Geprüft werden nicht nur UI und Backend. Einbezogen werden auch APIs, Identitäts-Provider, Datenbanken, Message-Broker, Konfigurationen sowie Build-/Deploy-Prozesse, soweit sie die Anwendungssicherheit beeinflussen. [Q1][Q4]

Reporting und Nachverfolgung:
Ergebnisse enthalten Risikobewertung (z. B. CVSS-basiert), Evidenzen, Exploit-Beispiele und Maßnahmenpriorisierung. Ein Re-Test prüft die Wirksamkeit der Remediation. [Q4]

Bedeutung für Unternehmen und Praxisrelevanz

Für Unternehmen im DACH-Raum bietet ein Application Security Audit Governance-Sicherheit: Anforderungen sind nachvollziehbar, priorisiert und mit Standards verknüpft. Das erleichtert interne Freigaben, Budgetentscheidungen und den Dialog mit Aufsichts- oder Zertifizierungsstellen. [Q1][Q3]

In Entwicklungsteams verankert das Audit Secure-by-Design. Schwachstellen fließen als konkrete Backlog-Items in den SDLC zurück. ASVS-Kontrollen lassen sich in Architektur-Reviews, Pull-Requests und Testfälle übersetzen. So steigt die Fehlertoleranz gegenüber Angriffsversuchen. Lieferkettenrisiken werden früher sichtbar. [Q2]

Ein dokumentiertes Audit stärkt die Compliance-Argumentation gegenüber Kunden, Partnern und Auditteams, z. B. im Kontext von ISO/IEC-27001-basierten ISMS oder BSI-Grundschutz. Entscheidend ist die Verifikation der Wirksamkeit, nicht nur das Vorhandensein von Richtlinien. [Q1][Q3]

Abgrenzung zu verwandten Begriffen

Application Security Audit vs. Penetrationstest:
Ein Penetrationstest fokussiert das Ausnutzen von Schwachstellen in einem definierten Zeitfenster. Das Audit deckt zusätzlich Prozesse, Konfigurationen und Kontrollen ab, bewertet systematisch gegen Standards und priorisiert Maßnahmen. [→ /glossar/penetrationstest/]

Application Security Audit vs. Vulnerability Scan:
Ein Scan ist überwiegend automatisiert und liefert Befunde ohne Kontext. Das Audit kombiniert Scans mit manueller Analyse, Threat Modeling und Exploit-Verifikation. [→ /glossar/vulnerability-scan/]

Application Security Audit vs. Code Review:
Code-Reviews prüfen Quellcode auf Musterfehler. Ein Application Security Audit betrachtet laufende Systeme, Endpunkte, Protokolle und Umgebungen. Code-Reviews können Bestandteil sein, sind aber nicht zwingend. [→ /glossar/code-review/]

Beispiele aus der Praxis

Beispiel 1: SaaS-Anbieter (≈ 150 Mitarbeitende)
Im Audit wurden unsichere JWT-Konfigurationen und fehlende Autorisierungsprüfungen in Admin-APIs identifiziert. Nach Härtung gemäß ASVS-Kontrollen V2/V4 und Einführung eines automatisierten Regressionstests sank die Zahl kritischer Findings im Re-Test von 8 auf 1. [Q2]

Beispiel 2: Gesundheitsdienstleister (≈ 300 Mitarbeitende)
Durch Konfigurationsprüfungen in Infrastructure as Code fanden sich überprivilegierte Service-Konten. Die Umstellung auf Least-Privilege-Rollen und Secrets-Rotation reduzierte das Risiko unautorisierter Zugriffe messbar. Der Re-Test zeigte keine kritischen Befunde. [Q2]

Häufig gestellte Fragen

Was ist ein Application Security Audit?
Es handelt sich um eine strukturierte Prüfung. Bewertet werden Sicherheitskontrollen einer Anwendung gegen etablierte Standards und Leitfäden. Dazu zählen manuelle Tests, Scans und die Verifikation von Maßnahmen entlang des Lebenszyklus. Ziel ist ein priorisiertes Maßnahmenpaket zur Risikoreduktion. [Q1][Q2]

Wie unterscheidet sich ein Application Security Audit von einem Penetrationstest?
Der Penetrationstest zeigt exemplarisch ausnutzbare Schwachstellen. Das Audit prüft breiter: Prozesse, Konfigurationen, Entwicklungs- und Betriebspraktiken sowie Kontrollen nach ASVS/BSI. Ergebnis ist ein normreferenziertes, wiederholbares, compliance-fähiges Bild mit klarer Priorisierung. [Q1][Q2]

Welche Standards eignen sich für Application Security Audits?
Bewährt sind der OWASP ASVS als Kontrollrahmen für Anwendungen sowie BSI-Leitfäden und Grundschutz-Bausteine für deutschsprachige Organisationen. Je nach Umfeld wird ergänzend gegen interne Policies oder ISO/IEC-27001-Kontrollen gemappt. [Q1][Q2][Q3]

Was umfasst der Ablauf eines Web Application Security Assessments?
Typisch sind Scoping und Informationsaufnahme, Threat Modeling, automatisierte Scans, manuelle Verifikation, risikobasierte Bewertung und Re-Test zur Wirksamkeitskontrolle. SCHUTZWERK dokumentiert das Vorgehen transparent als WASA. [Q4]

Quellen

[Q1] Bundesamt für Sicherheit in der Informationstechnik (BSI): „Webanwendungen – Empfehlungen und Leitfäden“, https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Webanwendungen/webanwendungen_node.html, Abrufdatum: 06.11.2025.
[Q2] OWASP: „Application Security Verification Standard (ASVS) – Projektseite“, https://owasp.org/www-project-application-security-verification-standard/, Abrufdatum: 06.11.2025.
[Q3] BSI-Grundschutz-Kompendium: „APP.3.1 Webanwendungen und Webservices (Edition 2022)“, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium/IT_Grundschutz_Kompendium_Edition2023.html, Abrufdatum: 06.11.2025.
[Q4] SCHUTZWERK: „Web Application Security Assessment (WASA) – Methodik und Vorgehen“, https://www.schutzwerk.com/pruefung/web-application-security-assessment/, Abrufdatum: 06.11.2025. |