9f5f8bfc11
Includes CACC/FINMA legal processes, updated AGB with PowerOn AG stammdaten, and internal legal and best-practice analysis report. Co-authored-by: Cursor <cursoragent@cursor.com>
57 lines
3.2 KiB
Markdown
57 lines
3.2 KiB
Markdown
# 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 |
|