Benjamin Admin
a98076196b
The mature step after Medical is not the next domain but understanding WHY the registry converges.
Three derived views over existing data (no ML, no new architecture):
1. Why converge? — a domain matrix per cross-domain MCAP + a curated REASON (the moat: not "MCAP-X
exists" but "why MCAP-X must exist": software product / supply chain / product operation /
universal process).
2. Capability Families — ~75 MCAPs collapse to ~15 curated families (knowledge/capability_families/
families.yaml), each with the reason it is universal or domain-specific.
3. Core vs Domain — a COMPUTED property (not a new class): Core recurs across >=2 independent domains
AND source types; Domain stays in one. Medical made it obvious (new medical caps are nearly all
Domain; update/SBOM/access/logging are Core).
Non-runtime -> no deploy. 4 tests pass, check-loc 0.
5.0 KiB
Capability Convergence Explanation — WARUM konvergieren diese Capabilities?
Nicht „welche MCAPs?", sondern „warum verlangen völlig verschiedene Welten immer wieder DIESELBEN?". Drei abgeleitete Sichten über vorhandene Daten (kein ML, keine neue Architektur). Der eigentliche Burggraben ist nicht „MCAP-X existiert", sondern „warum MCAP-X existieren MUSS".
1. Warum konvergieren sie? — Domänen-Matrix + Grund
| Capability | Industrial | Automotive | Medical | Environmental | Grund (Familie) |
|---|---|---|---|---||---|
| access_control_and_authentication | ✓ | ✓ | ✓ | – | Wer/was darf — Identität und Zugriff. |
| sbom_creation | ✓ | ✓ | ✓ | – | Lieferkette/Stoffstrom — was steckt im Produkt? (SBOM = Software, Stoffliste = Material). |
| secure_signed_update_distribution | ✓ | ✓ | ✓ | – | Softwareprodukt — jedes vernetzte Produkt muss sicher aktualisierbar sein. |
| technical_vulnerability_management | ✓ | ✓ | ✓ | – | Produktbetrieb — Schwächen über die Lebensdauer behandeln. |
| asset_and_configuration_management | ✓ | ✓ | – | – | Konfiguration und Asset-Kontrolle. |
| coordinated_vulnerability_disclosure | ✓ | ✓ | – | – | Produktbetrieb — Schwächen über die Lebensdauer behandeln. |
| cryptography | ✓ | ✓ | – | – | — |
| document_and_change_control | ✓ | ✓ | – | – | Nachweisführung — Konformität dokumentieren. |
| incident_management | ✓ | ✓ | – | – | Vorfälle erkennen, behandeln und melden. |
| product_cyber_risk_assessment | ✓ | ✓ | – | – | Universeller Prozess — jede Regulierung verlangt eine Risikobeurteilung. |
→ Das ist keine Statistik mehr, sondern Erkenntnis: dieselbe Fähigkeit kehrt wieder, weil ein universelles Prinzip dahinter steht (Softwareprodukt · Lieferkette · Produktbetrieb · universeller Prozess).
2. Capability Families — 75 MCAPs reduzieren sich auf 15 Familien
| Familie | Art | MCAPs | Domänen | Warum universell / spezifisch |
|---|---|---|---|---|
| Risk | core | 6 | 3 | Universeller Prozess — jede Regulierung verlangt eine Risikobeurteilung. |
| Update | core | 4 | 3 | Softwareprodukt — jedes vernetzte Produkt muss sicher aktualisierbar sein. |
| Vulnerability | core | 3 | 3 | Produktbetrieb — Schwächen über die Lebensdauer behandeln. |
| Identity & Access | core | 3 | 3 | Wer/was darf — Identität und Zugriff. |
| Inventory & Composition | core | 6 | 4 | Lieferkette/Stoffstrom — was steckt im Produkt? (SBOM = Software, Stoffliste = Material). |
| Supplier | core | 3 | 3 | Lieferantensteuerung — Verantwortung über die Kette. |
| Incident & Reporting | core | 2 | 2 | Vorfälle erkennen, behandeln und melden. |
| Monitoring & Audit | core | 3 | 3 | Beobachtung — Betrieb und Umfeld überwachen. |
| Lifecycle & Development | core | 3 | 3 | Produkt-/Software-Lebenszyklus. |
| Documentation & Evidence | core | 6 | 4 | Nachweisführung — Konformität dokumentieren. |
| Configuration & Asset | core | 2 | 2 | Konfiguration und Asset-Kontrolle. |
| Environmental/Material | domain | 9 | 1 | Umwelt-/Stoff-spezifisch. |
| Medical | domain | 7 | 3 | Medizin-/Patientensicherheit-spezifisch. |
| Automotive | domain | 4 | 1 | Automotive-/Funktionssicherheit-spezifisch. |
| Process & QMS | domain | 4 | 3 | QM-/Prozessdisziplin. |
| (nicht zugeordnet) | — | 10 | — | Review: Familie fehlt oder Name untypisch |
→ Die Familien erklären die Konvergenz: unterschiedliche Regelwerke brauchen dieselben MCAPs, weil sie dieselbe FAMILIE adressieren. Vermutete Langzeit-Reduktion: ~15 Familien statt 75 Einzel-MCAPs.
3. Core vs Domain — eine BERECHNETE Eigenschaft (keine neue Klasse, keine Architektur)
- Core (6): kehren über ≥2 unabhängige Domänen UND ≥2 Quelltypen wieder — z. B.
access_control_and_authentication,incident_management,secure_development_lifecycle,secure_signed_update_distribution,supplier_security,technical_vulnerability_management…. - Domain (61): überwiegend EINE Fachdomäne — z. B.
account_energy_consumption,analyze_water_discharge,approve_production_parts_ppap,assess_software_process_capability,assign_unique_device_identification,ce_conformity_assessment_and_technical_documentation…. - Bridging (8): dazwischen (mehrere Domänen, aber 1 Quelltyp).
Befund: Medical machte es offensichtlich — die neuen medizinischen Capabilities sind fast alle Domain, während Update/SBOM/Access/Logging Core sind. Die Zweiteilung ist eine abgeleitete Eigenschaft aus (Domänen × Quelltypen), kein neues Modell. Der eigentliche Burggraben ist die Erklärung, WARUM die Core-Familien existieren: sie sind die wenigen universellen Prinzipien (Risiko · Update · Identität · Inventar · Nachweis · Lieferant · Lebenszyklus), auf die sehr unterschiedliche Anforderungswelten immer wieder zurückfallen. Reine Aggregation, 0 Runtime, 0 neue Architektur.