Diese Checkliste stellt sicher, dass sicherheitsrelevante Maßnahmen während der Entwicklung konsequent umgesetzt und nachweisbar dokumentiert werden. Verknüpfe jeden Schritt mit eurem Ticket-System, zum Beispiel SEC-DEV-<nummer>.

Durchgehende Umsetzungsschritte #

1. Freigegebene Toolchain verwenden und patchen #

   • Maßnahmen: Stützt euch auf die freigegebenen Techstack und prüft Sicherheitsupdates mindestens monatlich.
   • Pause im Projekt? Spätestens nach vier Wochen ohne Pipeline-Lauf: Reminder (Kalender/Jira-Task) setzen und manuelle Updatescans via npm outdated, mvn versions:display-dependency-updates, pip list --outdated oder trivy fs . ausführen.
   • Dokumentiert Ergebnisse im Security-Report oder docs/logging.md.
   • Nachweis: Paket-Update-Protokoll oder Release Notes im Sprint-Report.

   Annex A.8.28 verlangt, dass nur genehmigte Komponenten verwendet und aktuell gehalten werden.

2. Bedrohungsmodell während der Umsetzung pflegen #

   • Maßnahmen: Aktualisiert das Threat Model bei Architektur- oder Feature-Änderungen, dokumentiert Risiken und Gegenmaßnahmen.
   • Hinweis: Nutzt STRIDE-Tabellen oder aktualisierte Mermaid-Diagramme als docs/threat-model-v1.md.
   • Nachweis: Verlinktes Modell im Architektur- oder Security-Ticket.

   Threat Modeling ist nicht explizit vorgeschrieben, erhöht aber den Nachweis für “Security by Design” und reduziert Audit-Risiken.

3. Architektur-Patterns & AuthN/AuthZ umsetzen #

   • Maßnahmen: Dokumentiert Schichten, Services und Protokolle (siehe Architektur-Review Vorlage). Verlinkt AuthN und AuthZ Vorgaben. Security Champion prüft die Entscheidungen und der Eskalationsbedarf wird festgehalten.
   • Nachweis: docs/auth.md oder vergleichbares Dokument mit Kommentaren des Security Champions.

   Annex A.8.28 fordert nachvollziehbare Architekturentscheidungen, insbesondere zu Authentifizierung und Autorisierung.

4. Validierung, Fehlerbehandlung, Logging und Monitoring implementieren #

   • Maßnahmen: Validierungsbibliotheken einsetzen, Output-Encoding anwenden, generische Fehlertexte verwenden und Logging konfigurieren.
   • Nachweis: Logging-Konzept abgelegt im Repository /docs/logging.md, ausgerichtet an Logging nach OWASP-Empfehlung.

   Ohne robuste Validierung und Logs fehlen Nachweise für sichere Programmierung sowie Incident Response.

5. Automatisierte Scans in CI/CD ausführen und Findings schließen #

   • Maßnahmen: Siehe Scans in CI/CD und integriert SAST (z. B. semgrep), SCA-Scans (npm audit) sowie Container- oder IaC-Scanner (trivy). Setzt harte Schwellenwerte und bearbeitet Findings zeitnah.
   • Übergabe: Findings mit Schweregrad “hoch” oder höher sofort als Task in den laufenden Sprint übergeben; mittlere/geringe Findings bündeln und spätestens zum Sprintwechsel priorisieren.
   • Corrective Action Log: Pflicht, wenn ein hohes/critical Finding nicht im aktuellen Sprint behoben wird, wenn Auditoren/Kunden Nachweise verlangen oder wenn wiederkehrende Befunde auftreten. Siehe Corrective Action Log.
   • Nachweis: Pipeline-Logs und Tickets, die die Behebung der Sicherheitsbefunde dokumentieren.

   Annex A.8.29 verlangt automatisierte Sicherheitstests. Offene Findings führen zu Audit-Beanstandungen.

6. Konfigurationen und IaC härten und versionieren #

   • Maßnahmen: Haltet Infrastruktur- oder Deployment-Konfigurationen im Repo (z. B. Terraform, Helm, Ansible) und sorgt für sichere Defaults (TLS, keine Klartext-Secrets).
   • Mindestprüfung: Führt pro Release einen Policiescan wie trivy config, tflint oder kube-score aus und dokumentiert das Ergebnis im Ticket.
   • Kein IaC? Legt eine kurze Baseline docs/config-baseline.md an (Ports, Auth, Secrets), siehe Vorlage, und stimmt sie mit dem Betriebsteam ab, damit Audit-Fragen beantwortet werden können.
   • Nachweis: Scan-Report oder kommentierte Baseline-Datei mit Freigabe des Security Champions.

   Unsichere Deployment-Skripte gefährden kontrollierte Änderungen und verletzen Annex A.8.28.

7. Ausnahmen mit Risiko und Laufzeit dokumentieren #

   • Maßnahmen: Ausnahme-Tickets mit Risiko, Owner und Ablaufdatum anlegen sowie im Security-Backlog nachverfolgen.
   • Nachweis: Genehmigte Ausnahmedokumente oder Jira-Issues mit Review-Datum.

   Auditoren erwarten vollständige Nachweise zu Abweichungen inklusive Risikobewertung und Frist.