Weitere Seiten sind derzeit auf Englisch. Entsprechende Artikellinks sind mit EN gekennzeichnet.
QUELLENVERGLEICH / KI-Sicherheit · Review-Praxis
Reviews im
Entwicklungszyklus
Eine quellenbasierte Einordnung von Prüfzielen, Zeitpunkten und Prüfumfang in der Softwareentwicklung. Sie trennt Anforderungen aus Standards und institutionelle Empfehlungen von abgeleiteten Empfehlungen für verschiedene Änderungstypen.
- Artikeldatum
- Stand der Ausgangsnotizen
- Letzte Quellenprüfung
KURZFASSUNG
Kernaussagen.
- Prüfziel, Methode und Zeitpunkt trennen. ASVS definiert Anforderungen an die Anwendung. Leitlinien für Reviews und Tests beschreiben das Vorgehen zur Prüfung. Die Änderung bestimmt, wann der Prüfumfang erneut bewertet wird.
- Den Umfang an der Änderung ausrichten. Betroffene Anforderungen und Risiken prüfen. Anwendbare Pflichtprüfungen bleiben bestehen.
- Quellen und Ableitungen trennen. Die vorgeschlagene Matrix nach Änderungstyp ist eine redaktionelle Empfehlung. Sie ist kein von einer Institution vorgeschriebenes Minimum.
01QUELLENVERGLEICH
Empfehlungen für Reviews und Tests
ASVS-Prüflevels legen fest, welche Anforderungen an die Anwendung zu prüfen sind. Die Levels allein bestimmen kein Review- oder Testverfahren. Methoden, Prüfumfang, Prüfende und Nachweise müssen im Prüfplan festgelegt werden. [07] [08]
NIST SSDF PW.7 sieht die Wahl zwischen menschlichem Review, werkzeuggestützter Analyse oder deren Kombination vor. Geprüft wird anhand von Vorgaben für sichere Programmierung. Befunde werden dokumentiert und bewertet. PW.8 behandelt die Auswahl, Planung und Durchführung von Tests ausführbaren Codes. Ergebnisse werden dokumentiert und entdeckte Probleme bewertet. [05]
NIST IR 8397 empfiehlt elf Verifikationstechniken als Mindestumfang für die Entwicklung. Dazu gehören Bedrohungsmodellierung, statische Analyse, Regressionstests und Fuzzing. Das Vorgehen wird an Produkt, Technologie, Werkzeuge und Entwicklungszyklus angepasst. Der verlinkte Testing-Artikel erläutert den vollständigen Katalog und seine Grenzen. [09]
OWASP SAMM verbindet automatisierte Sicherheitstests mit manuellen Reviews ausgewählter Komponenten mit hohem Risiko. Zu den Kriterien gehören eine risikobasierte Auswahl, qualifizierte Prüfende, dokumentierte Prüfleitlinien und die Behandlung von Befunden im Fehlermanagement. Die Reifegrade beschreiben organisatorische Praktiken. Sie sind von den ASVS-Prüflevels für Anwendungen zu unterscheiden. [11] [12]
OWASP WSTG bietet ein anpassbares Vorgehen über den Lebenszyklus. Dazu gehören Reviews von Anforderungen, Architektur und Code, Penetrations- und Konfigurationstests sowie die Prüfung von Änderungen. Die Leitlinie gibt keine universelle Abfolge verbindlich vor. [01]
Redaktionelle Empfehlung. Die folgende Matrix leitet aus diesen Quellen einen Prüfumfang je Änderungstyp ab. Sie begründet weder ein institutionell vorgeschriebenes Minimum noch einen universellen Goldstandard.
Die elf Verifikationstechniken und ihre Grenzen
Werkzeuge für Code- und Security-Reviews
Zum Inhaltsverzeichnis02QUELLENVERGLEICH
ASVS: Anforderungen an die Anwendung
Anforderungen des gewählten Standards. Für Webanwendungen und Services bietet OWASP ASVS 5.0.0 einen überprüfbaren Maßstab. Die Wahl des Levels richtet sich nach Risiko, sensiblen Daten und dem benötigten Absicherungsniveau. Die folgenden Levels beschreiben Anforderungen an die Anwendung. Sie schreiben keine bestimmte Scannerkombination oder CI/CD-Pipeline vor. [07]
Die folgenden Beispiele fassen ausgewählte Anforderungen verkürzt zusammen. Sie sind keine vollständige Checkliste. Die Levels bauen aufeinander auf. Einzelne Anforderungen enthalten strengere Bedingungen für höhere Levels. [07]
Version, Ziellevel, Prüfumfang, anwendbare Anforderungen, Methoden und Nachweise gehören in den Prüfbericht. Ausgrenzungen müssen begründet werden. Ein Scannerbericht allein kann die Erfüllung aller Anforderungen nicht belegen. Eine akzeptierte Abweichung ist keine erfüllte Anforderung. OWASP zertifiziert weder Anwendungen noch Prüfanbieter. [08]
ASVS L1 · Mindestniveau
Das Mindestniveau und ein Einstieg in die Anwendung des Standards. Im Mittelpunkt stehen grundlegende Schutzmaßnahmen gegen verbreitete Angriffe. Version 5.0 setzt nicht voraus, dass jede L1-Anforderung vollständig von außen geprüft werden kann. [07]
Zu den ausgewählten Anforderungen gehört die Validierung von Eingaben, die für Geschäfts- oder Sicherheitsentscheidungen verwendet werden (v5.0.0-2.2.1). Hinzu kommen Schutzmaßnahmen gegen Credential Stuffing und das systematische Ausprobieren von Passwörtern (v5.0.0-6.3.1). Funktionen und einzelne Datenobjekte dürfen nur ausdrücklich berechtigten Nutzern oder Clients zugänglich sein (v5.0.0-8.2.1 und v5.0.0-8.2.2). [14] [15] [16]
ASVS L2 · Ziel für die meisten Anwendungen
OWASP empfiehlt L2 für die meisten Anwendungen. Es umfasst die anwendbaren L1- und L2-Anforderungen und berücksichtigt seltenere Angriffe sowie komplexere Schutzmaßnahmen. Der gewählte Prüfumfang und nicht anwendbare Anforderungen müssen weiterhin begründet werden. [07] [08]
L2 erweitert die Eingabevalidierung auf alle Eingaben (L2-Bedingung in v5.0.0-2.2.1) und verlangt Mehrfaktor-Authentifizierung (v5.0.0-6.3.3). Berechtigungen werden auf Ebene einzelner Datenfelder durchgesetzt (v5.0.0-8.2.3). Authentifizierungsvorgänge und abgelehnte Zugriffsversuche werden protokolliert (v5.0.0-16.3.1 und v5.0.0-16.3.2). [14] [15] [16] [17]
Die MFA-Anforderung erlaubt eine Lockerung nur mit vollständig dokumentierter Begründung und umfassenden kompensierenden Schutzmaßnahmen. Diese Bedingung gilt auch für ihre strengere L3-Klausel. [15]
ASVS L3 · Höchstes Absicherungsniveau
Das höchste im ASVS definierte Absicherungsniveau umfasst anwendbare Anforderungen aus L1, L2 und L3. Die Ergänzungen bieten häufig weitere Schutzschichten oder aufwendiger umzusetzende Kontrollen. Es eignet sich für Anwendungen, deren Risiko und Absicherungsbedarf diese Prüftiefe erfordern. [07]
L3 verlangt einen hardwarebasierten, gegen Phishing geschützten Authentifizierungsfaktor mit bewusster Nutzeraktion (L3-Bedingung in v5.0.0-6.3.3). Kontextabhängige Kontrollen für Authentifizierung und Autorisierung gelten beim Sitzungsbeginn und während der Sitzung (v5.0.0-8.2.4). Geschäftsvorgänge mit hohem Wert erfordern die Freigabe durch mehrere Personen (v5.0.0-2.3.5). Alle Autorisierungsentscheidungen werden protokolliert, einschließlich Zugriffen auf sensible Daten. Die sensiblen Daten selbst gehören dabei nicht ins Protokoll (L3-Bedingung in v5.0.0-16.3.2). [15] [16] [14] [17]
03QUELLENVERGLEICH
Reviews im Softwareentwicklungszyklus
Empfehlungen der Quellen. WSTG ordnet Sicherheitstests über den gesamten Lebenszyklus ein. ENISA nennt SAST und Abhängigkeitsprüfungen bei jedem PR sowie Peer Review für sicherheitsrelevante Änderungen. OWASP SAMM beschreibt automatisierte Basisprüfungen und qualifizierte manuelle Reviews von Komponenten mit hohem Risiko. Die Matrix belegt diese Methoden getrennt vom empfohlenen Prüfumfang je Änderungstyp. [01] [04] [11] [12]
Abgeleitete Empfehlung. Die Änderungstypen, ihr vorgeschlagener Basisumfang und die Auslöser für eine vertiefte Prüfung sind eine redaktionelle Ableitung aus den genannten Quellen. Keine zitierte Institution schreibt diese konkrete Matrix oder einen universellen Goldstandard je Änderung vor. Die Spalte zum Basisumfang ist ein Ausgangspunkt für projektspezifische Regeln. Sie belegt kein vollständiges Mindestniveau und erlaubt nicht, Pflichtprüfungen auszulassen. Prüfungen können sich überschneiden. Befunde können dazu führen, dass Entwurf, Implementierung oder Tests erneut bearbeitet werden.
ASVS L1, L2 und L3 beschreiben das Absicherungsziel für die Anwendung. Sie sind keine Review-Stufen für einzelne Diffs. Zunächst wird der Prüfumfang dokumentiert. Anschließend wird untersucht, wie eine Änderung die anwendbaren Anforderungen und die Angriffsfläche beeinflusst. Die Matrix empfiehlt, zusätzliche Reviews daran auszurichten. Die gewählten Anforderungen bleiben bestehen. [07] [02] [03]
Abgeleitete Empfehlung für kosmetische Änderungen. Die zitierten Sicherheitsleitlinien enthalten keine ausdrückliche Ausnahme für Button-Farben. Die Empfehlung, allein wegen einer Farbänderung keinen neuen vollständigen Penetrationstest auszulösen, setzt unverändertes Verhalten, unveränderte Berechtigungen, Datenflüsse und Sicherheitshinweise voraus. Eine Änderung, die eine Sicherheitswarnung oder eine privilegierte Aktion schlechter erkennbar macht, erfüllt diese Voraussetzung nicht. Bestehende Pflichtprüfungen gelten weiterhin. [04] [02]
Anforderung bei gewähltem AISVS. AISVS hat eigene Levels. Appendix C der Version 1.01 verlangt in AC.4.2 auf L2 SAST, IAST, DAST, Secret-Scanning, IaC-Scanning und SCA bei jedem PR mit KI-generiertem Code. Eine kosmetische Ausnahme wird nicht genannt. AC.4.4 ergänzt erhöhte Review-Anforderungen für sicherheitskritische Dateien. Wenn diese Anforderungen gelten, haben sie Vorrang vor einer weniger umfangreichen abgeleiteten Empfehlung. Das OWASP-Projekt hat weiterhin den Status Incubator. Seine Anforderungen sind kein universelles Minimum für jede Anwendung. [06] [10]
VISUELL ERKLÄRT
Anlässe und Tiefe eines Reviews
EINORDNUNG IM SOFTWAREENTWICKLUNGSZYKLUS
- 01Entwurf
Anforderungen, Architektur & Bedrohungsmodell
- 02Umsetzung
Tests, statische Analyse, Abhängigkeiten & Secrets
- 03Änderungsreview
Diff und betroffene Codepfade prüfen
- 04Release
Laufzeitverhalten & Deployment-Einstellungen prüfen
- 05Betrieb
Schwachstellen, Änderungen & neue Nachweise verfolgen
Aktivitäten überschneiden sich. Befunde fließen in Entwurf, Korrekturen und Tests zurück.
Anlässe für eine erneute Prüfung
- AusgangsbewertungNeue Anwendung
- Vor dem ersten Release die Architektur, das Repository und relevante Laufzeitrisiken bewerten. Nach wesentlichen Änderungen erneut prüfen.
- Jede ÄnderungEntwicklung & Integration
- Automatisierte Basisprüfungen ausführen und betroffenes Verhalten prüfen. Das bedeutet kein vollständiges Repository-Audit bei jedem Pull Request.
- Bei verändertem RisikoGeänderte Sicherheitsannahmen
- Betroffene Bedrohungen erneut bewerten und das Review bei neuen Schnittstellen, Berechtigungen, sensiblen Daten, Abhängigkeiten oder Infrastruktur vertiefen.
- WiederkehrendWartung & Betrieb
- Nach einem risikobasierten Zeitplan sowie bei neuen Schwachstellen oder Vorfällen erneut bewerten, auch ohne Codeänderung.
Prüfumfang nach Änderungstyp
Quellenaussagen fassen die zitierten Veröffentlichungen zusammen. Die abgeleiteten Empfehlungen schlagen daraus einen Basisumfang und Anlässe für eine vertiefte Prüfung je Änderungstyp vor. Diese Zuordnung ist weder ein von den Quellen vorgeschriebenes Minimum noch ein validierter Goldstandard.
-
Neue Anwendung / erstes Release
Abgeleitete Empfehlung
- Basisumfang
- Anwendbare ASVS-Anforderungen auswählen. Bedrohungen, Code, Komponenten und Laufzeitverhalten prüfen. Einen Pentest mit definiertem Umfang bei der Bereitstellung vorsehen und offene Befunde dokumentieren.
- Vertiefung / Anlass
- Bei sensiblen Daten, kritischen Abläufen oder Nachweislücken die Prüftiefe erhöhen. Korrekturen prüfen, bevor verbleibendes Risiko akzeptiert wird.
-
Rein visuelle Änderung
Abgeleitete Empfehlung
- Basisumfang
- Gemeinsame PR-Prüfungen beibehalten. Diff, Darstellung und Kontrast prüfen. Bestätigen, dass Verhalten und Sicherheitseinstellungen unverändert sind.
- Vertiefung / Anlass
- Keinen vollständigen Pentest allein wegen einer Farbänderung ergänzen. Änderungen an Sicherheitswarnungen oder privilegierten Bedienelementen neu bewerten.
-
Funktion / Fehlerbehebung
Abgeleitete Empfehlung
- Basisumfang
- Gemeinsame PR-Prüfungen beibehalten. Diff und betroffene Codepfade prüfen. Erwartetes Verhalten, Fehlerfälle und relevante Regressionen testen.
- Vertiefung / Anlass
- Security Review und Laufzeittests vertiefen, wenn sich Schnittstellen, Datenflüsse oder Vertrauensannahmen ändern.
-
Login / Berechtigungen / sensible Schnittstellen
Abgeleitete Empfehlung
- Basisumfang
- Gemeinsame PR-Prüfungen beibehalten. Ein gezieltes Security Review und negative Zugriffstests ergänzen. Betroffene Bedrohungen und Vertrauensgrenzen neu bewerten.
- Vertiefung / Anlass
- Missbrauchsfälle und Integrationstests auf betroffene Rollen und Schnittstellen erweitern. Gezielte Penetrationstests einsetzen, wenn das Risiko dies erfordert.
-
Neue Abhängigkeit / Update
Abgeleitete Empfehlung
- Basisumfang
- Gemeinsame PR-Prüfungen beibehalten. Geänderte Versionen, Herkunft und Schwachstellenbefunde prüfen. Das Inventar aktualisieren und betroffene Integrationen testen.
- Vertiefung / Anlass
- Neue Berechtigungen von Komponenten oder erreichbare Schnittstellen untersuchen. Bei geänderter Angriffsfläche gezielte Reviews und Tests ergänzen.
-
Infrastruktur / Konfiguration
Abgeleitete Empfehlung
- Basisumfang
- Anwendbare PR-Prüfungen beibehalten. Konfiguration, Richtlinienprüfungen, Zugriffe, Secrets und Erreichbarkeit prüfen. Das Deployment testen und Rollback vorbereiten.
- Vertiefung / Anlass
- Bedrohungen neu bewerten und betroffene Grenzen testen, wenn sich Identitätsregeln, Netzwerkzugriffe, Verschlüsselung oder Datenverarbeitung ändern.
Alle Angaben zu Basisumfang und Vertiefung sind redaktionelle Empfehlungen. Die Quellen stützen ihre Grundsätze und Methoden. Sie belegen weder diese konkrete Checkliste noch deren Vollständigkeit. „Rein visuell“ schließt Änderungen an Verhalten, Datenflüssen, Abhängigkeiten oder Sicherheitskonfiguration aus. Das ASVS-Level bleibt das Zielniveau der Anwendung und wird nicht jedem Diff neu zugeordnet.
Verbindliche Prüfungen gelten weiterhin. AISVS Appendix C, AC.4.2 (Level 2), verlangt automatisierte Sicherheitstests bei jedem Pull Request mit KI-generiertem Code. Ein risikobasiert festgelegter Prüfumfang hebt eine geltende Anforderung nicht auf. [06]
Eine redaktionelle Zusammenführung der zitierten Empfehlungen. Die Phasen überschneiden und wiederholen sich. Die Quellen je Zeile stützen die genannten Methoden und Grundsätze. Der vorgeschlagene Umfang je Änderungstyp ist eine abgeleitete Empfehlung. Die Matrix wurde am 19. Oktober 2026 ergänzt. Sie dokumentiert keine auf dieser Website ausgeführten Prüfungen.
Die Anforderungen an die Anwendung festlegen und eine Ausgangsbewertung erstellen. Den betroffenen Prüfumfang neu bewerten, wenn Änderungen oder neue Erkenntnisse das Risiko verändern. Die Matrix bietet einen Ausgangspunkt für projektspezifische Regeln. Anwendbare Anforderungen und dokumentierte Nachweise bleiben maßgeblich.
QUELLEN / 17
Quellen.
Dieser Artikel führt institutionelle Standards und Leitlinien zusammen. Die Matrix nach Änderungstyp stützt sich auf Quellen von SAMM, ENISA, AISVS und W3C, die am 19. Oktober 2026 geprüft wurden. Andere Quellenangaben behalten ihr jeweiliges Prüfdatum. Anforderungen und Empfehlungen der Quellen sind von redaktionellen Empfehlungen getrennt. Der Artikel dokumentiert keine Bewertung oder Zertifizierung dieser Website.
- OWASP WSTG 4.2 — The Web Security Testing Framework (öffnet in einem neuen Tab)
Die Übersicht beschreibt ein anpassbares Vorgehen ohne verbindliche Vorgabe. Phasen 2 bis 5 umfassen Reviews von Anforderungen und Architektur, Code Reviews, Penetrations- und Konfigurationstests sowie die Prüfung von Änderungen. Die Grafik verwendet eine redaktionelle Gruppierung statt der genauen WSTG-Phasennamen.
- OWASP — Attack Surface Analysis Cheat Sheet (öffnet in einem neuen Tab)
„Managing the Attack Surface“ behandelt die Ausgangsbewertung, inkrementelle Änderungen, neue APIs und Uploads, Authentifizierung, Autorisierung und Architektur.
- OWASP SAMM — Threat Modeling (öffnet in einem neuen Tab)
Iterativer Prüfumfang, Anlässe für Aktualisierungen und regelmäßige Prüfung bestehender Bedrohungsmodelle. Die Aktivitäten sind nach Reifegrad geordnet.
- ENISA — Secure by Design and Default Playbook, Version 1.0 (öffnet in einem neuen Tab)
Abschnitte 4.8–4.9 behandeln Sicherheitsaspekte der Bedienoberfläche, Peer Review sensibler Änderungen, SAST und Abhängigkeitsprüfungen bei jedem PR, Negativtests, Secrets-Prüfungen und Release-Nachweise. Abschnitt 4.11 ergänzt Reviews von Infrastruktur und Konfiguration, Richtlinienprüfungen in der CI, Freigaben und Rollback. Abschnitte 4.13–4.14 behandeln Regressionstests für Sicherheitskorrekturen und Peer Review neuer Abhängigkeiten oder größerer Versionswechsel. Abschnitt 4.23.2 beschreibt eine produktabhängige Engineering-Baseline.
- NIST — Secure Software Development Framework (SSDF), Version 1.1 (öffnet in einem neuen Tab)
Endgültige Veröffentlichung. PW.7.1 bis PW.7.2 und PW.8.1 bis PW.8.2, gedruckte S. 14 bis 15 (PDF-S. 23 bis 24). Menschliches Review oder werkzeuggestützte Analyse wählen und Vorgaben für sichere Programmierung anwenden. Befunde dokumentieren und bewerten. Tests ausführbaren Codes auswählen, planen und durchführen. Ergebnisse dokumentieren und Probleme bewerten.
- OWASP AISVS 1.01 — Appendix C: AI-Assisted Secure Coding (öffnet in einem neuen Tab)
Veränderlicher main-Branch, stabiles Verzeichnis 1.01. AC.4.2 auf L2 nennt SAST, IAST, DAST, Secrets, IaC und SCA bei jedem PR mit KI-generiertem Code, ohne kosmetische Ausnahme. AC.4.4 ergänzt Review-Anforderungen für kritische Dateien. AISVS-Levels sind von ASVS-Levels zu unterscheiden.
- OWASP ASVS 5.0.0 — What is the ASVS? (öffnet in einem neuen Tab)
Festgehaltene Version 5.0.0. Geltungsbereich für Webanwendungen und Services. Die Levels bauen aufeinander auf und enthalten strengere Bedingungen für höhere Levels. L1 als Minimum, L2 als Empfehlung für die meisten Anwendungen und L3 als höchstes Absicherungsniveau. L1 ist nicht zwingend vollständig von außen prüfbar.
- OWASP ASVS 5.0.0 — Assessment and Certification (öffnet in einem neuen Tab)
Version, Level, Prüfumfang, Anwendbarkeit und Prüfnachweise. Grenzen automatisierter Werkzeuge. OWASP zertifiziert weder Anwendungen noch Prüfanbieter.
- NIST IR 8397 — Guidelines on Minimum Standards for Developer Verification of Software (öffnet in einem neuen Tab)
Abschnitte 1.1 bis 1.3 und 2.1 bis 2.11 empfehlen elf Verifikationstechniken als Mindestumfang. Das Vorgehen wird an Produkt, Technologie, Werkzeuge und Entwicklungszyklus angepasst. Ein einzelner konkreter, verbindlicher Prüfstandard kann nicht jede Software abdecken. Konfiguration und Betrieb liegen außerhalb des Geltungsbereichs.
- OWASP — Artificial Intelligence Security Verification Standard (AISVS) (öffnet in einem neuen Tab)
Das OWASP-Projektverzeichnis führt AISVS als Incubator-Projekt. Version 1.01 wurde anhand des Repositorys geprüft, nicht anhand älterer Versionsangaben auf Projektseiten.
- OWASP SAMM — Security Testing: Scalable Baseline (öffnet in einem neuen Tab)
V-ST-A-1 beschreibt statische und dynamische Tests, die passend zum Technologiestack gewählt werden. V-ST-A-3 integriert automatisierte Sicherheitstests und die Prüfung ihrer Ergebnisse in Build und Deployment. Die Aktivitäten gehören zu einem Reifegradmodell und schreiben kein Minimum je Änderungstyp vor.
- OWASP SAMM — Security Testing: Deep Understanding (öffnet in einem neuen Tab)
V-ST-B-1 beschreibt die risikobasierte Auswahl von Komponenten, qualifizierte Prüfende mit dokumentierten Leitlinien und die Behandlung von Befunden im Fehlermanagement. Beispiele für hohes Risiko sind Authentifizierung, Zugriffskontrolle, Sitzungen, externe Schnittstellen und Parser. V-ST-B-2 behandelt anwendungsspezifische Penetrationstests, üblicherweise vor dem Release. V-ST-B-3 nutzt frühere Befunde als Auslöser für gezielte Tests, wenn betroffener Code geändert wird.
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2 (öffnet in einem neuen Tab)
SC 1.4.3 behandelt Textkontrast. SC 1.4.11 behandelt den Kontrast, der zum Erkennen visueller Komponenten und Zustände erforderlich ist. Es gelten Ausnahmen. Dies sind Anforderungen an Barrierefreiheit, keine Vorgaben zur Häufigkeit von Security Reviews.
- OWASP ASVS 5.0.0 — V2 Validation and Business Logic (öffnet in einem neuen Tab)
Festgehaltene Version 5.0.0. v5.0.0-2.2.1 beschreibt die Eingabevalidierung auf L1 und den erweiterten Umfang auf L2. v5.0.0-2.3.5 verlangt auf L3 die Freigabe durch mehrere Personen für Geschäftsvorgänge mit hohem Wert.
- OWASP ASVS 5.0.0 — V6 Authentication (öffnet in einem neuen Tab)
Festgehaltene Version 5.0.0. v5.0.0-6.3.1 behandelt Schutzmaßnahmen gegen Credential Stuffing und Brute Force auf L1. v5.0.0-6.3.3 verlangt MFA auf L2, einen stärkeren hardwarebasierten Faktor auf L3 und dokumentierte Bedingungen für eine Lockerung.
- OWASP ASVS 5.0.0 — V16 Security Logging and Error Handling (öffnet in einem neuen Tab)
Festgehaltene Version 5.0.0. v5.0.0-16.3.1 verlangt auf L2 die Protokollierung von Authentifizierungsvorgängen. v5.0.0-16.3.2 umfasst abgelehnte Zugriffsversuche auf L2 und alle Autorisierungsentscheidungen auf L3. Die sensiblen Daten selbst werden dabei nicht protokolliert.