Security Scanning: SAST + Secret Detection vor MR-Erstellung #23

New issue

Open

opened 2026-03-30 19:46:32 +00:00 by David · 0 comments

David commented

2026-03-30 19:46:32 +00:00

Collaborator

Beschreibung

Vor jeder MR-Erstellung automatisch Security-Scans (SAST + Secret Detection) auf dem generierten Diff ausführen. Kritische Findings blockieren den MR.

Hintergrund

Laut Veracode (2025) enthält 45% von AI-generiertem Code Security-Flaws. AI-generierter Code hat 1.7x mehr logische/Correctness-Bugs als menschlicher Code. Ohne Security-Scanning landen diese Schwachstellen direkt in GitLab MRs und potenziell in Produktion.

Akzeptanzkriterien

bandit (Python) oder semgrep (polyglot) wird auf den Diff jedes generierten Branches ausgeführt
gitleaks oder detect-secrets prüft auf versehentlich committete Secrets
Kritische Findings (High/Critical Severity) blockieren die MR-Erstellung
Medium Findings werden als Labels/Kommentare am MR angehängt
Scan-Ergebnis wird im Ticket gespeichert und im Dashboard angezeigt
Scanner sind konfigurierbar pro Repo (verschiedene Tech-Stacks brauchen verschiedene Scanner)
False-Positive-Suppression über .security-ignore Datei im Repo möglich

Technische Hinweise

Neuer Service: backend/services/security_scanner.py
Erweitern: backend/services/pipeline.py — Security-Scan zwischen Test-Verifikation und git push
Erweitern: backend/models/ticket.py — security_scan_result (JSON), security_scan_passed (Bool)
Erweitern: backend/models/repo.py — security_scanner (String: bandit/semgrep), security_rules (JSON)
Dependencies: bandit, semgrep, gitleaks (als CLI-Tools im Container/System)
Migration nötig: ja (neue Felder)

Aufwand: M

## Beschreibung Vor jeder MR-Erstellung automatisch Security-Scans (SAST + Secret Detection) auf dem generierten Diff ausführen. Kritische Findings blockieren den MR. ## Hintergrund Laut Veracode (2025) enthält 45% von AI-generiertem Code Security-Flaws. AI-generierter Code hat 1.7x mehr logische/Correctness-Bugs als menschlicher Code. Ohne Security-Scanning landen diese Schwachstellen direkt in GitLab MRs und potenziell in Produktion. ## Akzeptanzkriterien - [ ] `bandit` (Python) oder `semgrep` (polyglot) wird auf den Diff jedes generierten Branches ausgeführt - [ ] `gitleaks` oder `detect-secrets` prüft auf versehentlich committete Secrets - [ ] Kritische Findings (High/Critical Severity) blockieren die MR-Erstellung - [ ] Medium Findings werden als Labels/Kommentare am MR angehängt - [ ] Scan-Ergebnis wird im Ticket gespeichert und im Dashboard angezeigt - [ ] Scanner sind konfigurierbar pro Repo (verschiedene Tech-Stacks brauchen verschiedene Scanner) - [ ] False-Positive-Suppression über `.security-ignore` Datei im Repo möglich ## Technische Hinweise - Neuer Service: `backend/services/security_scanner.py` - Erweitern: `backend/services/pipeline.py` — Security-Scan zwischen Test-Verifikation und git push - Erweitern: `backend/models/ticket.py` — `security_scan_result` (JSON), `security_scan_passed` (Bool) - Erweitern: `backend/models/repo.py` — `security_scanner` (String: bandit/semgrep), `security_rules` (JSON) - Dependencies: `bandit`, `semgrep`, `gitleaks` (als CLI-Tools im Container/System) - Migration nötig: ja (neue Felder) ## Aufwand: M