wiki/e-compliance/ims/05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md

3.2 KiB
Raw Permalink Blame History

Sichere Softwareentwicklung (Secure SDLC)

Dokumenttyp: Richtlinie Geltungsbereich: Entwicklung der PORTA-Plattform Version: 1.0 Status: Entwurf zur internen Freigabe Owner: Entwicklung Letzte Aktualisierung: 02.06.2026 Deckt ab (CACC): 100, 101, 102 Verweist auf: feature_release_bugfix.md


1. Basis

Der grundlegende Entwicklungs- und Release-Prozess (Anforderungen, Tech-Workshop mit Architektur-/Schnittstellenanalyse, Branches, Code-Review, Staging-Verifikation, Release Notes) ist in feature_release_bugfix.md dokumentiert. Dieses Dokument ergänzt die sicherheitsspezifischen Aspekte gemäss #100#102.

2. Sicherheit über den Entwicklungszyklus (#100)

Phase Sicherheitsmassnahme Status
Anforderungen Sicherheits-/Datenschutzanforderungen je Feature im Tech-Workshop berücksichtigen [ZU PRÜFEN: explizit Teil des Workshops?]
Design Bedrohungsbetrachtung bei Architekturänderungen (betroffene Daten, Schnittstellen, Drittdienste) Teilweise (Tech-Workshop prüft Abhängigkeiten zu Drittdiensten)
Implementierung Sichere Coding-Praktiken, Secrets nicht im Code (.env-Trennung) Umgesetzt
Tests & Review Code-Review (Vier-Augen), Staging-Verifikation Umgesetzt
Security-Tests SAST/DAST/Dependency-Scan in der CI/CD-Pipeline [ZU PRÜFEN: in Forgejo-Pipeline integriert?]

3. Standards und Frameworks (#101)

Standard Anwendung Status
OWASP Top 10 Berücksichtigung gängiger Web-Schwachstellen in Reviews [ZU PRÜFEN: als Review-Checkliste verankert?]
NIST / anerkannte Frameworks Orientierung [ZU PRÜFEN]

Massnahme: OWASP-Top-10-Checkliste als fester Bestandteil des Code-Reviews aufnehmen; ggf. automatisiertes SAST-Tool (z. B. Bandit für Python) in die Pipeline integrieren.

4. Keine Produktivdaten in Entwicklung/Test (#102) — WICHTIG

Direkter Konflikt mit aktueller Praxis: datenbank-handling.md (Abschnitt 3) beschreibt das Übertragen von Produktionsdaten auf die Testumgebung als regulären Use-Case. Punkt #102 verlangt jedoch ausdrücklich, dass produktive, dem Berufsgeheimnis unterliegende Daten NICHT für Entwicklung und Test verwendet werden.

Erforderliche Massnahme (Entscheidung nötig):

Option Beschreibung
A — Verbot + Anonymisierung Prod→Int-Migration nur mit vollständiger Anonymisierung/Pseudonymisierung der Inhaltsdaten. Klartext-Berufsgeheimnisdaten nie auf Int.
B — Synthetische Testdaten Entwicklung/Test ausschliesslich mit synthetischen Testdaten (poweron_test ist bereits vom Export ausgeschlossen).
C — Streng kontrollierte Ausnahme Prod-Daten auf Int nur in eng begrenzten, protokollierten Ausnahmefällen mit Kundengenehmigung.

Empfehlung für FINMA-Kontext: Option A oder B. Die aktuelle Beschreibung in datenbank-handling.md ist entsprechend anzupassen.

5. Stand der Umsetzung / Lücken

Thema Status Massnahme
SAST/DAST in Pipeline [ZU PRÜFEN] Integrieren
OWASP-Review-Checkliste [ZU PRÜFEN] Verankern
Prod-Daten in Test (#102) Konflikt Praxis ändern (Anonymisierung/synthetische Daten) + Doku anpassen