Verwaltung von Sicherheitsanforderungen
Die meisten Sicherheitsprobleme sind keine Programmierfehler — es fehlen Anforderungen. Niemand hat festgelegt, dass der Passwort-Reset-Ablauf Token ablaufen lassen soll. Niemand hat dokumentiert, dass API-Endpunkte Rate Limiting benötigen. Der Entwickler hat gebaut, was gefordert wurde. Sicherheit wurde nicht gefordert.
Sicherheitsanforderungen machen implizite Annahmen zu expliziten, testbaren Spezifikationen. Wenn aus „der Benutzer soll authentifiziert sein" wird „die Authentifizierung muss bcrypt mit Kostenfaktor 12 verwenden, Sitzungen müssen nach 30 Minuten Inaktivität ablaufen und fehlgeschlagene Anmeldeversuche müssen auf 5 pro Stunde begrenzt werden" — können Sie die Implementierung tatsächlich verifizieren.
Dieses Kapitel zeigt, wie Sie Sicherheitsanforderungen anhand von Branchenstandards definieren, in Ihren Entwicklungsworkflow integrieren und ihre korrekte Umsetzung verifizieren.
Warum Sicherheitsanforderungen wichtig sind
Ohne explizite Anforderungen:
- Entwickler treffen eigene Sicherheitsentscheidungen (inkonsistent)
- Sicherheitsprüfungen finden Probleme spät, wenn Korrekturen teuer sind
- Tests decken keine Sicherheit ab, weil nichts zum Testen vorhanden ist
- Compliance-Audits erfordern das Reverse-Engineering des tatsächlich Gebauten
Mit expliziten Anforderungen:
- Sicherheitsentscheidungen werden einmal getroffen, dokumentiert und wiederverwendet
- Entwickler wissen genau, was erwartet wird
- QA kann Sicherheit wie jedes andere Feature testen
- Compliance ist nachweisbar
Die Kosten für die Behebung eines Sicherheitsproblems steigen dramatisch, je später es gefunden wird. Eine in der Design-Phase erkannte Anforderung kostet fast nichts zu beheben. Dasselbe Problem in der Produktion gefunden erfordert möglicherweise Notfall-Patches, Kundenbenachrichtigungen und wochenlange Nachbesserungen.
OWASP Application Security Verification Standard (ASVS)
Der OWASP ASVS ist ein umfassender Katalog von Sicherheitsanforderungen für Webanwendungen. Statt eigene Anforderungen zu erfinden, verwenden Sie ASVS als Basis.
ASVS-Struktur
ASVS gliedert Anforderungen in Kapitel:
| Kapitel | Thema | Beispielanforderungen |
|---|---|---|
| V1 | Architektur | Threat Modeling, sichere Design-Muster |
| V2 | Authentifizierung | Passwortrichtlinien, MFA, Zugangsdatenspeicherung |
| V3 | Sitzungsverwaltung | Sitzungstoken, Timeouts, Abmeldung |
| V4 | Zugriffskontrolle | Rollenbasierter Zugriff, Objektautorisierung |
| V5 | Validierung | Eingabevalidierung, Ausgabekodierung |
| V6 | Kryptografie | Algorithmenwahl, Schlüsselverwaltung |
| V7 | Fehlerbehandlung | Protokollierung, Fehlermeldungen |
| V8 | Datenschutz | Datenklassifizierung, PII-Handhabung |
| V9 | Kommunikation | TLS-Konfiguration, Zertifikatsvalidierung |
| V10 | Schädlicher Code | Abhängigkeitsintegrität, Code-Review |
| V11 | Geschäftslogik | Missbrauchsfälle, Workflow-Sicherheit |
| V12 | Dateien | Datei-Upload, Path Traversal |
| V13 | API | REST-Sicherheit, GraphQL, WebSocket |
| V14 | Konfiguration | Sicherheits-Header, Build-Härtung |
ASVS-Levels
ASVS definiert drei Verifikationsebenen:
Level 1 — Minimale Baseline Grundlegende Sicherheit für alle Anwendungen. Deckt die häufigsten Schwachstellen (OWASP Top 10) ab. Kann durch automatisierte Tests verifiziert werden.
Level 2 — Standard Empfohlen für die meisten Anwendungen, insbesondere solche mit sensiblen Daten. Erfordert einige manuelle Überprüfungen.
Level 3 — Erweitert Für sicherheitskritische Anwendungen (Banking, Gesundheitswesen, kritische Infrastruktur). Erfordert gründliche Überprüfung und fortgeschrittene Tests.
Für die meisten kleinen Unternehmen: Beginnen Sie mit Level 1 und erweitern Sie auf Level 2 für sensible Features.
Beispiele für ASVS-Anforderungen
Aus dem Bereich Authentifizierung (V2):
V2.1.1: Verify that user set passwords are at least 12 characters in length.
V2.1.5: Verify users can change their password.
V2.1.7: Verify that passwords submitted during account registration,
login, and password change are checked against a set of breached
passwords either locally or using an external API.
V2.2.1: Verify that anti-automation controls are effective at mitigating
breached credential testing, brute force, and account lockout attacks.
Jede Anforderung hat:
- Eindeutigen Bezeichner (z.B. V2.1.1)
- Klare, testbare Formulierung
- Anwendbares ASVS-Level
OWASP Cheat Sheet Series
Die OWASP Cheat Sheet Series bietet Implementierungsanleitungen für Sicherheitsthemen. Während ASVS sagt, was zu tun ist, erklären Cheat Sheets, wie es zu tun ist.
Nützliche Cheat Sheets für Entwickler:
| Thema | Cheat Sheet |
|---|---|
| Authentifizierung | Authentication Cheat Sheet |
| Passwortspeicherung | Password Storage Cheat Sheet |
| Sitzungsverwaltung | Session Management Cheat Sheet |
| Eingabevalidierung | Input Validation Cheat Sheet |
| SQL-Injection | Query Parameterization Cheat Sheet |
| XSS-Prävention | Cross Site Scripting Prevention Cheat Sheet |
| CSRF | Cross-Site Request Forgery Prevention Cheat Sheet |
| JWT | JSON Web Token Cheat Sheet |
| Datei-Upload | File Upload Cheat Sheet |
| API-Sicherheit | REST Security Cheat Sheet |
| Kryptografie | Cryptographic Storage Cheat Sheet |
| Fehlerbehandlung | Error Handling Cheat Sheet |
| Protokollierung | Logging Cheat Sheet |
Verknüpfen Sie relevante Cheat Sheets mit Ihren Anforderungen — sie werden zu Implementierungsanleitungen für Entwickler.
Weitere OWASP-Ressourcen
| Ressource | Zweck |
|---|---|
| OWASP Top 10 | Kritischste Sicherheitsrisiken für Webanwendungen |
| OWASP Testing Guide | Manuelle Testmethodik |
| OWASP SAMM | Software Assurance Maturity Model |
| OWASP Security Knowledge Framework | Schulungs- und Anforderungsplattform |
| OWASP Proactive Controls | Top 10 Sicherheitstechniken für Entwickler |
ASVS und Compliance-Frameworks
ASVS-Anforderungen decken sich mit gängigen Compliance-Standards. Wenn Sie eine Zertifizierung anstreben, gibt Ihnen ASVS einen Vorsprung:
| Compliance | Relevante ASVS-Kapitel | Hinweise |
|---|---|---|
| SOC 2 | V2, V3, V4, V7, V8, V14 | Zugriffskontrolle, Protokollierung, Datenschutz |
| PCI-DSS | V2, V3, V4, V6, V7, V8, V9 | Starke Authentifizierung, Verschlüsselung, Protokollierung |
| DSGVO | V8, V7, V6 | Datenschutz, Datenpannen-Protokollierung, Verschlüsselung |
| HIPAA | V2, V3, V6, V7, V8 | Zugriffskontrolle, Prüfpfade, Verschlüsselung |
| ISO 27001 | Alle Kapitel | Umfassende Überschneidung |
Wie das hilft:
- Wenn Prüfer fragen „wie gewährleisten Sie sichere Authentifizierung?", verweisen Sie auf V2-Anforderungen und Nachweise
- Sicherheitsfragebögen von Kunden decken sich oft direkt mit ASVS-Anforderungen
- Compliance wird zur Verifizierung bestehender Anforderungen, nicht zu einem separaten Projekt
ASVS-Tools und -Plattformen
Erfinden Sie das Rad nicht neu — es gibt Tools zur Verwaltung von ASVS-Anforderungen:
Kostenlose Tools
| Tool | Beschreibung | Link |
|---|---|---|
| OWASP ASVS Checklist | Interaktive Checkliste | GitHub |
| ASVS Excel/CSV | Herunterladbare Tabelle | ASVS GitHub |
| Security Knowledge Framework | Schulung + Anforderungs-Mapping | SKF |
| OWASP Cornucopia | Threat-Modeling-Kartenspiel | Cornucopia |
Kommerzielle Plattformen mit ASVS-Unterstützung
| Tool | ASVS-Funktionen |
|---|---|
| IriusRisk | Automatische ASVS-Anforderungen aus Threat Models |
| SD Elements | Anforderungsbibliothek enthält ASVS |
| Jira with Security Requirements Plugin | ASVS-Tracking in Jira |
| DefectDojo | Open Source, verfolgt Befunde gegen ASVS |
Anforderungen für Ihr Projekt auswählen
Sie müssen nicht alle 286 ASVS-Anforderungen sofort umsetzen. Beginnen Sie mit dem, was für Ihre Anwendung wichtig ist.
Schnellstart: Wesentliche Anforderungen
Für eine typische Webanwendung mit Benutzerkonten beginnen Sie mit diesen 25 Anforderungen:
Authentifizierung (V2)
- V2.1.1: Passwörter mindestens 12 Zeichen
- V2.1.7: Passwörter gegen bekannte Datenpannen prüfen
- V2.2.1: Rate Limiting beim Login
- V2.4.1: Passwörter mit bcrypt/argon2 gehasht
Sitzungsverwaltung (V3)
- V3.2.1: Sitzungstoken mit sicherem Zufallsgenerator erzeugt
- V3.3.1: Sitzung bei Abmeldung invalidiert
- V3.7.1: Sitzungs-Timeout implementiert
Zugriffskontrolle (V4)
- V4.1.1: Zugriffskontrolle auf dem Server erzwungen
- V4.1.2: Standardmäßig verweigern
- V4.2.1: Schutz gegen IDOR
Validierung (V5)
- V5.1.1: Serverseitige Eingabevalidierung
- V5.2.1: HTML-Eingaben bereinigen
- V5.3.1: Ausgabekodierung zur XSS-Prävention
- V5.3.4: Kontextbewusste Ausgabekodierung
Kryptografie (V6)
- V6.2.1: Nur starke Verschlüsselungsalgorithmen
- V6.4.1: Keine hardcodierten Secrets
Protokollierung (V7)
- V7.1.1: Authentifizierungsereignisse protokollieren
- V7.1.2: Zugriffskontrollfehler protokollieren
- V7.2.1: Keine sensiblen Daten in Protokollen
Datenschutz (V8)
- V8.3.1: Sensible Daten verschlüsselt gespeichert
- V8.3.4: Sensible Daten verschlüsselt übertragen
Kommunikation (V9)
- V9.1.1: TLS für alle Verbindungen
- V9.1.2: Starke TLS-Konfiguration
Konfiguration (V14)
- V14.4.1: Sicherheits-Header konfiguriert
- V14.4.3: Content-Security-Policy-Header
- V14.4.5: Strict-Transport-Security-Header
Setzen Sie diese 25 zuerst um. Sie decken die häufigsten Angriffsvektoren ab und brauchen ein kleines Team 2–4 Wochen.
Anforderungen nach Risiko priorisieren
Nicht alle Anforderungen sind gleich wichtig. Verwenden Sie eine einfache Risikobewertung:
Auswirkung (wenn Anforderung fehlt):
- Kritisch (4): Direkte Datenpanne, vollständiger Systemkompromiss, regulatorischer Verstoß
- Hoch (3): Erhebliche Datenexposition, Kontoübernahme
- Mittel (2): Begrenzte Exposition, erfordert andere Schwachstellen
- Niedrig (1): Minimale Auswirkung, Defense in Depth
Wahrscheinlichkeit (der Ausnutzung):
- Hoch (3): Häufiger Angriffsvektor, leicht ausnutzbar
- Mittel (2): Erfordert etwas Können oder spezifische Bedingungen
- Niedrig (1): Seltener Angriff, erfordert erheblichen Aufwand
Risikowert = Auswirkung × Wahrscheinlichkeit
| Wert | Priorität | Maßnahme |
|---|---|---|
| 9–12 | Kritisch | Sofort umsetzen |
| 5–8 | Hoch | Im aktuellen Sprint umsetzen |
| 3–4 | Mittel | Für nächstes Quartal planen |
| 1–2 | Niedrig | Backlog |
Beispielpriorisierung:
| Anforderung | Auswirkung | Wahrscheinlichkeit | Wert | Priorität |
|---|---|---|---|---|
| V2.4.1 Passwort-Hashing | 4 (Datenpanne) | 3 (häufiger Angriff) | 12 | Kritisch |
| V5.3.1 XSS-Prävention | 3 (Übernahme) | 3 (häufig) | 9 | Kritisch |
| V4.1.1 Serverseitige Zugriffskontrolle | 4 (Datenpanne) | 2 (erfordert Authentifizierung) | 8 | Hoch |
| V14.4.5 HSTS-Header | 2 (MITM-Risiko) | 2 (gezielter Angriff) | 4 | Mittel |
Schritt 1: Ihre Anwendung klassifizieren
Welche Daten verarbeiten Sie?
- Nur öffentliche Daten → Niedrigere Anforderungen
- Benutzer-PII → V8 (Datenschutz) ist kritisch
- Finanzdaten → V6 (Kryptografie), V2 (Authentifizierung) sind kritisch
- Gesundheitsdaten → Vollständiges V8, V2, V3, plus regulatorische Anforderungen
Was ist Ihre Angriffsfläche?
- Internes Tool → Niedrigeres externes Bedrohungsprofil
- Öffentliche API → V13 (API) ist kritisch
- Dateiverarbeitung → V12 (Dateien) ist kritisch
- E-Commerce → V11 (Geschäftslogik) ist kritisch
Schritt 2: Mit Level-1-Grundlagen beginnen
Für jede Webanwendung beginnen Sie mit diesen ASVS-Kapiteln auf Level 1:
- V2 Authentifizierung — Passworthandhabung, Sperrung
- V3 Sitzungsverwaltung — Token-Sicherheit, Ablauf
- V4 Zugriffskontrolle — Autorisierungsprüfungen
- V5 Validierung — Eingabevalidierung, Ausgabekodierung
- V14 Konfiguration — Sicherheits-Header, HTTPS
Das deckt die häufigsten Schwachstellen mit vertretbarem Aufwand ab.
Schritt 3: Feature-spezifische Anforderungen hinzufügen
Beim Bau neuer Features relevante ASVS-Abschnitte identifizieren:
| Feature | Relevante ASVS-Abschnitte |
|---|---|
| Benutzerregistrierung | V2.1 (Passwortsicherheit) |
| Login / SSO | V2.2 (Authentifizierung), V3 (Sitzungen) |
| Datei-Upload | V12.1 (Datei-Upload) |
| API-Endpunkte | V13 (API), V4 (Zugriffskontrolle) |
| Zahlungsabwicklung | V6 (Kryptografie), V8 (Datenschutz) |
| Passwort-Reset | V2.5 (Zugangsdatenwiederherstellung) |
| Admin-Panel | V4 (Zugriffskontrolle), V7 (Protokollierung) |
| Suchfunktion | V5.3 (Ausgabekodierung) |
Schritt 4: Ihre Baseline dokumentieren
Erstellen Sie ein Dokument, das die für Ihr Projekt geltenden ASVS-Anforderungen auflistet:
# Security Requirements Baseline
## Scope
This document defines security requirements for [Project Name].
## ASVS Level
Level 1 for all features, Level 2 for authentication and payment.
## Applicable Chapters
- V2 Authentication: Full
- V3 Session Management: Full
- V4 Access Control: Full
- V5 Validation: 5.1, 5.2, 5.3 only
- V7 Error Handling: 7.1 only
- V8 Data Protection: 8.1, 8.3
- V13 API Security: Full
- V14 Configuration: Full
## Excluded (with justification)
- V12 Files: No file upload functionality
- V11 Business Logic: Simple CRUD, no complex workflows
Last reviewed: [Date]
Threat Modeling und Anforderungen
Threat Modeling identifiziert was schief gehen könnte. ASVS-Anforderungen spezifizieren wie es zu verhindern ist. Beide arbeiten zusammen.
Einfaches Threat Modeling für Features
Bevor Sie ASVS-Anforderungen zu einem Feature hinzufügen, stellen Sie diese Fragen:
STRIDE für jede Komponente:
| Bedrohung | Frage | Beispielanforderung |
|---|---|---|
| Spoofing | Kann sich jemand als anderer Benutzer ausgeben? | V2, V3 (Authentifizierung, Sitzungen) |
| Tampering | Kann jemand Daten ändern, die er nicht ändern sollte? | V4, V5 (Zugriffskontrolle, Validierung) |
| Repudiation | Kann jemand seine Aktionen abstreiten? | V7 (Protokollierung) |
| Information disclosure | Kann jemand auf Daten zugreifen, auf die er keinen Zugriff haben sollte? | V4, V8 (Zugriff, Datenschutz) |
| Denial of service | Kann jemand die Verfügbarkeit beeinträchtigen? | V2.2 (Rate Limiting) |
| Elevation of privilege | Kann jemand unbefugten Zugriff erlangen? | V4 (Zugriffskontrolle) |
Für jede identifizierte Bedrohung:
- Den relevanten ASVS-Abschnitt finden
- Diese Anforderungen zum Feature hinzufügen
- Verifizieren, dass sie getestet werden
Schnelle Threat-Modeling-Vorlage
## Threat Model: [Feature Name]
### Assets
What are we protecting?
- [ ] User credentials
- [ ] User PII
- [ ] Financial data
- [ ] Business logic
- [ ] Other: ___
### Entry points
How do users interact with this feature?
- [ ] Web form
- [ ] API endpoint
- [ ] File upload
- [ ] Webhook
- [ ] Other: ___
### Trust boundaries crossed
- [ ] Internet → Web server
- [ ] Web server → Database
- [ ] Web server → External API
- [ ] User role → Admin role
### Threats identified
| Threat | Category | Mitigation | ASVS requirement |
|--------|----------|------------|------------------|
| | | | |
### Security requirements
Based on threats, apply these ASVS requirements: [List]
Anforderungen in Ihrem Workflow verfolgen
Sicherheitsanforderungen müssen wie jedes andere Arbeitselement verfolgt werden. Nutzen Sie Ihre vorhandenen Tools.
Mit Jira (oder ähnlich)
Erstellen Sie einen benutzerdefinierten Issue-Typ „Sicherheitsanforderung" mit Feldern:
| Feld | Optionen |
|---|---|
| ASVS-ID | V2.1.1, V2.1.2, usw. |
| Status | Nicht anwendbar, Nicht umgesetzt, In Bearbeitung, Umgesetzt, Verifiziert |
| Priorität | Kritisch, Hoch, Mittel, Niedrig |
| Betroffene Features | Liste der Features, auf die diese Anforderung zutrifft |
| Verifizierungsmethode | Automatischer Test, Code-Review, Penetrationstest, Manuelle Prüfung |
| Zuletzt verifiziert | Datum |
| Nachweis | Link zu Testergebnissen oder Review-Notizen |
Status-Workflow:
┌─────────────────┐
│ Not Applicable │ ← Requirement doesn't apply to this project
└────────┬────────┘
│ (applies)
▼
┌─────────────────┐
│ Not Implemented │ ← Requirement applies but isn't done
└────────┬────────┘
│ (work started)
▼
┌─────────────────┐
│ In Progress │ ← Implementation underway
└────────┬────────┘
│ (code complete)
▼
┌─────────────────┐
│ Implemented │ ← Code done, needs verification
└────────┬────────┘
│ (tested/reviewed)
▼
┌─────────────────┐
│ Verified │ ← Confirmed working
└─────────────────┘
Anforderungs-Tickets erstellen
Für jede zutreffende ASVS-Anforderung ein Ticket erstellen:
Title: [V2.1.1] Minimum password length of 12 characters
Description:
ASVS Requirement: V2.1.1
Level: 1
Requirement text:
"Verify that user set passwords are at least 12 characters in length."
Implementation notes:
- Update password validation in registration and password change flows
- Update user-facing error messages
- See: OWASP Password Storage Cheat Sheet
Acceptance criteria:
- [ ] Registration rejects passwords under 12 characters
- [ ] Password change rejects passwords under 12 characters
- [ ] Error message explains minimum length
- [ ] Automated test covers both flows
Verification method: Automated Test
Anforderungen mit Features verknüpfen
Beim Planen eines neuen Features relevante Sicherheitsanforderungen verknüpfen:
Feature: User Registration
Security requirements:
- V2.1.1: Password minimum 12 characters
- V2.1.5: Users can change password
- V2.1.7: Check passwords against breach list
- V2.1.9: No password composition rules (just length)
- V2.4.1: Bcrypt for password storage
- V5.1.1: Server-side input validation
- V7.1.1: Log authentication events
Definition of Done:
- [ ] All linked security requirements verified
Spezialisierte Tools für Sicherheitsanforderungen
Für größere Teams oder compliance-intensive Umgebungen helfen spezialisierte Tools:
GRC- und Compliance-Plattformen
| Tool | Beschreibung | Am besten für |
|---|---|---|
| Drata | SOC 2, ISO 27001 Compliance-Automatisierung | Startups mit SOC-2-Ziel |
| Vanta | Kontinuierliche Sicherheitsüberwachung + Compliance | Ähnlich wie Drata |
| Secureframe | Compliance-Automatisierung | SOC 2, HIPAA, PCI |
| Tugboat Logic | Sicherheitsassurance-Plattform | Wachsende Unternehmen |
| Hyperproof | Compliance-Betrieb | Enterprise-Compliance |
| OneTrust | GRC-Plattform | Große Unternehmen |
Threat Modeling und Anforderungen
| Tool | Beschreibung | Am besten für |
|---|---|---|
| OWASP Threat Dragon | Open-Source-Threat-Modeling | Kostenlos, entwicklerfreundlich |
| Microsoft Threat Modeling Tool | Desktop-Threat-Modeling | Microsoft-Stack |
| IriusRisk | Threat Modeling + Anforderungen | Enterprise DevSecOps |
| SD Elements | Sicherheitsanforderungen aus Design | Enterprise SDLC |
| Foreseeti | Angriffssimulation | Erweitertes Threat Modeling |
Sicherheitstestplattformen
| Tool | Beschreibung | Am besten für |
|---|---|---|
| Snyk | Entwicklersicherheitsplattform | DevSecOps, SCA |
| Checkmarx | SAST + Anforderungs-Tracking | Enterprise |
| Veracode | Sicherheitstests + Richtlinien | Enterprise |
| Contrast Security | IAST + RASP | Laufzeitschutz |
| StackHawk | DAST für Entwickler | API-Sicherheitstests |
Einfache Ansätze für kleine Teams
Tabellenkalkulation: ASVS als CSV von GitHub exportieren, auf zutreffende Anforderungen filtern, Status in Spalten verfolgen.
GitHub Issues: Issues für jede Anforderung erstellen, Labels für Status verwenden, mit PRs verknüpfen, die sie umsetzen.
Notion/Confluence: Anforderungsdatenbank mit Status, verknüpft mit Feature-Dokumentation.
Für die meisten kleinen Teams funktioniert Jira + eine Baseline-Tabelle gut. Wechseln Sie zu spezialisierten Tools, wenn Sie Compliance-Anforderungen oder Sicherheitspersonal haben.
Gebrauchsfertige Vorlagen
GitHub Issue Template (.github/ISSUE_TEMPLATE/security-requirement.md):
---
name: Security Requirement
about: Track ASVS security requirement implementation
title: '[ASVS] '
labels: security, requirement
assignees: ''
---
## ASVS Requirement
**ID:** V0.0.0
**Level:** 1 / 2 / 3
**Chapter:**
## Requirement Text
> [Paste requirement text from ASVS]
## Implementation Notes
- Where does this apply in our codebase?
- What changes are needed?
- Related cheat sheet: [link]
## Acceptance Criteria
- [ ] Requirement implemented
- [ ] Automated test written
- [ ] Code reviewed
- [ ] Verified in staging
## Verification Method
- [ ] Automated test
- [ ] Code review
- [ ] Manual testing
- [ ] Penetration test
## Evidence
[Link to test results / review / audit]
Ergänzung der PR-Vorlage (.github/pull_request_template.md):
## Security Checklist
- [ ] No secrets in code
- [ ] Input validation added for new inputs
- [ ] Output encoding for new outputs
- [ ] Access control checks in place
- [ ] Logging added for security events
- [ ] Security requirements linked: #
### Security Champion Review
- [ ] Required for: auth changes, access control, crypto, data handling
- [ ] Reviewer: @security-champion
Sicherheitsfragebögen von Kunden
Wenn Kunden oder Partner Sicherheitsfragebögen senden, macht ASVS die Beantwortung einfacher.
Häufige Fragen und ASVS-Mapping
| Fragekategorie | ASVS-Nachweis |
|---|---|
| „Wie handhaben Sie Authentifizierung?" | V2-Anforderungen + Verifizierung |
| „Wie werden Passwörter gespeichert?" | V2.4 + bcrypt-Implementierung |
| „Verschlüsseln Sie Daten im Ruhezustand?" | V6, V8.3 + Verschlüsselungsdetails |
| „Haben Sie Audit-Protokollierung?" | V7 + Protokollbeispiele |
| „Wie handhaben Sie Sitzungsverwaltung?" | V3-Anforderungen |
| „Welche Sicherheitstests führen Sie durch?" | ASVS-Verifizierungsaufzeichnungen |
| „Befolgen Sie sichere Programmierpraktiken?" | V5, V10 + SAST-Ergebnisse |
Vorbereitung auf Fragebögen
-
Eine Nachweisbibliothek erstellen:
- Für jeden wichtigen ASVS-Abschnitt ein Zusammenfassungsdokument vorbereiten
- Enthalten: Anforderungs-ID, Umsetzungsstatus, Nachweislink
-
Standard-Antwortvorlagen:
**Authentifizierungssicherheit**
We follow OWASP ASVS Level 2 for authentication (V2).
Specific controls include:
- Password minimum 12 characters (V2.1.1)
- Passwords checked against breach databases (V2.1.7)
- Bcrypt with cost factor 12 for storage (V2.4.1)
- Rate limiting on login attempts (V2.2.1)
- MFA available for all users (V2.8)
Evidence: [Link to ASVS verification records] -
Verifizierung aktuell halten:
- Fragebögen fragen nach dem aktuellen Stand
- Monatliche Reviews stellen sicher, dass Ihre Antworten korrekt bleiben
Workflow für Fragebogen-Antworten
- Fragebogen erhalten
- Fragen auf ASVS-Abschnitte mappen
- Aktuellen Verifizierungsstatus prüfen
- Antwort mit Nachweislinks schreiben
- Security Champion prüft vor Einreichung
- Im CRM/Deal-System verfolgen
Integration in den Entwicklungsworkflow
Sicherheitsanforderungen funktionieren nur, wenn sie Teil Ihrer Software-Entwicklung sind.
Die Rolle des Security Champions
Der Security Champion sollte in diesen Phasen einbezogen werden:
1. Feature-Design (vor dem Programmieren)
- Feature-Spezifikation auf Sicherheitsauswirkungen prüfen
- Zutreffende ASVS-Anforderungen identifizieren
- Sicherheitsanforderungen zum Feature-Ticket hinzufügen
- Features markieren, die Threat Modeling benötigen
2. Sprint-Planung
- Sicherheitsanforderungen in Schätzungen einbeziehen
- Features identifizieren, die vor dem Merge eine Sicherheitsprüfung benötigen
3. Code-Review
- Verifizieren, dass Sicherheitsanforderungen umgesetzt sind
- Auf häufige Schwachstellen prüfen
4. Testing
- Verifizieren, dass Sicherheitstests vorhanden sind und bestehen
- Testabdeckung für Sicherheitsanforderungen prüfen
Checkliste für Feature-Planung
Bevor ein Feature in die Entwicklung geht:
## Security Review Checklist
Feature: [Name]
Security Champion: [Name]
Date: [Date]
### Data handling
- [ ] What user data does this feature process?
- [ ] Does it introduce new PII fields?
- [ ] Does it involve file uploads?
- [ ] Does it expose data via API?
### Authentication/Authorization
- [ ] Does it require authentication?
- [ ] What authorization checks are needed?
- [ ] Does it change authentication flows?
### Applicable ASVS requirements
[List requirements with IDs]
### Threat considerations
- [ ] How could this feature be abused?
- [ ] What's the worst-case impact?
### Testing requirements
- [ ] What security tests are needed?
- [ ] Can they be automated?
### Notes
[Any special considerations]
Sicherheit in User Stories einbauen
Sicherheit in die Definition of Done aufnehmen:
As a user, I want to upload a profile picture.
Acceptance criteria:
- [ ] Only JPEG, PNG, GIF allowed (V12.1.1)
- [ ] Maximum file size 5MB (V12.1.2)
- [ ] File type validated by content, not extension (V12.1.3)
- [ ] Files stored outside web root (V12.4.1)
- [ ] Filename sanitized (V12.3.1)
Security requirements: V12.1.1, V12.1.2, V12.1.3, V12.3.1, V12.4.1
Sicherheit in CI/CD
Automatisieren, was möglich ist:
# .github/workflows/security.yml
name: Security Checks
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
# Dependency scanning (V10.3)
- name: Run Snyk
uses: snyk/actions/node@master
# SAST scanning (V10.2)
- name: Run Semgrep
uses: returntocorp/semgrep-action@v1
# Secrets detection (V6.4)
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
# Security headers check (V14)
- name: Check security headers
run: |
# Custom script to verify headers in test environment
Anforderungsabdeckung verfolgen
Sichtbarkeit in Ihre Sicherheitslage aufrechterhalten:
| Metrik | Was wird gemessen |
|---|---|
| % verifizierter Anforderungen | Fortschritt zur Baseline |
| Tage seit letzter Verifizierung | Aktualität der Sicherheitsprüfungen |
| Anforderungen pro Feature | Sicherheitsschulden in der Planung |
| Testabdeckung der Anforderungen | Automatisierungsgrad |
| Offene Sicherheitsanforderungen | Aktuelles Gap |
Sicherheitsanforderungen testen
Anforderungen sind erst fertig, wenn sie verifiziert sind.
Verifizierungsmethoden
Verschiedene Anforderungen brauchen verschiedene Verifizierungen:
| Methode | Wann verwenden | Beispiele |
|---|---|---|
| Automatisierte Tests | Wiederholbare Prüfungen | Passwortlänge, Eingabevalidierung, Sicherheits-Header |
| Code-Review | Logik und Implementierung | Zugriffskontrolle, kryptografische Nutzung |
| SAST/DAST | Breites Schwachstellen-Scanning | SQL-Injection, XSS, Fehlkonfigurationen |
| Manuelle Tests | Komplexe Szenarien | Missbrauch der Geschäftslogik, Authentifizierungsumgehung |
| Penetrationstest | Umfassende Bewertung | Alles oben + unbekannte Probleme |
Sicherheitstests schreiben
Passwortrichtlinie (V2.1.1):
def test_password_minimum_length():
# Too short - should fail
response = client.post('/register', data={
'email': '[email protected]',
'password': 'short123' # 8 chars
})
assert response.status_code == 400
assert 'password' in response.json['errors']
# Minimum length - should pass
response = client.post('/register', data={
'email': '[email protected]',
'password': 'validpassword1' # 14 chars
})
assert response.status_code == 201
Autorisierungsprüfung (V4.1.1):
def test_user_cannot_access_other_user_data():
# Create two users
user1 = create_user('[email protected]')
user2 = create_user('[email protected]')
# Login as user1
token = login('[email protected]')
# Try to access user2's data
response = client.get(
f'/api/users/{user2.id}/profile',
headers={'Authorization': f'Bearer {token}'}
)
# Should be forbidden
assert response.status_code == 403
Rate Limiting (V2.2.1):
def test_login_rate_limiting():
# Make 5 failed login attempts
for i in range(5):
response = client.post('/login', data={
'email': '[email protected]',
'password': 'wrongpassword'
})
# 6th attempt should be blocked
response = client.post('/login', data={
'email': '[email protected]',
'password': 'wrongpassword'
})
assert response.status_code == 429 # Too Many Requests
Sicherheits-Header (V14.4):
def test_security_headers():
response = client.get('/')
assert response.headers.get('X-Content-Type-Options') == 'nosniff'
assert response.headers.get('X-Frame-Options') == 'DENY'
assert 'max-age=' in response.headers.get('Strict-Transport-Security', '')
assert response.headers.get('Content-Security-Policy') is not None
ASVS-Test-Checkliste
Für jede umgesetzte Anforderung verifizieren:
## Requirement: V2.1.1 - Password minimum length
### Test coverage
- [ ] Unit test for validation function
- [ ] Integration test for registration endpoint
- [ ] Integration test for password change endpoint
- [ ] UI test for error message display
### Test cases
- [ ] Password exactly 11 characters → rejected
- [ ] Password exactly 12 characters → accepted
- [ ] Password 50+ characters → accepted
- [ ] Password with only spaces → rejected
- [ ] Unicode password → handled correctly
### Verification date
Last verified: [Date]
Verified by: [Name]
Evidence: [Link to test run]
Periodische Verifizierung
Sicherheitsanforderungen können rückfällig werden. Regelmäßige Prüfungen einplanen:
Wöchentlich (automatisiert):
- CI/CD-Sicherheitsscans
- Abhängigkeitsschwachstellen-Prüfungen
- Sicherheits-Header-Verifizierung
Monatlich (Security Champion):
- Neue Features auf Abdeckung der Sicherheitsanforderungen prüfen
- Anforderungs-Drift prüfen
- Anforderungsstatus aktualisieren
Quartalsweise (Team-Review):
- Vollständige ASVS-Baseline-Überprüfung
- Stichprobenartige Verifizierung, dass „Verifiziert"-Anforderungen noch gelten
- Ausgeschlossene Anforderungsliste aktualisieren
Jährlich (extern):
- Penetrationstest gegen ASVS-Anforderungen
- Compliance-Audit falls zutreffend
- Vollständige Anforderungsüberarbeitung
Workshop: Sicherheitsanforderungs-Tracking einrichten
Blocken Sie 3–4 Stunden.
Teil 1: Ihre Baseline erstellen (60 Minuten)
- ASVS 4.0.3 CSV von GitHub herunterladen
- In einer Tabellenkalkulation öffnen
- Für jede Anforderung markieren:
- Zutreffend / Nicht zutreffend
- Aktueller Status
- Priorität
- Als Projektbaseline speichern
Ergebnis: Tabelle mit markierten zutreffenden Anforderungen
Teil 2: Tracking einrichten (45 Minuten)
In Jira (oder Ihrem Issue-Tracker):
- Issue-Typ „Sicherheitsanforderung" erstellen
- Benutzerdefinierte Felder hinzufügen (ASVS-ID, Status, Verifizierungsmethode)
- Issues für die Top-20-Prioritätsanforderungen erstellen
- Wo zutreffend mit bestehenden Features verknüpfen
Ergebnis: Tracking-System konfiguriert, erste Anforderungen eingetragen
Teil 3: Verifizierungstests erstellen (60 Minuten)
5 Anforderungen auswählen, die „Umgesetzt" sind, und Tests schreiben:
- Automatisierten Test schreiben
- Zur Test-Suite hinzufügen
- Verifizieren, dass der Test Verstöße erkennt
- Anforderungsstatus auf „Verifiziert" aktualisieren
Ergebnis: 5 Sicherheitsanforderungen mit automatisierten Tests
Teil 4: In den Workflow integrieren (30 Minuten)
- Checklisten-Vorlage für Feature-Planung erstellen
- Sicherheits-Review-Schritt zur PR-Vorlage hinzufügen
- Monatliche Sicherheitsanforderungs-Reviews einplanen
- Den Prozess dokumentieren
Ergebnis: Aktualisierte Workflow-Dokumentation
Workshop-Checkliste
- ASVS-Baseline erstellt
- Tracking-System eingerichtet
- Top-20-Anforderungen im Tracker
- Mindestens 5 Anforderungen haben automatisierte Tests
- Feature-Planungsvorlage enthält Sicherheit
- PR-Vorlage enthält Sicherheits-Review
- Monatlicher Review geplant
Praktische Tipps
Umgang mit „Nicht zutreffend"-Anforderungen
Wenn Sie eine Anforderung als „Nicht zutreffend" markieren, dokumentieren Sie immer den Grund:
## V12.1.1 - File Upload Validation
Status: Not Applicable
Justification: Application does not accept file uploads.
Verified by: [Name]
Date: [Date]
Review trigger: If file upload feature is added, this requirement becomes applicable.
„Nicht zutreffend"-Anforderungen quartalsweise überprüfen — Features ändern sich, und zuvor ausgeschlossene Anforderungen könnten jetzt zutreffen.
Anforderungen sichtbar machen
Slack/Teams-Integration:
- Wöchentlichen Sicherheitsanforderungsstatus posten
- Warnmeldung bei Anforderungen, die länger als 2 Wochen „In Bearbeitung" sind
- Erfolge feiern, wenn Anforderungen auf „Verifiziert" wechseln
Dashboard:
- Ein einfaches Dashboard erstellen, das zeigt:
- % verifizierter Anforderungen
- Anforderungen nach Status
- Anforderungen nach Priorität
- Zeit seit letzter vollständiger Überprüfung
Sprint-Reviews:
- Sicherheitsanforderungen in Sprint-Demos einbeziehen
- Zeigen, welche Anforderungen verifiziert wurden
- Neu hinzugefügte Anforderungen hervorheben
Umgang mit Legacy-Code
Für bestehende Anwendungen ohne Sicherheitsanforderungen:
- Nicht alles auf einmal reparieren wollen — Sie werden überfordert sein
- Mit neuen Features beginnen — Anforderungen auf neuen Code anwenden
- Kritische Anforderungen zuerst angehen — V2.4 (Passwortspeicherung), V5.3 (XSS)
- Vorfälle als Auslöser nutzen — wenn Sie eine Schwachstelle finden, Anforderung hinzufügen und überall beheben
- 10–20 % der Sprint-Kapazität einplanen — kontinuierlicher Fortschritt schlägt heroische Bemühungen
Anforderungen für Drittanbieter-Integrationen
Beim Hinzufügen externer Services deren Sicherheit prüfen:
## Third-Party Security Checklist
Service: [Name]
Purpose: [What it does]
### Data handling
- [ ] What data do we send to this service?
- [ ] Is data encrypted in transit? (V9.1.1)
- [ ] Is data encrypted at rest? (V8.3.1)
- [ ] Where is data stored geographically?
- [ ] What is their data retention policy?
### Authentication
- [ ] How do we authenticate to the service?
- [ ] API keys stored in Passwork (V6.4.1)
- [ ] Keys rotated periodically (V6.4.2)
### Security posture
- [ ] SOC 2 or equivalent certification?
- [ ] Security contact available?
- [ ] Vulnerability disclosure program?
### Incident response
- [ ] How will they notify us of breaches?
- [ ] What is their SLA for security issues?
Approved by: [Security Champion]
Date: [Date]
Review date: [Annual review]
Passwork für das Anforderungsmanagement verwenden
Die Arbeit an Sicherheitsanforderungen erzeugt viele sensible Artefakte — Zugangsdaten, Schlüssel, Berichte, Audit-Nachweise. Wenn diese über Google Drive, E-Mail-Threads und individuelle Laptops verstreut sind, ist das selbst ein Sicherheitsanforderungsversagen.
Passwork ist ein Business-Passwort- und Secrets-Manager, der natürlich in diesen Workflow passt:
Sensible Sicherheitsartefakte speichern:
- API-Schlüssel für Sicherheits-Scan-Tools (SAST, DAST, SCA) — mit Ablaufverfolgung und Audit-Protokoll
- Zugangsdaten für Sicherheitstests und Staging-Konten
- Zugangsdaten für Sicherheits-Dashboards und Monitoring-Tools
- Verschlüsselungsschlüssel für sensible Sicherheitsdaten
Nach Zugangsstufe organisieren. Erstellen Sie einen dedizierten Tresor für Sicherheits-Tools mit Zugriff, der auf den Security Champion und relevante Team-Leads beschränkt ist. Passworks granulare Berechtigungen ermöglichen das Teilen spezifischer Elemente ohne den gesamten Tresor zu exponieren — nützlich, wenn ein Entwickler temporären Zugang zu einem Testkonto benötigt, aber nicht zu Produktions-Secrets.
Dokumentation anhängen. Passwork unterstützt sichere Notizen und Dateianhänge, sodass Penetrationstest-Berichte, Audit-Nachweise und Anforderungs-Genehmigungen neben den zugehörigen Zugangsdaten gespeichert werden können — nicht in einem freigegebenen Ordner mit breiterem Zugriff.
Verfolgen, wer was zugegriffen hat. Das Audit-Protokoll zeichnet jeden Zugriff, jede Änderung und jeden Export auf. Wenn eine Sicherheitsanforderung die Demonstration der Zugriffskontrolle gegenüber einem Prüfer beinhaltet, sind Passworks Protokolle direkt exportierbare Nachweise.
Beim Offboarding rotieren. Wenn ein Entwickler, der Zugang zu Sicherheits-Tool-Zugangsdaten hatte, das Unternehmen verlässt, zeigt Passwork genau, worauf er Zugriff hatte — damit Sie sofort die richtigen Zugangsdaten rotieren, nicht erst Wochen später, wenn jemand etwas bemerkt.
Häufige Fehler
Fehler 1: Alle Anforderungen, keine Priorisierung
Alle ASVS-Anforderungen auf einmal umsetzen wollen. Das Team wird überfordert, nichts wird erledigt.
Lösung: Mit Level 1 für kritische Features beginnen. Schrittweise erweitern. Manche Anforderungen sind für Ihre Anwendung wichtiger als andere.
Fehler 2: Anforderungen ohne Verifizierung
Anforderungen sind dokumentiert, aber nie getestet. Der Status zeigt „Umgesetzt" basierend auf jemandes Erinnerung.
Lösung: Jeder „Verifiziert"-Status braucht einen Nachweis — Testergebnisse, Review-Notizen oder Audit-Befunde.
Fehler 3: Sicherheit nach der Entwicklung
Security Champion prüft, nachdem das Feature gebaut ist. Änderungen sind teuer und werden überhastet.
Lösung: Security Champion in das Feature-Design einbeziehen. Sicherheitsanforderungen vor Beginn des Programmierens hinzufügen.
Fehler 4: Einmalige Übung
Anforderungs-Baseline erstellt, nie aktualisiert. Neue Features bekommen keine Anforderungen.
Lösung: Anforderungs-Review ist fortlaufend. Jedes Feature bekommt Sicherheitsanforderungen. Monatliche Reviews.
Fehler 5: Keine Entwicklerbeteiligung
Sicherheitsteam erstellt Anforderungen. Entwickler wissen nicht, dass sie existieren.
Lösung: Entwickler sollten bei der Auswahl und Umsetzung von Anforderungen helfen. Sie sollten Sicherheitstests schreiben. Gemeinsame Verantwortung.
Erklärung gegenüber der Führungsebene
Wenn jemand fragt, warum Sie Zeit mit Sicherheitsanforderungen verbringen:
„Wir implementieren einen strukturierten Ansatz zur Sicherheit mit OWASP ASVS — einem branchenüblichen Katalog von Sicherheitsanforderungen. Statt zu hoffen, dass unser Code sicher ist, definieren wir genau, was Sicherheit für unsere Anwendung bedeutet, und verifizieren, dass es umgesetzt ist. Das findet Probleme während der Entwicklung statt in der Produktion, senkt die Kosten für Sicherheitskorrekturen und liefert uns Nachweise für Compliance und Sicherheitsfragebögen von Kunden."
Kurze Version: „Wir definieren Sicherheitsanforderungen im Voraus, damit wir es beim ersten Mal richtig bauen, statt es später zu reparieren."
Selbstcheck
Anforderungs-Baseline
- OWASP ASVS heruntergeladen und geprüft
- Zutreffende Anforderungen für Ihr Projekt identifiziert
- Baseline-Dokument mit Begründungen erstellt
- Anforderungen priorisiert (kritisch, hoch, mittel, niedrig)
Tracking
- Anforderungen im Issue-System verfolgt
- Status-Workflow definiert
- Aktueller Status für jede Anforderung bekannt
Integration
- Feature-Planung enthält Sicherheitsanforderungen
- Security Champion prüft Features vor der Entwicklung
- PR-Vorlage enthält Sicherheitscheckliste
- Sicherheitsanforderungen in der Definition of Done
Verifizierung
- Automatisierte Tests für Schlüsselanforderungen
- Regelmäßiger Verifizierungsplan
- Nachweise für verifizierte Anforderungen dokumentiert
Haken Sie mindestens 10 von 13 Punkten ab, bevor Sie weitermachen.
Was als nächstes kommt
Sie haben ein Framework zur Definition und Verfolgung von Sicherheitsanforderungen. Nächstes Kapitel: Secrets-Verwaltung — Secrets aus dem Code in eine geeignete Ablage mit Rotation und Zugriffskontrolle überführen.