Prädikat is_security_reviewed
Ein Tresor kann noch so stabil gebaut sein - wenn niemand prüft, ob er richtig verschlossen ist, nützt er wenig. Das Prädikat is_security_reviewed stellt sicher, dass Sicherheitsaspekte nicht nur implementiert, sondern auch überprüft wurden.
Sicherheit ist kein Zufall
Entwickler machen Fehler. Selbst erfahrene Programmierer übersehen manchmal SQL-Injection-Lücken oder vergessen, Passwörter zu hashen. Das Prädikat is_security_reviewed sorgt dafür, dass ein zweites Augenpaar - Mensch oder KI - die sicherheitsrelevanten Aspekte prüft.
Vollständiges Beispiel
Definition des Security-Review-Prädikats:
# Prädikat: is_security_reviewed
# Verwendet in: Gate G5 (Review), Gate G6 (Release)
predicate:
id: "is_security_reviewed"
name: "Security Review durchgeführt"
description: "Prüft, ob alle sicherheitsrelevanten Änderungen reviewed wurden"
category: "security"
severity: "critical"
# Wann wird es ausgelöst?
triggers:
- file_patterns:
- "**/*Auth*.php"
- "**/*Security*.php"
- "**/api/**"
- "**/config/credentials*"
- change_types:
- "authentication"
- "authorization"
- "encryption"
- "input_validation"
- change_class:
- "critical"
# Was wird geprüft?
checks:
- id: "sast_scan"
name: "Static Application Security Testing"
tool: "semgrep"
rules: "owasp-top-10"
max_findings:
critical: 0
high: 0
medium: 5
- id: "dependency_audit"
name: "Dependency Vulnerability Check"
tool: "composer audit"
max_vulnerabilities:
critical: 0
high: 0
- id: "secrets_scan"
name: "Secrets Detection"
tool: "gitleaks"
findings_allowed: 0
- id: "human_review"
name: "Security Team Review"
required_for:
- change_class: "critical"
- file_pattern: "**/payment/**"
reviewers:
team: "security-team"
min_approvals: 1
# Erfolgskriterien
success_criteria:
all_scans_pass: true
no_critical_findings: true
human_approval_where_required: true
Auswertung in der Praxis
# Security Review Ergebnis
evaluation:
predicate_id: "is_security_reviewed"
change_id: "CHG-2024-0044"
change_class: "critical"
evaluated_at: "2024-01-15T17:00:00Z"
check_results:
- check_id: "sast_scan"
passed: true
details:
tool: "semgrep"
rules_checked: 247
findings:
critical: 0
high: 0
medium: 2
low: 5
medium_findings:
- rule: "php.lang.security.injection.tainted-sql-string"
file: "src/Repository/UserRepository.php"
line: 45
status: "false_positive"
reason: "Query uses parameter binding"
- check_id: "dependency_audit"
passed: true
details:
packages_checked: 142
vulnerabilities:
critical: 0
high: 0
medium: 1
low: 3
- check_id: "secrets_scan"
passed: true
details:
files_scanned: 347
secrets_found: 0
- check_id: "human_review"
passed: true
details:
reviewer: "alice@security-team"
approved_at: "2024-01-15T16:45:00Z"
comments: "LGTM - Input validation korrekt implementiert"
result: true
evidence:
sast_report: "reports/semgrep-2024-0044.json"
audit_report: "reports/composer-audit-2024-0044.json"
approval_record: "reviews/security-approval-2024-0044.json"
Warum ist das wichtig?
Das Prädikat is_security_reviewed ist die letzte Verteidigungslinie vor der Produktion. Es kombiniert automatische Scans mit menschlicher Expertise und stellt sicher, dass Sicherheit nicht dem Zufall überlassen wird.
Im Mensch + KI-Code Prozess: Bei Change Class "Normal" reicht der automatische Scan. Bei "Critical" ist zusätzlich ein menschlicher Security-Review erforderlich. Das Prädikat ist am Gate G5 (Review) und G6 (Release) obligatorisch.