bd65b6f318
CI / guardrail-integrity (push) Has been skipped
CI / secret-scan (push) Has been skipped
CI / dep-audit (push) Has been skipped
CI / sbom-scan (push) Has been skipped
CI / go-lint (push) Has been skipped
CI / python-lint (push) Has been skipped
CI / nodejs-lint (push) Has been skipped
CI / nodejs-build (push) Has been skipped
CI / test-go (push) Failing after 59s
CI / detect-changes (push) Successful in 10s
CI / branch-name (push) Has been skipped
CI / validate-canonical-controls (push) Successful in 15s
CI / loc-budget (push) Failing after 19s
CI / iace-gt-coverage (push) Successful in 27s
CI / test-python-backend (push) Successful in 42s
CI / test-python-document-crawler (push) Has been skipped
CI / test-python-dsms-gateway (push) Has been skipped
P54 — consent_diff_for_user.py: USP-Feature fuer wiederkehrende Besucher. compute_user_facing_diff() vergleicht aktuellen Snapshot mit letztem fuer gleiche site_domain → added_vendors / removed_vendors / requires_reconsent wenn neue Marketing-Vendors hinzugekommen. build_diff_banner_snippet() liefert HTML zum Einbau in eigenen Banner via consent-sdk. P68 — reverse_audit.py: Self-Audit unserer Template-Bibliothek. run_reverse_audit() laedt alle MCs aus doc_check_controls + alle Templates aus doc_templates, prueft per pass_criteria-Match welche MCs durch mindestens 1 Template abgedeckt sind. Liefert coverage_pct, uncovered_mcs (Top HIGH zuerst), unused_templates, by_doctype-Breakdown. P69 — data/ecall_regulation.json: eCall-VO (EU) 2015/758 als 7 Chunks fuer RAG-Ingest (Art. 3/6/7 + compliance_implications fuer Automotive-OEMs). Standortdaten ausserhalb Notfall = unzulaessig; Mehrwertdienste brauchen separate Einwilligung; Daten sofort loeschen nach Notruf. P6+P53+P55 — industry_library.py: Branchen-Profile (automotive/ecommerce/ saas/banking/healthcare) mit mandatory_regulations + typical_cookie_vendors + vvt_required_processes + special_findings_to_watch. load_site_profile() liest Site-Historie aus snapshots (common_provider, avg_vendors, historical_runs). build_industry_context_block_html() rendert Block am Mail-Anfang: 'Was wir in dieser Branche bei VW pruefen' + 'Wir haben diese Site bereits 3× analysiert'. P31 — llm_cascade.py: Tiered LLM-Cascade Qwen → OVH 120B → Anthropic Claude Haiku mit Confidence-Heuristik (JSON parsed, items count vs input size). Valkey-Cache (redis://) mit 7-Tage-TTL plus In-Process- Fallback. Wenn Tier-1 unter Confidence-Threshold → Tier-2, dann Tier-3. Reduziert Lauf-Zeit drastisch bei Re-Runs. P80 v2 — check_replay.py: replay nutzt jetzt audit_quality_checks mit den Snapshot-Daten. Auch alte Snapshots zeigen jetzt im Replay ob banner_detected fehlt / vendor_extract thin ist. Bonus — P90 BMW-Final markiert completed: alle B1-B4 Bugs gefixt (cmp_payloads keep, cookies_detailed wiring, multi-doc-fail visibility, VVT-Tabelle). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Compliance Data - Service Module Registry
Diese Dateien enthalten die Seed-Daten für das Compliance-Modul.
Sprint 3: Service-Module Registry
Dateien
service_modules.py: Vollständige Registry aller 30+ Breakpilot Services mit:- Technische Details (Port, Stack, Repository)
- Datenkategorien und PII-Verarbeitung
- Anwendbare Regulierungen (GDPR, AI Act, BSI-TR, etc.)
- Kritikalität und Ownership
Service-Typen
| Typ | Beschreibung | Beispiele |
|---|---|---|
backend |
API/Backend Services | consent-service, python-backend |
database |
Datenbanken | PostgreSQL, Qdrant, Valkey |
ai |
KI/ML Services | embedding-service, ai-compliance-sdk |
communication |
Chat/Video | Matrix, Jitsi |
storage |
Speichersysteme | MinIO, DSMS |
infrastructure |
Infrastruktur | Vault, Mailpit, Backup |
monitoring |
Monitoring (geplant) | Loki, Grafana, Prometheus |
security |
Sicherheit | Vault |
Relevanz-Stufen
| Stufe | Bedeutung |
|---|---|
critical |
Non-Compliance = Shutdown |
high |
Hohes Risiko |
medium |
Mittleres Risiko |
low |
Geringes Risiko |
Verwendung
from compliance.data.service_modules import (
BREAKPILOT_SERVICES,
get_service_count,
get_services_by_type,
get_services_processing_pii,
get_services_with_ai,
get_critical_services
)
# Alle Services
total = get_service_count()
# Backend Services
backends = get_services_by_type("backend")
# PII-verarbeitende Services
pii_services = get_services_processing_pii()
# KI-Services
ai_services = get_services_with_ai()
# Kritische Services
critical = get_critical_services()
Seeding
Services werden automatisch beim ersten Start geseedet:
# Nur Service-Module seeden
python -m compliance.scripts.seed_service_modules --mode modules
# Vollständige Compliance-DB seeden
python -m compliance.scripts.seed_service_modules --mode all
Validierung
Vor dem Seeding können die Daten validiert werden:
python -m compliance.scripts.validate_service_modules
Prüft:
- Pflichtfelder vorhanden
- Keine Port-Konflikte
- Regulierungen existieren
- Datenkategorien bei PII-Services
Service-Dokumentation
Jeder Service ist dokumentiert mit:
-
Identifikation
name: Technischer Name (Docker-Container)display_name: Anzeigenamedescription: Kurzbeschreibung
-
Technische Details
service_type: Typ (backend, database, etc.)port: Hauptport (falls vorhanden)technology_stack: Verwendete Technologienrepository_path: Pfad im Repositorydocker_image: Docker Image Name
-
Datenschutz
data_categories: Welche Datenkategorien werden verarbeitetprocesses_pii: Verarbeitet personenbezogene Daten?processes_health_data: Verarbeitet Gesundheitsdaten?ai_components: Enthält KI-Komponenten?
-
Compliance
criticality: Kritikalität (critical, high, medium, low)owner_team: Verantwortliches Teamregulations: Liste anwendbarer Regulierungen mit Relevanz
Beispiel: consent-service
{
"name": "consent-service",
"display_name": "Go Consent Service",
"description": "Kernlogik für Consent-Management, Einwilligungsverwaltung und Versionierung",
"service_type": "backend",
"port": 8081,
"technology_stack": ["Go", "Gin", "GORM", "PostgreSQL"],
"repository_path": "/consent-service",
"docker_image": "breakpilot-pwa-consent-service",
"data_categories": ["consent_records", "user_preferences", "audit_logs"],
"processes_pii": True,
"processes_health_data": False,
"ai_components": False,
"criticality": "critical",
"owner_team": "Backend Team",
"regulations": [
{"code": "GDPR", "relevance": "critical", "notes": "Art. 7 Einwilligung, Art. 30 VVZ"},
{"code": "TDDDG", "relevance": "critical", "notes": "§ 25 Cookie-Consent"},
{"code": "BSI-TR-03161-2", "relevance": "high", "notes": "Session-Management"}
]
}
Datenbank-Schema
Die Service-Module werden in folgenden Tabellen gespeichert:
compliance_service_modules
Haupttabelle für Services:
id,name,display_name,descriptionservice_type,port,technology_stackdata_categories,processes_pii,ai_componentscriticality,owner_teamcompliance_score(berechnet)
compliance_module_regulations
Mapping Service ↔ Regulation:
module_id,regulation_idrelevance_level(critical, high, medium, low)notesapplicable_articles(JSON Liste)
compliance_module_risks
Service-spezifische Risikobewertungen:
module_id,risk_idmodule_likelihood,module_impactmodule_risk_levelassessment_notes
API Endpoints
Nach dem Seeding stehen folgende Endpoints zur Verfügung:
GET /api/compliance/modules
Liste aller Service-Module
GET /api/compliance/modules/{module_id}
Details zu einem Service
GET /api/compliance/modules/{module_id}/regulations
Anwendbare Regulierungen für einen Service
GET /api/compliance/modules/{module_id}/compliance-score
Compliance-Score für einen Service
Erweiterung
Um einen neuen Service hinzuzufügen:
- Service zu
BREAKPILOT_SERVICESinservice_modules.pyhinzufügen - Validierung ausführen:
python -m compliance.scripts.validate_service_modules - Seeding ausführen:
python -m compliance.scripts.seed_service_modules
Oder über die API (wenn aktiviert):
POST /api/compliance/modules
{
"name": "new-service",
"display_name": "New Service",
...
}
Aktueller Stand (Sprint 3)
- ✅ 30+ Services dokumentiert
- ✅ Alle docker-compose.yml Services erfasst
- ✅ Regulation Mappings definiert
- ✅ Seeder implementiert
- ✅ Validierung verfügbar
- 🔄 Compliance-Score Berechnung (geplant)
- 🔄 Gap-Analyse pro Service (geplant)