# 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.