52 lines
3.2 KiB
Markdown
52 lines
3.2 KiB
Markdown
# Vergleichsengine für Assessment-Läufe
|
|
|
|
Stand: 2026-07-17
|
|
Zugehörige Planphase: Phase 8
|
|
|
|
## Zweck
|
|
|
|
Die Vergleichsengine ordnet Finding-Vorkommen aus zwei Scan-Läufen reproduzierbar ein. Sie arbeitet ausschließlich auf dem kanonischen Assessment-Modell und benötigt weder React noch Browser-, Tauri- oder Datenbankfunktionen.
|
|
|
|
Originalwerte und Findings werden durch den Vergleich nicht verändert. Das Ergebnis ist ein separates, versioniertes `ScanRunComparison`.
|
|
|
|
## Matchingstufen
|
|
|
|
Die Engine verarbeitet eindeutige Kandidaten stufenweise:
|
|
|
|
1. lokal bestätigte Mappingregel
|
|
2. bereits gemeinsame Finding-Definition oder gemeinsamer kanonischer Schlüssel
|
|
3. Quellwerkzeug und Regel-ID
|
|
4. Framework und Control-ID
|
|
5. Regel-ID und betroffenes Objekt
|
|
6. normalisierte Merkmalskombination
|
|
7. Ähnlichkeitsvorschlag
|
|
|
|
Eine Stufe erzeugt nur dann ein automatisches Match, wenn sowohl das Finding des Basislaufs als auch das Finding des Ziellaufs in dieser Stufe genau einen Partner besitzen. Doppelte Regel-IDs, mehrfach verwendete Controls oder kollidierende Merkmalskombinationen werden deshalb nicht willkürlich aufgelöst.
|
|
|
|
Die gemeinsame Finding-Definition und lokale Mappingregeln stehen vor neu berechneten Quellschlüsseln, weil sie eine bereits bestätigte fachliche Identität ausdrücken.
|
|
|
|
## Sichere und unsichere Zuordnungen
|
|
|
|
Tool-/Regel-ID, Control-ID, Regel-/Asset-Kombination und ausreichend vollständige Merkmalskombinationen können bei Eindeutigkeit automatisch zugeordnet werden. Jede Zuordnung enthält Methode, Entscheidung, Konfidenzwert und Begründung.
|
|
|
|
Textähnlichkeit erzeugt ausschließlich `possibly-identical` mit der Entscheidung `suggested`. Ein solcher Vorschlag wird nicht als gemeinsame Finding-Identität gespeichert. Erst `createLocalComparisonRule` erzeugt nach einer ausdrücklichen Benutzerbestätigung eine serialisierbare Regel. Wird diese Regel bei einem späteren Vergleich übergeben, lautet die Entscheidung `user-confirmed`.
|
|
|
|
## Vergleichsergebnisse
|
|
|
|
- `persistent`: in Basis- und Ziellauf eindeutig vorhanden
|
|
- `new`: im Ziellauf erstmals vorhanden
|
|
- `resolved`: im Basislauf vorhanden, im Ziellauf nicht mehr vorhanden
|
|
- `reoccurred`: im Basislauf abwesend, aber in einem älteren Lauf eindeutig vorhanden
|
|
- `possibly-identical`: unsicherer, noch zu bestätigender Vorschlag
|
|
- `not-comparable`: Assessment, Werkzeug oder Identitätsmerkmale reichen nicht für eine belastbare Aussage
|
|
|
|
Für sichere Paare werden Änderungen an Severity, Status, Score, Asset und Evidenz getrennt ausgewiesen. Evidenzvergleiche sind unabhängig von der Reihenfolge der Evidenzeinträge.
|
|
|
|
## Reproduzierbarkeit
|
|
|
|
Eingaben werden nach stabilen IDs und Schlüsseln sortiert. Das Ergebnis enthält keine aktuelle Uhrzeit und hängt nicht von der Reihenfolge der Arrays im Modell ab. Identische fachliche Eingaben liefern daher identische Vergleichsergebnisse.
|
|
|
|
## Grenzen und nächste Schicht
|
|
|
|
Lokale Mappingregeln werden seit Phase 9 über den Repository-Vertrag verwaltet. Die In-Memory-Referenzimplementierung ist noch keine dauerhafte Produktdatenbank; die konkrete dauerhafte Ablage folgt mit dem Backend- und PostgreSQL-Adapter. Die heutige lokale Oberfläche erzeugt noch kein vollständiges kanonisches Mehrlaufprojekt.
|