Files

T

Benjamin Admin f6fe592164 docs: Schnittstellen-Notiz um Controls-Session-Abhängigkeit ergänzt

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>

2026-06-16 06:24:48 +02:00

4.6 KiB

Raw Blame History

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.

4.6 KiB Raw Blame History Unescape Escape