Xml Output: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

XML-Output ist in WPScan kein kosmetisches Extra, sondern ein Arbeitsformat. Wer Ergebnisse nur im Terminal liest, verliert bei wiederholten Scans, Teamarbeit und Weiterverarbeitung schnell die Kontrolle über Details. XML schafft Struktur: Funde werden als klar abgegrenzte Elemente ausgegeben, Metadaten bleiben maschinenlesbar, und Ergebnisse lassen sich in Parser, Reporting-Skripte oder SIEM-nahe Prozesse übernehmen. Gerade in Umgebungen mit mehreren WordPress-Instanzen ist das entscheidend, weil ein Scan nicht isoliert betrachtet wird, sondern Teil eines reproduzierbaren Prüfpfads ist.

Der praktische Nutzen zeigt sich vor allem dann, wenn Scans regelmäßig laufen oder Ergebnisse mit anderen Werkzeugen korreliert werden. Ein Terminal-Output ist für den schnellen Blick gut, aber schlecht für belastbare Nachweise. XML eignet sich, wenn Funde archiviert, verglichen oder automatisiert bewertet werden sollen. Wer bereits mit Output Format arbeitet, erkennt schnell den Unterschied zwischen menschenlesbarer Ausgabe und einer Form, die sich stabil weiterverarbeiten lässt. Im Vergleich zu Json Output ist XML oft dort im Vorteil, wo bestehende Parser, XSLT-Transformationen oder klassische Enterprise-Workflows im Einsatz sind.

Wichtig ist die richtige Erwartungshaltung: XML macht einen Scan nicht besser, sondern verwertbarer. Fehlerhafte Zieldefinition, unpassende Scan-Optionen oder blockierte Requests werden durch XML nicht kompensiert. Wenn die Erkennung von Plugins, Themes oder Versionen unvollständig ist, landet diese Unvollständigkeit sauber strukturiert in der Datei. Deshalb muss XML immer zusammen mit sauberer Scan-Planung betrachtet werden, etwa mit Target Url, passenden Scan Optionen und einem nachvollziehbaren Ablauf aus Pentest Workflow.

In der Praxis ist XML besonders nützlich, wenn mehrere Rollen mit denselben Daten arbeiten. Ein Pentester braucht Rohdaten, ein Analyst will priorisierte Findings, ein Entwickler möchte nur die betroffenen Komponenten sehen, und ein Security-Team will Trends über Zeiträume vergleichen. XML kann diese Anforderungen bedienen, weil es nicht nur Text ausgibt, sondern Beziehungen zwischen Ziel, Scan-Kontext und Findings konserviert. Genau deshalb ist XML-Output weniger ein Exportformat als ein Bindeglied zwischen Erkennung, Bewertung und Bericht.

Ein sauberer XML-Workflow beginnt nicht beim Parser, sondern beim Scan-Aufruf. Der häufigste Fehler ist ein improvisierter Befehl, der zwar läuft, aber keine konsistenten Ergebnisse erzeugt. Vor dem Export muss klar sein, welche Daten überhaupt erhoben werden sollen: nur passive Erkennung, aggressive Enumeration, API-gestützte Schwachstellenabfrage oder authentifizierte Prüfung. Erst danach ergibt XML Sinn. Wer die Grundlagen noch nicht standardisiert hat, sollte zuerst Wpscan Anleitung, CLI Parameter und Scan Starten sauber festziehen.

Ein typischer Startpunkt für eine strukturierte XML-Ausgabe sieht so aus:

wpscan --url https://target.tld \
  --format xml \
  --output scan-target-2026-04-23.xml

Das ist funktional, aber noch nicht robust. In realen Assessments kommen meist weitere Parameter hinzu, etwa API-Nutzung, Enumeration oder Timeouts. Ein praxisnaher Befehl kann so aussehen:

wpscan --url https://target.tld \
  --enumerate vp,vt,tt,u \
  --api-token YOUR_TOKEN \
  --request-timeout 20 \
  --connect-timeout 10 \
  --format xml \
  --output reports/target.tld-full.xml

Hier werden Plugins, verwundbare Plugins, Themes und Benutzer enumeriert. Ob das sinnvoll ist, hängt vom Scope ab. Für einen ersten, defensiven Überblick kann ein passiver Ansatz genügen; für tiefergehende Prüfungen sind aggressive Methoden oft notwendig. Die Auswahl sollte sich an Passive Scan, Aggressive Scan und dem tatsächlichen Prüfziel orientieren.

