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.
50 lines
5.0 KiB
Markdown
50 lines
5.0 KiB
Markdown
# 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.
|
||
|