Benjamin Admin
f6fe592164
Ergänzt nach Rückmeldung der Controls-Session: ID-Stabilität schützt auch deren atom_classification (~161k) + addressee (control_uuid-gebunden); deren Step-1/2 ist additiv (tier/source_type/core_count/addressee, bricht Verträge nicht); eine Wahrheit — Muster-Schicht aus atom_classification speisen, nicht neu ableiten. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
96 lines
4.6 KiB
Markdown
96 lines
4.6 KiB
Markdown
# Schnittstelle: Controls-/Muster-Schicht → Maßnahmen-Schicht
|
||
|
||
> Status: Vorschlag / Abstimmung mit der Controls-Session (Stand 2026-06-16)
|
||
> Kontext: Die Controls-Pipeline (master controls, Topic-Mapping) wird in
|
||
> `breakpilot-core/control-pipeline/` überarbeitet. Diese Notiz definiert, was
|
||
> die Maßnahmen-Schicht (CRA/Compliance) als stabilen Andock-Punkt braucht.
|
||
|
||
## Ziel
|
||
|
||
Maßnahmen werden **pro Abhilfe-Muster** geschrieben (wiederverwendbar, viele
|
||
Controls → eine Maßnahme), **nicht** pro Control. Es sollen also keine ~100k
|
||
Einzel-Maßnahmen entstehen, sondern wenige hundert standard-gestützte Maßnahmen,
|
||
die an eine saubere, **stabile** Muster-/Topic-Schicht andocken.
|
||
|
||
## Was die Maßnahmen-Schicht von der Controls-Schicht braucht
|
||
|
||
### 1. Stabile „Abhilfe-Muster"-Einheit mit fester ID (wichtigste Bitte)
|
||
|
||
- Kandidaten für die kanonische Einheit: verbesserter `master_control_id`,
|
||
`sub_topic`, oder ein neues „obligation-pattern"-Cluster. **Bitte festlegen,
|
||
welche Einheit kanonisch ist.**
|
||
- **Kritisch:** die ID muss eine Re-Generierung überleben (deterministisch)
|
||
**oder** es gibt einen stabilen natürlichen Schlüssel
|
||
(z. B. Hash des normalisierten `canonical_obligation`, oder
|
||
`use_case + sub_topic + framework`). Sonst brechen die
|
||
Maßnahme↔Muster-Verknüpfungen bei jedem Re-Run (dasselbe Problem wie damals
|
||
mit `chunk_hash`).
|
||
|
||
### 2. Mapping `control_uuid → pattern_id` (viele zu eins)
|
||
|
||
Von der Controls-Schicht gepflegt, damit ein Befund vom Control aufs Muster
|
||
(→ Maßnahme) aufgelöst werden kann.
|
||
|
||
### 3. Felder pro Muster (oder pro Control)
|
||
|
||
- `sub_topic` / Topic (z. B. authentication, cryptography) — die Muster-Achse
|
||
- **Framework-Crosswalk:** NIST 800-53, OWASP (ASVS/Top 10), ISO 27002,
|
||
IEC 62443 — der inhaltliche Anker der Maßnahme (Substanz aus Standards
|
||
referenzieren, nicht neu schreiben)
|
||
- `canonical_obligation` — normalisiertes „was ist zu tun" (Saat-Text)
|
||
- `source_regulation` + `source_article` — Provenienz/Zitat
|
||
- `severity`, `use_case`, `tier` (core/review)
|
||
|
||
## Was die Controls-Schicht NICHT anfassen muss
|
||
|
||
Die **CRA-Annex-I-Spine + die kuratierten Maßnahmen M540–M548** (40 Anforderungen,
|
||
in `compliance/api/cra_annex_i_data.py`) hängen an CRA-**Anforderungen**, liegen in
|
||
der Compliance-Session und sind vom Control-Rework **unabhängig**. Die
|
||
CRA-Maßnahmen laufen parallel weiter.
|
||
|
||
## Bitte NICHT brechen (liest die Breadth-Schicht heute schon)
|
||
|
||
- `atom_classification` (`use_case`, `sub_topic`, `relevant`, `canonical_obligation`)
|
||
- `canonical_controls` (`control_id`, `title`, `objective`, `severity`, `license_rule`)
|
||
- `control_parent_links` (`source_regulation`, **`source_article`**)
|
||
- die Response-Form von `UseCaseControlsService.controls_for_use_case` (atom-grain)
|
||
|
||
> Bestätigt von der Controls-Session: deren laufende Step-1/2-Änderungen sind rein
|
||
> **additiv** (neue Felder `tier` / `source_type` / `core_count`, neue Spalte
|
||
> `addressee`) — diese Verträge bleiben also unverletzt.
|
||
|
||
## Gemeinsame ID-Stabilitäts-Abhängigkeit (beide Sessions)
|
||
|
||
Die geforderte stabile Muster-ID + `control_uuid → pattern`-Garantie schützt
|
||
**nicht nur die Maßnahmen-Schicht**, sondern genauso die laufende
|
||
Klassifikations-Arbeit der Controls-Session:
|
||
|
||
- `atom_classification` (≈161k Zeilen) + die neuen `addressee`-Tags + Provenance
|
||
hängen an `control_uuid → canonical_controls.id`.
|
||
- Wird bei einer Control-Neuerzeugung die `control_uuid` neu vergeben, sind diese
|
||
Klassifikationen **verwaist** — exakt das „chunk_hash"-Problem.
|
||
- **Anforderung an die Re-Generierung:** `control_uuid` erhalten **oder** einen
|
||
stabilen natürlichen Schlüssel mitliefern, an den sich beide Schichten neu
|
||
binden können.
|
||
|
||
## Eine Wahrheit, nicht zwei
|
||
|
||
`atom_classification` **IST** die Breite-Schicht (`use_case` / `sub_topic` /
|
||
`canonical_obligation`), auf die diese Notiz sich beruft. Die Controls-/
|
||
Muster-Schicht sollte daraus **gespeist** werden, nicht parallel neu ableiten —
|
||
sonst entsteht doppelte Wahrheit. Muster-Bildung und Klassifikation müssen auf
|
||
demselben kanonischen `sub_topic`/`canonical_obligation` aufsetzen.
|
||
|
||
## Aufgabenteilung
|
||
|
||
- **Controls-Session (core/control-pipeline):** MC-/Control-Neuerzeugung +
|
||
Topic/Muster-Mapping + Framework-Crosswalk pro Muster, mit stabilen IDs.
|
||
- **Compliance-Session:** Maßnahmen-Schicht (Muster → ausformulierte,
|
||
standard-gestützte Maßnahme) + CRA-Integration auf diesem Output.
|
||
|
||
## Die eine Entscheidung, die uns entblockt
|
||
|
||
Bitte nennen: **(a) die kanonische Muster-Einheit** und **(b) die
|
||
ID-Stabilitäts-Garantie**. Das allein reicht, damit die Maßnahmen-Schicht darauf
|
||
ausgerichtet werden kann.
|