• Der Dateiname sollte Ziel, Scan-Typ und Datum enthalten, damit spätere Vergleiche eindeutig bleiben.
• Der Exportpfad sollte vor dem Scan existieren und beschreibbar sein, sonst endet der Lauf ohne verwertbare Datei.
• Parameter für Timeout, Proxy oder Authentifizierung müssen im Befehl dokumentiert sein, damit Ergebnisse reproduzierbar bleiben.

Gerade bei Teamarbeit ist Reproduzierbarkeit wichtiger als Bequemlichkeit. Ein XML-Report ohne dokumentierten Befehl ist nur begrenzt belastbar. Wenn ein späterer Rescan andere Resultate liefert, muss nachvollziehbar sein, ob sich das Ziel geändert hat oder nur die Scan-Parameter. Deshalb gehört zum XML-Output immer auch die Disziplin, Scan-Kommandos versioniert oder zumindest nachvollziehbar abzulegen. Wer das ignoriert, produziert zwar Dateien, aber keine belastbaren Befunde.

Viele Fehler entstehen nicht beim Erzeugen, sondern beim Interpretieren der XML-Datei. Wer XML nur als Textcontainer betrachtet, übersieht die eigentliche Stärke: Hierarchien. Ein WPScan-Export enthält typischerweise Informationen zum Ziel, zur erkannten WordPress-Installation, zu Versionen, Komponenten, Konfigurationen und potenziellen Schwachstellen. Diese Struktur ist entscheidend, weil ein Finding ohne Kontext leicht falsch priorisiert wird. Ein verwundbares Plugin ist etwas anderes als ein bloßer Hinweis auf eine freigelegte Datei oder eine erkennbare Login-Oberfläche.

Ein vereinfachter Ausschnitt kann so aussehen:

<wpscan>
  <target_url>https://target.tld</target_url>
  <wordpress_version>6.4.3</wordpress_version>
  <interesting_findings>
    <finding>
      <type>xmlrpc</type>
      <url>https://target.tld/xmlrpc.php</url>
      <confidence>100</confidence>
    </finding>
  </interesting_findings>
  <plugins>
    <plugin>
      <name>contact-form-7</name>
      <version>5.7.1</version>
      <vulnerabilities>
        <vulnerability>
          <title>Example Vulnerability</title>
          <fixed_in>5.7.2</fixed_in>
        </vulnerability>
      </vulnerabilities>
    </plugin>
  </plugins>
</wpscan>

Entscheidend ist nicht nur, dass ein Element vorhanden ist, sondern wie sicher es erkannt wurde und auf welcher Methode die Erkennung basiert. Ein Plugin kann durch Readme-Dateien, Asset-Pfade, HTML-Referenzen oder direkte Requests identifiziert werden. Diese Unterschiede beeinflussen die Verlässlichkeit. Wer XML automatisiert auswertet, sollte deshalb nicht nur auf Namen und Versionen filtern, sondern auch auf Erkennungsquelle, Confidence und Vollständigkeit achten. Sonst werden aus Indikatoren vorschnell harte Befunde.

Besonders relevant ist das bei Themen wie Version Detection, Plugin Enumeration und Theme Enumeration. Eine XML-Datei ist nur so gut wie die Erkennung, die sie speist. Wenn eine Version nicht eindeutig bestimmt werden konnte, darf ein Parser nicht so tun, als sei sie sicher bekannt. Genau an dieser Stelle scheitern viele hausinterne Automatisierungen: Sie behandeln jedes XML-Feld als Wahrheit, obwohl manche Felder nur Hinweise mit unterschiedlicher Sicherheit darstellen.

Saubere Auswertung bedeutet daher, die XML-Struktur fachlich zu lesen. Ein Element ist nicht nur ein Datenpunkt, sondern Teil einer Beweiskette. Wer das versteht, kann XML-Output für belastbare Berichte, Deltas zwischen Scans und technische Priorisierung nutzen. Wer das ignoriert, baut auf scheinbar präzisen, tatsächlich aber unscharfen Daten auf.

