Assessor_2.0/reports/purple-knight-audit-2026-09-09/PRUEFBERICHT.md

PurpleKnight in ASSESSOR – Importprüfung

Verifizierte Umsetzung vom 09.09.2026

Die beauftragten Importfehler sind behoben. Der ursprüngliche Auditstand bleibt darunter als Historie erhalten.

• Profil 1.3.0, HTML-Extractor 1.2.0, Summary-Extractor 1.1.0; bestehende Mapping-/Normalisierungsverträge bleiben kompatibel.
• XLSX liefert nun 119 kanonische Ergebnisse, 22 Kontextbeobachtungen und alle 20 verknüpften Detailtabellen mit 46 Zeilen. Die Summary verdrängt keine Indikatorentabelle mehr.
• HTML liefert 119 Ergebnisse, 45 Kontextbeobachtungen, einen Reportabschnitt und alle 20 Detailtabellen mit 46 Zeilen. Bekannte Summary-Kennzahlen und unbekannte Originalmetadaten bleiben erhalten. Sämtliche 213 geprüften Detailzellen, einschließlich Sekunden, stimmen exakt mit der Quelle überein; 4.743 Originalfeldwerte wurden gegen ihre nativen Quellpfade geprüft. Abgeleitete Status-, Kategorie- und Laufzeitwerte referenzieren ihre realen Eingabeobjekte.
• Die Haupt-CSV wird anhand der Kombination aus nativer Namensstruktur und Schema ohne zusätzliche Werkzeugbestätigung erkannt. Der CSV-Gesamtsatz liefert weiterhin 119 Ergebnisse, 22 Kontextbeobachtungen sowie 19 eindeutig verknüpfte Detaildateien mit 45 Zeilen. Dateiname allein erzwingt kein Profil.
• Beschädigte Payloads, fehlende IDs, konkurrierende Zuweisungen und angekündigte, aber unlesbare Ergebnisse scheitern explizit. Wiederholte IDs, fehlende Kategorieverweise und Summen-/Detailabweichungen erhalten Diagnosen; vorhandene Ergebnisse werden nicht verworfen. Native Null-Details ohne Ergebnisse und deklarierte Leerberichte bleiben gültig.
• 25 neue synthetische Regressionen. npm test: 1.122 bestanden, acht optionale PostgreSQL-Tests übersprungen. Sicherheits-/Designcheck und vollständiger Client-/Serverbuild erfolgreich. Alle 24 Dateien wurden rein lesend mit beiden Runtimes und dem lokalen Parse-Endpunkt abgeglichen; der abschließende Drei-Format-Check am finalen Backend bestätigt Profil und Ergebniszahlen. Repositoryrevision unverändert.

AGENTS.md, Sicherheitsvorgaben, Importgrenzen und Umsetzungsplan enthalten die Erkenntnisse. Die temporären Audit-Skripte wurden entfernt. Der kanonische PostgreSQL-Datastore bleibt unverändert; App und aktualisiertes Backend laufen lokal. Kein Reimport, keine Datenbankmigration. Bereits gespeicherte PurpleKnight-Importe benötigen einen ausdrücklichen Reimport, um den neuen Erfassungsstand zu erhalten. Die separate AD-Domänen-CSV bleibt als Rohquelle erhalten; die typisierte HTML-Domänenliste ist Teil des neuen Kontexts. Phase 13C bleibt insgesamt in Arbeit.

Ursprünglicher Prüfstand

Stand: 09.09.2026 · ASSESSOR 2.5.5 · Prüfung, keine Implementierung

Ergebnis

PurpleKnight wird noch nicht vollständig verarbeitet. Der schwerste Fehler betrifft das vollständige Excel-Workbook: Seine 119 Indikatorergebnisse ergeben 0 kanonische Findings. HTML und der bestätigte CSV-Gesamtimport liefern dagegen jeweils sämtliche 119 Indikatorergebnisse und die zugehörigen Ergebnistabellen. HTML verliert jedoch Berichtskontext und Zeitstempelpräzision; außerdem fehlen Vollständigkeitsprüfungen.

„119 Ergebnisse“ umfasst bestandene und nicht ausgeführte beziehungsweise nicht relevante Prüfungen, nicht 119 Sicherheitsprobleme.

Prüfumfang und Methode

Geprüft wurden ausschließlich die 24 vom Nutzer freigegebenen Dummy-Dateien: 22 CSV-Dateien, ein HTML-Bericht und ein XLSX-Workbook. Der Auftrag gehört zu Phase 13A/13C des Implementierungsplans: Importpipeline, Profilverarbeitung und vollständiger Umgebungskontext.

