dv-civic · Codebase-Audit & Roadmap-Scorecard

Was steht, was fehlt, was kommt als Nächstes.

Ein ehrlicher Audit der dv-civic-Plattform (Stadt- & Veranstaltungsportal-as-a-Service) gegen den gebauten Stand der Plattform — nicht gegen die Doku. Jede Aussage unten ist am realen Stand geprüft. Ergebnis: ein technisch starker Pilot-Release-Candidate, dessen Weg zu General Availability nicht an Code-Qualität hängt, sondern an einer offenen Zahlungs-Integration und drei externen Prüfungen.

75 / 100
Pilot-RC
Gesamturteil
Produktionsreif als geschlossener Pilotkein GA. Mandantentrennung, Domänenlogik und Test-Gates sind auf hohem Niveau und verifiziert. Die Decke bei 75 ziehen drei Dinge ein, die nicht in der Code-Qualität liegen: die Zahlungs-Anbindung ist ein bewusst lautstark scheiternder Platzhalter (kein Echtgeld-Ticketing), und Pentest, BITV-/WCAG-Audit sowie KoSIT-Validierung stehen extern aus.
Roadmap-Phasen
7 / 7
P0–P6 codeseitig aufgebaut · 3 davon mit offenen Außen-Gates
Backend-Coverage
90,6 %
CI-Gate ≥ 85 % erzwungen · statische Analyse · umfangreiche automatisierte Tests (letzter Lauf)
Produktions-Blocker
2 + 3
2 Code (Zahlung, CSP-Härtung) · 3 externe Audits (Pentest, BITV, KoSIT)

Methodik: Prüfung jedes sicherheits- und geldrelevanten Pfads (Mandanten- und Domänenlogik, Berechtigungen, Datenmigrationen, Test- und CI-Gates). Es wurde nichts im Audit ausgeführt — Test- und Coverage-Zahlen stammen aus dem zuletzt dokumentierten CI-Lauf und sind als solche markiert. Vorgänger: ein interner Vor-Audit (Stand vor den letzten Verbesserungen).

StandVersion 1.0.0 (Pilot-RC)
UmfangGeprüft: Mandanten- und Domänenlogik, Berechtigungen, Datenmigrationen, Test- und CI-Gates über das gesamte Backend und die End-to-End-Tests.
StackEtablierter EU-hostbarer Server-Stack mit datenbankseitiger Mandantenisolation, server-gerendertem Portal und Admin-/Redaktions-Framework.
Datum12. Juni 2026

Roadmap-Scorecard — Phase für Phase

Bewertung gegen die Exit-Kriterien aus der Roadmap. „Fortschritt" misst den technischen Aufbau; ein ✅ heißt nicht automatisch GA-reif, wenn ein externes Gate (Pentest, Audit, KoSIT) oder eine Echtgeld-Integration noch aussteht.

