# 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 |