Der häufigste Fehler ist banal: Es wird zwar XML angefordert, aber die Datei wird nie geprüft. Viele verlassen sich darauf, dass ein erfolgreicher Prozess automatisch eine vollständige, valide Ausgabe erzeugt. In der Realität brechen Scans durch Netzwerkprobleme, WAF-Reaktionen, Timeouts oder API-Limits ab. Das Resultat kann eine unvollständige Datei sein, die formal existiert, aber fachlich wertlos ist. Ein Parser, der nur auf Dateiexistenz prüft, verschleiert diesen Zustand.

Ein weiterer Klassiker ist die Vermischung unterschiedlicher Scan-Typen unter demselben Dateinamen. Wenn ein erster Lauf passiv war und ein zweiter aggressiv, aber beide in dieselbe Datei oder denselben Report-Ordner geschrieben werden, ist später kaum noch nachvollziehbar, welche Findings aus welchem Modus stammen. Das führt direkt zu Fehlinterpretationen. Ein Team sieht plötzlich zusätzliche Plugins und hält sie für neue Funde, obwohl nur die Erkennungsmethode geändert wurde. Wer solche Probleme wiederholt erlebt, sollte seine Abläufe mit Best Practices und Typische Fehler abgleichen.

Ebenso kritisch ist das blinde Vertrauen in API-angereicherte Schwachstelleninformationen. Wenn der API Token fehlt, abgelaufen ist oder das Limit erreicht wurde, kann die XML-Datei technisch korrekt sein, aber weniger Schwachstelleninformationen enthalten als erwartet. Ohne Plausibilitätsprüfung wirkt das wie ein sauberes Ergebnis. Tatsächlich fehlt nur der Datenabgleich mit der Vulnerability-Datenbank. Das ist besonders gefährlich in automatisierten Pipelines, weil dort oft nur das Endergebnis konsumiert wird.

• Unvollständige XML-Dateien nach Abbruch oder Timeout werden als vollständige Reports behandelt.
• Mehrere Scan-Modi oder Rescans überschreiben sich gegenseitig und zerstören Vergleichbarkeit.
• Parser werten Hinweise, Confidence-Werte oder unsichere Versionen als harte Tatsachen.

Auch Encoding- und Sonderzeichenprobleme werden unterschätzt. Zielsysteme liefern gelegentlich unerwartete Header, ungewöhnliche Zeichenketten oder Inhalte, die Parser aus dem Tritt bringen. Wenn ein nachgelagertes Skript XML nicht robust verarbeitet, scheitert nicht der Scan, sondern die Auswertung. Das ist in der Praxis oft schwerer zu erkennen als ein offensichtlicher Fehler im Terminal. Deshalb gehört zu jedem XML-Workflow eine Validierung der Datei und ein Test mit realistischen Sonderfällen.

Wenn Probleme auftreten, ist eine systematische Analyse nötig. Dazu gehören Wpscan Fehlerbehebung, Debug Mode und Verbose Mode. Ohne diese Hilfsmittel bleibt oft unklar, ob der Fehler im Scan, im Netzwerk oder erst im XML-Handling entstanden ist.

Ein XML-Report ist erst dann nützlich, wenn er zuverlässig weiterverarbeitet werden kann. Dazu gehört zunächst eine technische Validierung. Nicht jede Datei mit .xml-Endung ist automatisch sauber parsebar. Schon ein abgebrochener Schreibvorgang oder ein unerwartetes Zeichen kann Folgeprozesse stoppen. In einfachen Umgebungen reicht oft ein schneller Syntax-Check mit Standardwerkzeugen:

xmllint --noout reports/target.tld-full.xml

Für die eigentliche Auswertung gibt es mehrere Wege. In Shell-lastigen Umgebungen werden häufig XPath- oder XSLT-basierte Ansätze genutzt. In Python, Ruby oder Go ist ein DOM- oder SAX-Parser meist flexibler. Entscheidend ist, dass das Parsing nicht nur Werte extrahiert, sondern Kontext mitnimmt. Ein Plugin-Name ohne Version, Confidence oder zugehörige Schwachstellen ist für Priorisierung nur begrenzt brauchbar. Gute Parser erzeugen deshalb interne Datenmodelle, die Ziel, Scan-Zeitpunkt, Erkennungsmethode und Findings gemeinsam abbilden.

Ein minimalistischer Python-Ansatz kann so aussehen:

import xml.etree.ElementTree as ET