• Unabhängige Kontrolllesung mit Python-CSV-Reader und direkter OOXML-Zelllesung. Der Spreadsheet-Prüfworkflow wurde rein lesend angewendet; das Workbook blieb unverändert. Die direkte OOXML-Lesung umging eine nicht unterstützte Layout-Eigenschaft im unabhängigen Excel-Leser, nicht einen ASSESSOR-Parserfehler.
• HTML-Skriptblöcke ausschließlich als Text und eingebettetes JSON gelesen, niemals ausgeführt.
• Alle Dateien durch Browser- und Node-Importadapter, Vorschau, erforderliche Mappingbestätigung, kanonisches Modell, Modellvalidierung und Work-Dataset-Projektion geprüft.
• Zusätzlich alle 24 Dateien gegen den laufenden lokalen Backend-Parse-Endpunkt geprüft: jeweils HTTP 200 und identische Extraktion; Repository-Revision vorher/nachher unverändert.
• Synthetische Gegenproben für Workbook-Extractor-Auswahl und beschädigte beziehungsweise widersprüchliche HTML-Berichte.
• 47 vorhandene fokussierte Tests in neun Testdateien bestanden.

Kein Import-/Reimport-Abschluss, keine Datenbankmigration, kein Zugriff auf fremde Kundendaten und keine Produktionscodeänderung. Bestehende persistierte PurpleKnight-Bestände und eine befüllte Oberfläche wurden nicht inhaltlich untersucht. Vollständiger Build und Gesamttests waren nicht Gegenstand dieser reinen Prüfung.

Abgleich nach Format

Quelle	Native Indikatorergebnisse	Kanonische Ergebnisse	Detailverknüpfungen	Berichtskontext
CSV-Gesamtsatz, 08:23	119	119 nach Bestätigung	19/19 eindeutig, 45 Detailzeilen	22 Beobachtungen, ein Summary-Abschnitt
XLSX, 09:14	119	0	Keine Work-Projektion aus diesem Einzelimport	22 Beobachtungen, ein Summary-Abschnitt
HTML, 09:14	119	119	20/20 eindeutig, 46 Detailzeilen	0 Beobachtungen, 0 Berichtabschnitte

Die CSV-Dateien stammen aus einem früheren Lauf als HTML/XLSX. Ihre Abweichung ist kein Importfehler:

Lauf	Bestanden	IOE gefunden	Nicht relevant	Nicht ausgewählt	Nativer Posture Score
CSV 08:23	96	19	3	1	65
HTML/XLSX 09:14	95	20	4	0	59

Alle 119 nativen Indikator-IDs stimmen zwischen den Läufen überein; zwei Statuswerte haben sich geändert. Die CSV-Hauptdatei erhält sämtliche 26 Spaltenwerte für alle 119 Zeilen. Die 19 CSV-Detaildateien erhalten sämtliche geprüften Zellwerte.

Priorisierte Befunde

1. P1 – Summary-Extractor verdrängt Excel-Indikatoren

Das Workbook enthält 23 Blätter, darunter „Assessment summary“, „Indicators results“ mit 119 Indikatoren sowie 20 Detailblätter. Die Erkennung wählt die Indikatorentabelle korrekt aus. Anschließend gewinnt jedoch der Summary-Extractor für das gesamte Dokument und liefert absichtlich keine Finding-Kandidaten. Die kanonische Validierung akzeptiert das Ergebnis ohne Warnung. Quelltabellen bleiben erhalten, aber die 119 Indikatorergebnisse werden nicht als Findings aufgebaut; die Work-Projektion des alleinigen Workbooks bleibt leer.

Ursache: Summary-Erkennung und Extraktion in Verbindung mit der Auswahl genau eines Extractors.

Fix: Summary-Kontext, Indikatorentabelle und Detailblätter gemeinsam über die generische Pipeline verarbeiten. Den Summary-Extractor nicht einfach abschalten, sonst geht der bereits verfügbare Kontext verloren. Synthetisch mit einem Summary- und einem Indikatorenblatt reproduziert.

Abnahme: 119 Ergebnisse, 20 eindeutig verknüpfte Detailtabellen mit 46 Zeilen und weiterhin 22 Summary-Beobachtungen aus diesem Workbook; keine Summary-Zeile als Finding.

2. P1 – HTML-Berichtskontext wird nicht übernommen

Im eingebetteten HTML-Modell stehen unter anderem Posture Score 59, Gesamtzahl 119, 95 bestandene Prüfungen, 20 IOEs, vier nicht relevante Prüfungen, sechs bewertete Kategorien, Werkzeugversion, Erstellungszeit und Umgebungskontext. Der Extractor übernimmt lediglich Indikator-Kandidaten und Detailtabellen. Das kanonische Modell enthält weder Umgebungsbeobachtungen noch Berichtabschnitte.

Ursache: HTML-Extraktion.

Fix: Native HTML-Summary und Kategorien auf dieselben Kontextverträge wie CSV/XLSX abbilden. Native Scores separat und mit Herkunft führen, nicht mit vergleichbaren ASSESSOR-Scores verwechseln. Fehlende Werte bleiben unbekannt, nicht 0 beziehungsweise 0 %.

Abnahme: Inhaltlich äquivalente HTML-/XLSX-Summary liefert dieselben normalisierten Kennzahlen bei erhaltener formatabhängiger Provenienz.

3. P1 – HTML-Teilimporte werden nicht als unvollständig erkannt

Synthetische Gegenproben durch Extraktion und kanonisches Modell:

