Skip to content

Security-Grundsätze

Die Software verarbeitet besonders schützenswerte Daten (Sozialdaten nach SGB VIII, Daten von Kindern). Security ist daher nicht optional, sondern integraler Bestandteil jeder Änderung. Die Leitlinien folgen ISO 27001.

Keine E-Mail-Adressen, Telefonnummern, Namen, Adressen oder Geburtsdaten in console.log, logger.* oder Test-Output. Für Log-Ausgaben existiert ein PII-Masking-Utility.

Jeder API-Endpunkt validiert eingehende Daten vollständig (class-validator / DTOs). Ungültiger Input wird früh abgelehnt.

  • Keine String-Interpolation in SQL-Queries — ausschließlich parameterisierte Queries über Prisma.
  • Keine Path-Traversal: Datei-Operationen mit Benutzer-Input erfordern Path-Sanitization.
  • Kein eval() oder sonstige dynamische Code-Ausführung.
  • Niemals Secrets, Tokens oder Passwörter im Code oder in committed Dateien.
  • Lokale Entwicklung: .env-Dateien (gitignored).
  • Produktiv: Secrets werden über den Deployment-Prozess bereitgestellt.

Besonders schützenswerte Felder werden zusätzlich auf Feldebene verschlüsselt (AES-256-GCM). Verschlüsselte Werte sind am Präfix enc:v1: erkennbar.

Die Pipeline enthält mehrere Fail-Gates:

  • SAST (Semgrep) mit projektspezifischen Regeln — u. a. gegen hardcodierte Secrets, PII in Logs und Cross-Modul-Imports.
  • Secret-Scan (Gitleaks) über die gesamte Git-Historie.
  • Dependency-Scans (Trivy, pnpm audit) für HIGH/CRITICAL-Findings.
  • DAST (OWASP ZAP Baseline) gegen die Demo-Umgebung.

Suppressions sind nur mit Begründung und Review-Datum erlaubt — keine Pauschal-Ausnahmen.

Sicherheitsrelevante Fundstellen (z. B. potenzielle Datenlecks, fehlende Validierung) werden proaktiv gemeldet und dokumentiert — auch wenn sie außerhalb der aktuellen Aufgabe liegen.