tree = ET.parse("reports/target.tld-full.xml")
root = tree.getroot()

for plugin in root.findall(".//plugin"):
    name = plugin.findtext("name")
    version = plugin.findtext("version")
    print(f"{name} - {version}")

Für echte Praxis reicht das nicht. Ein belastbarer Parser muss mit fehlenden Feldern, mehrfachen Einträgen, optionalen Knoten und wechselnden Strukturen umgehen. Außerdem sollte er zwischen nicht vorhanden und nicht erkannt unterscheiden. Das klingt klein, ist aber fachlich zentral. Ein nicht gefundenes Plugin ist nicht dasselbe wie ein Plugin, das sicher nicht vorhanden ist. Diese Unterscheidung entscheidet später über False Negatives und Berichtssicherheit.

Wer XML in größere Abläufe integriert, sollte die Ausgabe nicht direkt in finale Reports schreiben, sondern zunächst in eine Normalisierungsschicht überführen. Dort werden Felder vereinheitlicht, Confidence-Werte interpretiert, Duplikate entfernt und technische Artefakte bereinigt. Erst danach folgt die Übergabe an Reporting, Report Analyse oder Security Report. Diese Trennung verhindert, dass Rohdaten unreflektiert in Management- oder Entwicklerberichte gelangen.

In CI/CD- oder Batch-Umgebungen ist zusätzlich Fehlerbehandlung Pflicht. Wenn Parsing fehlschlägt, darf das nicht stillschweigend zu einem leeren Report führen. Besser ist ein harter Fehlerzustand mit klarer Meldung. Genau daran erkennt man reife Automatisierung: Nicht nur erfolgreiche Scans werden verarbeitet, sondern auch fehlerhafte Zustände werden sichtbar gemacht.

XML entfaltet seinen größten Wert in automatisierten Abläufen. Einzelne manuelle Scans profitieren zwar ebenfalls, aber echte Stärke zeigt sich bei wiederkehrenden Prüfungen, Multi-Target-Setups und standardisierten Reports. In solchen Szenarien muss jeder Scan dieselbe Struktur liefern, damit Ergebnisse vergleichbar bleiben. Genau deshalb ist XML in vielen Umgebungen das bevorzugte Austauschformat zwischen Scanner und nachgelagerten Systemen.

Ein typischer Workflow beginnt mit einer Zieliste, führt WPScan pro Host mit definierten Parametern aus und speichert pro Ziel eine XML-Datei. Danach folgt eine Sammelroutine, die alle Reports einliest, normalisiert und in eine zentrale Datenbasis überführt. Dort lassen sich Trends erkennen: neue Plugins, verschwundene Themes, geänderte Versionen oder plötzlich auftauchende Schwachstellen. Solche Deltas sind im Tagesgeschäft oft wertvoller als der einzelne Scan. Wer größere Umgebungen prüft, sollte sich mit Automation, Batch Scan, Pipeline und Ci Cd beschäftigen.

Ein einfaches Batch-Schema in Shell kann so aussehen:

while read url; do
  host=$(echo "$url" | sed 's#https\?://##' | tr '/' '_')
  wpscan --url "$url" --format xml --output "reports/${host}.xml"
done < targets.txt

Für produktive Nutzung muss das erweitert werden: Exit-Codes prüfen, Laufzeiten loggen, Fehler separat speichern, Dateinamen normieren und parallele Ausführung kontrollieren. Gerade bei parallelen Scans entstehen sonst Race Conditions, API-Limit-Probleme oder unvollständige Reports. XML löst diese Probleme nicht, macht sie aber sichtbar, wenn die Umgebung sauber gebaut ist.

• Jeder Scan braucht eindeutige Dateinamen und eine feste Ordnerstruktur.
• Fehlerhafte Läufe müssen getrennt von erfolgreichen Reports gespeichert werden.
• Vergleiche zwischen Scans dürfen nur bei identischen oder dokumentiert abweichenden Parametern erfolgen.

Ein weiterer Punkt ist die Archivierung. XML-Dateien sollten nicht nur als Zwischenprodukt betrachtet werden. In Audits, Incident-Nachbereitung oder Regressionstests sind historische Reports oft entscheidend. Wenn ein Plugin heute als verwundbar erkannt wird, ist die Frage relevant, ob es vor vier Wochen bereits vorhanden war und nur nicht sauber erfasst wurde. Ohne archivierte XML-Rohdaten bleibt diese Frage oft unbeantwortet.