PhaseInhalt & Exit-KriteriumFortschrittStatus
0 Fundament. Projektaufbau, CI/CD, Mandanten-Kern (die Trennung wird auf Datenbankebene erzwungen — zweite Verteidigungslinie, sodass selbst ein App-Fehler kein Cross-Tenant-Leck verursacht), Auth inkl. Passkeys, eigenes Designsystem, Coverage-Gate.
Exit: Demo-Mandant über Subdomain + Auto-TLS, Isolations-Tests grün, CI blockt < 85 %.
100 % Erfüllt
1 Content-Core. Artikel/Seiten/Kategorien/Tags, Redaktions-Workflow mit V.i.S.d.P.-Freigabe (§ 18 MStV), Rich-Text-Editor, Admin-/Redaktions-Panel mit Mandanten-Trennung, server-gerendertes Portal mit News, strukturierten SEO-Daten, Sitemap, Volltext-Such-Dienst.
Offen: Medien-Pipeline (moderne Bildformate, responsive Auslieferung) bewusst deferred. Performance-Ziel nicht im Audit gemessen.
95 % Erfüllt
2 Verzeichnis & Karten. Gastro-/Business-Modell, Claim-Prozess, Karten-Stack ohne Consent-Banner, Bewertungen, DSA-Moderation (Art. 16 Meldeweg + Mail, Art. 17 Begründung).
Offen: Tourismus-Seitentypen (geplant, nicht gebaut). Self-hosted Geocoding nicht im Audit verifiziert.
90 % Erfüllt
3 Events & Ticketing. schema.org-Eventmodell, ICS-Feeds, barrierearmer Checkout mit korrekter Kontingent-Sperrung (kein Oversell), PDF-Tickets mit QR, Ticket-Mail, Einlass-Check-in im Admin-Bereich.
Blockiert: Anbindung an den Zahlungsdienstleister (Onboarding + Auszahlung + Erstattung) ist ein Platzhalter (nur Test-/Fake-Anbieter). Offline-fähiger Check-in & Open-Data-API verschoben.
70 % Teilweise
4 SaaS-Schicht. Self-Service-Onboarding, Theming (Token-Editor), Custom-Domain-Flow mit DNS-Verifikation → On-Demand-TLS, Plan-/Feature-Gating, XRechnung-Lauf (Leitweg-ID).
Offen: KoSIT-Validierung (extern), Mail-/Newsletter-Versanddienst, Consent-Management, SSO-Spike. SEPA gestrichen (YAGNI).
65 % Teilweise
5 Hardening. Audit der datenbankseitigen Mandantenisolation + automatisierte Angriffspfad-Tests, Onsale-Lasttest mit echten parallelen Käufern, Security-Header, token-geschützter Deep-Health-Check, Backup-/Restore-Tooling + DR-Runbook.
Offen: externer Pentest, BITV-/WCAG-2.2-Audit, Content-Security-Policy-Härtung, Statuspage.
55 % Teilweise
6 Pilot & GA. Idempotentes Bestandsdaten-Import-Werkzeug (mit Dry-Run), Go-Live-Preflight-Check, Go-Live-Checkliste, Release-Runbook.
Offen: realer Pilotbetrieb, LOI/zahlender Kunde (Roadmap-Gate), Owner-Freigabe. GA nicht erreicht.
40 % Teilweise
Strategisches Schnittprinzip eingehalten
Die Roadmap schneidet P1–P3 so, dass nach Phase 3 ein eigenständig verkaufbares Event-Modul („Variante B") existiert. Das ist technisch erreicht — mit einer Einschränkung: der Echtgeld-Verkauf hängt am Zahlungs-Platzhalter. Das Modul ist demonstrierbar und pilotfähig, aber noch nicht geld­führend.

Gewichtete Scorecard nach Kategorie

Acht Kategorien, gewichtet nach Risiko und Geschäftsrelevanz. Vergleich gegen den Vor-Audit (68/100): Code-Qualität und Sicherheit deutlich hoch, Decke weiter durch Zahlungs-Platzhalter und Außen-Gates begrenzt.

#KategorieGewichtScoreBelegt durch
1Tenancy & Isolation20 %9,5Der Mandanten-Kern erzwingt die Trennung auf Datenbankebene als zweite Verteidigungslinie — selbst Raw-Inserts werden mandanten-gestempelt, die App-Rolle kann die Isolation nicht umgehen (auch in CI). Durch automatisierte Angriffspfad-Tests abgedeckt.
2Produktions-Runtime15 %6,5Domain-Cache-Bug behoben (Skalar-Array statt Model), eigener Hintergrund-Verarbeitungsdienst, Ticket-Mail asynchron. Gedeckelt: Echtgeld-Ticketing blockiert durch Zahlungs-Platzhalter.
3Security / AuthZ / AppSec15 %8,0Rollenbasierte Berechtigungen für alle Admin-Bereiche (Bestellungen/PII + Domains nur Admin, Ticket-Preise nur Admin), TOTP-MFA-Pflicht, Registrierungs-Gate, Security-Header, Rate-Limits, tokengeschützter Domain-Verifikations-Endpunkt mit Cache. Offen: Content-Security-Policy, Stored-XSS-Fläche (Pentest).
4Domänenlogik-Korrektheit12 %9,0Die Kauf-, Einlass- und Rechnungslogik arbeitet mit korrekter Sperrung gegen Überverkauf und Doppelscan, mit sauberem Rollback bei Zahlungsfehlern und idempotenter Rechnungserzeugung (Leitweg-ID). Alle getestet.
5Payments / Ticketing-Produktionspfad10 %2,0Die Zahlungs-Anbindung ist ein bewusst lautstark scheiternder Platzhalter — keine Anbindung, keine Webhooks, keine Erstattung, kein Onboarding. Die Integration ist noch offen. Nur der Test-/Fake-Anbieter funktioniert.
6Backend-Tests & Gates10 %9,0Umfangreiche automatisierte Tests, Coverage-Gate ≥ 85 % (zuletzt 90,6 %), statische Analyse, Code-Style-Gate. CI gated zusätzlich auf Abhängigkeits-Sicherheitsscans und Secret-Scanning.
7E2E / a11y / Frontend-Tests8 %6,5End-to-End-Tests der kritischen Flows inkl. Checkout, plus automatisierter Barrierefreiheits-Testlauf, gegen einen geseedeten Stack mit aktiver Hintergrund-Verarbeitung. Komponenten-Tests inkl. Ticket-Checkout. Frontend-Coverage noch dünn.
8Compliance-Umsetzung10 %7,5DSA Art. 16 Eingangs-Mail + Art. 17 Begründung (jetzt zuverlässig zustellbar), V.i.S.d.P.-Gate (AI Act/MStV), XRechnung. Offen: externer BITV-Test, Consent-Management, KoSIT.
Gewichtet100 %7,5≈ 75 / 100. Vorher 68/100. Anstieg aus Berechtigungs-, Verarbeitungs-, Cache- und E2E-Arbeit; Decke unverändert durch Zahlungs-Platzhalter und offene Außen-Gates.

Befund-Status — F1 bis F12

Die zwölf Befunde des Vor-Audits, am aktuellen Stand nachverifiziert. Erfreulich: F1 und F2 (die beiden 🔴-Befunde) waren bereits vor dem Audit-Stand behoben; der Vor-Audit lief gegen einen veralteten Stand. Sieben weitere wurden seither umgesetzt.

IDBefundStatus heuteBeleg
F1🔴 Domain-Auflösung cachte ein Datenbank-Objekt — der Prod-Cache verweigert ObjektebehobenCache hält nur noch Skalar-Werte; Rehydrierung beim Lesen. Durch Regressionstest abgedeckt.
F2🔴 Gequeute (DSA-)Mails ohne VerarbeitungsdienstbehobenEigener Hintergrund-Verarbeitungsdienst, auch im CI-E2E-Lauf aktiv. Durch Test abgedeckt.
F3🟠 Rollenbasierte Berechtigungen deckten nur einen Teil der Admin-BereichebehobenBerechtigungen für alle Admin-Bereiche; Bestellungen/Domains nur Admin, Ticket-Preise schreiben nur Admin, Content abgestuft (Viewer/Editor/Admin). Durch Test abgedeckt.
F4🟠 Offene Registrierung + Self-Service-Mandant ohne VerifikationbehobenEin abschaltbares Registrierungs-Gate (Default aus) sperrt Registrierung und Self-Service-Anlage. Durch Test abgedeckt.
F5🟡 Bestell-Kennung als einzige Capability für Bestellseite/Ticket-PDFgehärtetRate-Limit + striktes No-Store-Caching auf beiden Routen. Capability-Modell bewusst belassen; F7 entschärft Verlustfall.
F6🟡 Lücke zwischen Zahlung und Bestätigung ohne AbgleichoffenGehört zur noch offenen Zahlungs-Integration (Webhooks + Abgleich). Mit Fake-Anbieter kein reales Risiko.
F7🟡 Keine Ticket-Zustellung per MailbehobenTicket-Mail asynchron, PDF im Hintergrund erzeugt. Durch Test abgedeckt.
F8🟡 Domain-Verifikations-Endpunkt ungecacht + Hostnamen-OrakelbehobenCache mit kurzer TTL und Invalidierung bei Domain-Änderung + tokengeschützter Endpunkt (ohne Token nicht ansprechbar).
F9🟡 Bewertungen gehen ungebremst & unmoderiert livegehärtetHoneypot (stille Verwerfung) + Flood-Limit pro Ort/IP/Tag. Publish-on-arrival bleibt (DSA notice-and-action).
F10🟡 Keine Content-Security-PolicyoffenNoch zu verdrahtende Content-Security-Policy. Bleibt Pentest-Vorbedingung, im Code ehrlich vermerkt.
F11⚪ Stored-XSS-Fläche (Admin-Renderer)offenBelastbar nur im Pentest prüfbar; die CSP (F10) wäre der Backstop.
F12⚪ Kleinigkeiten (Optional-Hacks, Sitemap-Bound, Ticket-Code-Alphabet)teilweiseBeide Optional-Fallbacks im Frontend entfernt; No-Store gesetzt. Sitemap-Bound & Code-Alphabet bewusst belassen (begründet).

Was der Audit als echt stark befunden hat

Defense-in-depth bei der Mandantentrennung
Der Mandanten-Kern erzwingt die Trennung auf Datenbankebene als zweite Verteidigungslinie — selbst Raw-Inserts werden mandanten-gestempelt, und die App-Rolle kann die Isolation nicht umgehen, weder in Dev noch in CI. So verursacht selbst ein App-Fehler kein Cross-Tenant-Leck. Lehrbuch.
Korrekter Reserve→Charge→Confirm-Kauf
Die Kauflogik hält die Sperre minimal (Codes außerhalb der Transaktion vorerzeugt) und rollt bei Zahlungsfehler das Kontingent sauber zurück — verifiziert durch einen echten parallelen Concurrency-Lasttest. Kein Oversell.
Hintergrund-Verarbeitung gegen die subtilen Fallen
Die Hintergrund-Verarbeitung (Mail, PDF) rebindet den Mandantenkontext korrekt: Skalar-Mandanten-ID, Rebind vor Lauf, Wiederherstellung des vorherigen Kontexts nach Sync-Dispatch — genau die Failure-Modes, vor denen die Tenancy-Doku warnt.
Code, der die Wahrheit sagt
Die Zahlungs-Anbindung scheitert lautstark statt zu tun-als-ob; die offene CSP, die Cache-Begründung und das Capability-Modell sind im Code ehrlich kommentiert. Selbst dort, wo die Doku einmal hinterherhinkte, log der Code nicht.

Produktions-Blocker bis GA — geordnet

#BlockerArtWas es braucht
1Zahlungs-Integration (Zahlungsdienstleister)CodeAnbindung, signierte + idempotente Webhooks, Onboarding, Erstattungen, Abgleich (schließt F6). Ohne dies kein Echtgeld-Ticketing.
2Content-Security-Policy (F10/F11)CodeNoch zu verdrahtende CSP als AppSec-Härtung; backstoppt die Stored-XSS-Fläche vor dem Pentest.
3Externer PentestExternSchwerpunkt Mandanten-Isolation; ohne offene High/Critical + bestandener Re-Test (gemäß Pentest-Auftrag). ~8–15 k€.
4BITV-/WCAG-2.2-AuditExternExterne Prüfung + Behebung; der automatisierte Barrierefreiheits-Testlauf ist die Vorarbeit, ersetzt aber kein Zertifikat. ~5–10 k€.
5KoSIT-Validierung der XRechnungExternDer Rechnungslauf existiert (Leitweg-ID); die KoSIT-Konformität muss validiert werden.
6Kommerzielles Gate (Roadmap)BusinessLOI/Vorvertrag eines zahlenden Pilotkunden + Owner-Freigabe. Harte Roadmap-Regel, kein Code.
7Vertriebs-/RechtsdokumenteRechtAVV, TOMs, SLA, Subprozessorenliste — anwaltlich geprüft. Mail-Versanddienst/Consent-Management/SSO nach Bedarf.

Launch-Checkliste — Soll-Stand-Spiegel

Aus der Launch-Checkliste. Erledigt = im Code/CI nachweisbar; offen = Außen-Gate oder Integration.

Erledigt & verifiziert
9
Berechtigungen, MFA, Reg-Gate, Isolations-Tests, CI-Sicherheits-Scans, Hintergrund-Verarbeitung, Cache, Ticket-Mail, DSA-Mails
Offen — Integration/Code
2
Echtgeld-Zahlung + Erstattung · CSP
Offen — extern/Business
6
Pentest · BITV · KoSIT · Restore-Drill-Nachweis · Statuspage/Alerts live · LOI + Owner-Freigabe

Empfehlung — „follow next time"

Die Reihenfolge, die den meisten Risiko-Abbau pro Aufwand bringt
  1. CSP verdrahten (F10/F11). Kleiner Code-Change, schließt die letzte offene AppSec-Lücke vor dem teuren Pentest — sonst wird sie ein Finding. Reihenfolge zählt: erst CSP, dann Pentest beauftragen.
  2. Zahlungs-Integration bauen. Der einzige Code-Blocker, der „verkaufbares Event-Modul" von „geld­führendes Event-Modul" trennt. Webhooks + Abgleich gleich mitdenken (schließt F6). Davor lohnt kein GA-Termin.
  3. Frontend-Testabdeckung anheben. Die Frontend-Tests sind dünn für einen Checkout, der Geld bewegt. Ziel 80 % besonders auf Checkout-Pfaden, bevor Echtgeld fließt.
  4. Externe Gates parallel terminieren. Pentest (nach CSP), BITV-Audit, KoSIT-Validierung haben Vorlaufzeiten — Slots jetzt buchen, nicht erst wenn der Code „fertig" ist. ~23–45 k€ Budget einplanen.
  5. Betriebsnachweise einsammeln. Restore-Drill unter RTO dokumentieren, Monitoring/Alerts/Statuspage live schalten, Zero-Downtime-Deploy + Rollback auf Prod verifizieren.
  6. Kommerzielles Gate respektieren. Kein Phase-2+-Vollausbau ohne LOI eines zahlenden Pilotkunden — die Roadmap-Regel ist die wichtigste Zeile im ganzen Plan.

Kurz und ehrlich

Erstellt am 12. Juni 2026 — Codebase-Audit dv-civic
Quelle: Prüfung des gebauten Plattform-Stands
Test-/Coverage-Zahlen aus dem zuletzt dokumentierten CI-Lauf