Gegenprobe	Beobachtetes Verhalten
Deklarierte Gesamtzahl 99, tatsächlich zwei Indikatoren	Zwei Ergebnisse; Extraktion „complete“; keine Abweichungsdiagnose
Ein fehlender ResIndicator-Block	Nur ein statt zwei Ergebnissen; „complete“
Ein beschädigter JSON-Indikator	Nur ein statt zwei Ergebnissen; „complete“
Zwei Indikatoren mit gleicher ShortName	Zwei Vorkommen; keine Identitätskonfliktdiagnose

Die generische Warnung über entfernten aktiven HTML-Inhalt ist vorhanden, erklärt aber keinen dieser Vollständigkeitsfehler. Bei den freigegebenen 119 HTML-Indikatoren wurde kein solcher Ausfall festgestellt; hier geht es um eine nachgewiesene Schutzlücke.

Ursache: Payload-Lesung überspringt nicht lesbare Objekte und gleicht das Ergebnis nicht mit der nativen Berichtsbilanz ab.

Fix: Deklarierte, gelesene und kanonisch übernommene Ergebnisse sowie Detailanzahlen abgleichen; beschädigte Objekte, fehlende IDs und Identitätskonflikte explizit melden. Widersprüchliche Identitäten nicht pauschal zusammenlegen. Fehler je nach Ausmaß als partiellen oder fehlgeschlagenen Import ausweisen.

4. P2 – HTML-Originaltreue und Feldherkunft unvollständig

• Von 213 geprüften Detailzellen wurden 20 Zeitstempel verändert: Ihre vorhandenen, nicht nullwertigen Sekunden verschwinden durch die Normalisierung auf Minuten. Alle 46 Zeilen bleiben erhalten, aber diese Werte sind nicht mehr exakt. Die Datumsumwandlung muss den Originalwert neben einem separat normalisierten Wert erhalten.
• Bei allen 119 Indikatoren zeigen die Feldpfade für die sechs geprüften Felder ShortName, Name, Description, Severity, Score und Remediation auf die falsche Objektebene. Beispielsweise fehlt ResIndicator beziehungsweise ExecutionResult im Pfad. Die Werte selbst wurden gelesen; ihre Feldprovenienz ist jedoch unzutreffend. Abgeleitete Werte brauchen ebenfalls explizite Ableitungsherkunft.

Die Originaldatei wird im kanonischen Import nicht separat aufbewahrt. Deshalb ist eine spätere Wiederherstellung der verlorenen Zeitpräzision aus dem kanonischen Modell allein nicht gesichert.

Textabweichungen wurden nicht pauschal als Verlust gezählt: 95 Unterschiede in „Likelihood of compromise“ und sechs in „Description“ betreffen die Darstellung. Sieben Remediation-Werte unterscheiden sich durch Whitespace oder HTML-zu-Klartext-Umwandlung; zwei enthalten Links, deren Ziele im Klartext fehlen. Die ursprünglichen Remediation-HTML-Werte bleiben jedoch als Originalfelder erhalten. Dies ist kein nachgewiesener vollständiger Verlust dieser Maßnahmen oder Links aus dem kanonischen Modell.

5. P2 – CSV-Erkennung benötigt zusätzliche Bestätigung

Die Haupt-CSV wird als PurpleKnight vorgeschlagen, erreicht aber nur 0,54 Konfidenz und verwendet bis zur Bestätigung das generische Profil. Nach der regulären Bestätigung ist das Profil korrekt purple-knight; es handelt sich nicht um einen dauerhaft generischen oder fehlerhaften Import.

Fixoption: Die Kombination aus typischer CSV-Namensstruktur und charakteristischen Spalten besser erkennen, ohne Dateinamen allein zu vertrauen. Die Sicherheitsgrenze für unbekannte oder mehrdeutige Dateien beibehalten. Profilregeln.

Die separate AD-Domänen-Datei bleibt als Quelltabelle erhalten, erzeugt aber keine typisierten Domänenbeobachtungen. Ob ihre Einzelangaben zusätzlich als Umfeldkontext benötigt werden, sollte mit der Kontextabbildung aus Punkt 2 vereinheitlicht werden; dies ist kein Verlust ihrer Rohdaten.

Empfohlene Umsetzung

Zuerst Punkte 1–3 beheben, anschließend Originaltreue und Provenienz aus Punkt 4 absichern. Die CSV-Erkennungsverbesserung ist nachrangig.

Verbindliche Regressionen sollten vollständige Multi-Sheet-Workbooks, semantische Formatparität innerhalb desselben Scan-Laufs, vollständige Ergebnistabellen-Verknüpfung, exakte Originalwerte, auflösbare Feldpfade und explizite Teilimportdiagnosen abdecken. Prüfungen gegen unabhängige native Summen dürfen nicht nur die Anzahl der bereits extrahierten Kandidaten bestätigen. CSV- und HTML/XLSX-Läufe verschiedener Zeitpunkte müssen getrennt bleiben.

Dieser Bericht dokumentiert einen Prüfstand. Die genannten Fehler sind noch nicht behoben; keine Phase oder Abnahme wurde als abgeschlossen markiert. Temporäre Audit-Skripte wurden nach der Prüfung entfernt.