In reifen Umgebungen wird XML daher nicht nur erzeugt, sondern versioniert, signiert oder zumindest mit Hashes versehen. Das ist besonders sinnvoll, wenn Ergebnisse in Compliance-nahe Prozesse oder externe Prüfungen einfließen. So bleibt nachvollziehbar, dass ein Report nicht nachträglich verändert wurde.

XML wirkt präzise, weil alles sauber strukturiert ist. Genau darin liegt eine Gefahr: Struktur wird leicht mit Wahrheit verwechselt. Ein XML-Knoten sieht verbindlich aus, auch wenn der zugrunde liegende Fund nur ein Indikator ist. In der Praxis müssen deshalb immer drei Ebenen getrennt werden: technische Erkennung, fachliche Interpretation und operative Priorisierung. Wenn diese Ebenen vermischt werden, entstehen klassische Fehlbewertungen.

False Positives entstehen oft dann, wenn Erkennungsmuster zu breit sind oder wenn Artefakte gecachter Inhalte, CDN-Reste oder generische Dateipfade als echte Komponenten interpretiert werden. Ein Plugin-String in einer alten JavaScript-Referenz bedeutet nicht zwingend, dass das Plugin aktiv oder überhaupt installiert ist. Umgekehrt entstehen False Negatives, wenn WAFs Requests blockieren, Readme-Dateien entfernt wurden oder Versionen absichtlich verschleiert sind. XML bildet diese Unsicherheit nicht automatisch ausreichend ab. Die Auswertung muss sie aktiv berücksichtigen. Dazu passen False Positives und False Negatives als feste Prüfpunkte.

Besonders heikel ist die automatische Zuordnung von Schwachstellen zu Komponenten. Wenn eine Plugin-Version unsicher erkannt wurde, darf eine CVE-Zuordnung nicht wie ein bestätigter Befund behandelt werden. Saubere Workflows markieren solche Fälle als verifizierungsbedürftig. Das gilt auch für Themen wie Vulnerability Database, Cve Nutzung und Exploit Mapping. Ein XML-Parser sollte nicht nur Treffer extrahieren, sondern Unsicherheit konservieren.

Ein robuster Bewertungsansatz fragt daher immer:

Wurde die Komponente direkt oder indirekt erkannt? Ist die Version bestätigt oder nur geschätzt? Stammt die Schwachstellenzuordnung aus einer belastbaren Versionsbasis? Wurde der Scan durch Schutzmechanismen beeinflusst? Gibt es Hinweise auf Blockaden, Redirects oder unvollständige Antworten? Erst wenn diese Fragen beantwortet sind, wird aus XML ein belastbarer Befund.

In professionellen Assessments wird deshalb häufig ein zweistufiges Modell genutzt: automatische XML-Auswertung zur Vorpriorisierung, danach manuelle Verifikation kritischer Findings. Das spart Zeit, ohne die Qualität zu opfern. Wer XML direkt in finale Aussagen übersetzt, spart kurzfristig Aufwand und produziert langfristig Diskussionen, Nacharbeit und Vertrauensverlust.

Viele XML-Probleme sind in Wahrheit Netzwerkprobleme. Wenn ein Ziel langsam antwortet, Requests drosselt oder durch vorgeschaltete Schutzsysteme gefiltert wird, landet das Ergebnis als scheinbar normaler Report auf der Platte. Der Scanner hat dann vielleicht nur einen Teil der Oberfläche gesehen. Ohne Blick auf Transportebene und Request-Verhalten wird das leicht übersehen.

Typische Ursachen sind Timeouts, Redirect-Ketten, TLS-Besonderheiten, Proxy-Fehlkonfigurationen, Cloud-WAFs oder IP-basierte Rate Limits. In solchen Fällen ist XML nicht falsch, sondern unvollständig. Genau deshalb muss jeder ernsthafte Workflow technische Telemetrie mitdenken. Dazu gehören Laufzeit, Anzahl erfolgreicher Requests, Fehlerraten und Hinweise auf Blockaden. Wenn diese Informationen fehlen, ist die XML-Datei isoliert betrachtet nur bedingt aussagekräftig.

Praktisch bedeutet das: Bei verdächtig dünnen Reports nicht sofort von einem sauberen Ziel ausgehen. Erst prüfen, ob Schutzmechanismen oder Verbindungsprobleme die Sicht eingeschränkt haben. Relevante Themen sind hier Timeouts, Verbindungsfehler, Firewall Block, Proxy und Rate Limit. Auch ein Wechsel zwischen direkter Verbindung und Proxy kann Ergebnisse stark verändern, obwohl derselbe XML-Exportmechanismus verwendet wird.

Ein realistisches Muster aus der Praxis: Ein erster Scan liefert kaum Plugins und keine Benutzer. Ein zweiter Lauf mit angepassten Timeouts, reduzierter Geschwindigkeit und sauberem Header-Handling findet plötzlich mehrere Komponenten. Der Unterschied liegt nicht im XML, sondern in der Erreichbarkeit und Beobachtbarkeit des Ziels. Wer nur die Enddateien vergleicht, sieht neue Findings. Wer den Transportkontext mitdenkt, erkennt einen Erkennungsbias des ersten Laufs.

Deshalb sollte jede XML-Datei mit Begleitinformationen verknüpft werden: Scan-Zeitpunkt, verwendete IP oder Proxy, Modus, Timeouts, Exit-Code und idealerweise ein separates Log. So lässt sich später erklären, warum zwei Reports voneinander abweichen. Ohne diese Daten bleibt nur Spekulation, und genau das ist in Audits oder Incident-Nachweisen problematisch.

Der eigentliche Wert von XML liegt nicht in der Datei selbst, sondern in der Qualität der Entscheidungen, die daraus folgen. Ein guter Workflow endet nicht beim Export, sondern bei einer nachvollziehbaren Bewertung. Dazu gehört, Rohdaten von bestätigten Befunden zu trennen, Unsicherheiten sichtbar zu halten und technische Details so aufzubereiten, dass Entwickler, Administratoren und Security-Verantwortliche damit arbeiten können.

Ein belastbarer Abschlussbericht basiert deshalb nicht direkt auf XML, sondern auf verifizierten und priorisierten Ergebnissen. Ein Plugin mit bekannter Schwachstelle wird erst dann zum belastbaren Finding, wenn Version, Erreichbarkeit und Relevanz geprüft wurden. Ein offenes xmlrpc.php ist zunächst ein technischer Befund; ob daraus ein echtes Risiko entsteht, hängt vom Gesamtkontext ab, etwa Login-Schutz, Rate Limits oder zusätzlicher Härtung. XML liefert die Bausteine, nicht automatisch die Schlussfolgerung.

• Rohdaten aus XML zuerst normalisieren und auf Vollständigkeit prüfen.
• Kritische Findings manuell verifizieren, bevor sie als bestätigte Schwachstellen gemeldet werden.
• Berichte immer mit Scan-Kontext, Parametern und Einschränkungen versehen.

Für die operative Nutzung lohnt sich eine klare Trennung zwischen technischen Detailreports und Management-Sicht. Entwickler brauchen Pfade, Versionen, Erkennungsmethoden und Fix-Hinweise. Verantwortliche auf höherer Ebene brauchen Priorität, Auswirkung und Handlungsbedarf. XML kann beide Sichten speisen, wenn die Aufbereitung sauber erfolgt. Wer alles ungefiltert übernimmt, erzeugt entweder überladene Berichte oder gefährlich verkürzte Aussagen.

In der Praxis hat sich bewährt, XML als Rohquelle zu archivieren, daraus ein internes Normalformat zu erzeugen und erst dann Berichte oder Tickets abzuleiten. So bleibt die Beweiskette erhalten, während operative Systeme mit bereinigten Daten arbeiten. Dieser Ansatz ist besonders stark in wiederkehrenden Prüfungen, Audits und größeren WordPress-Landschaften. Er reduziert Diskussionen, verbessert Vergleichbarkeit und macht aus einem simplen Export einen belastbaren Bestandteil professioneller Sicherheitsarbeit.

Wer XML-Output so einsetzt, bekommt keine bloße Datei, sondern einen reproduzierbaren, prüfbaren und teamfähigen Workflow. Genau darin liegt der Unterschied zwischen einem Scan, der nur gelaufen ist, und einem Ergebnis, das sich fachlich verteidigen lässt.