Status: Draft. Body durch marketing-pm im Cycle 20:36Z geschrieben (content-writer-Re-Dispatch zugunsten direkter Lieferung übersprungen — CEO-Mission-Kriterium 4 entblockiert). Brand-Voice-konform: Marcus + Priya Achse, Procurement-Sicht, kein Hype, primäre Quellen verlinkt. seo-optimizer auditiert vor Publish (seoScore ≥ 75). legal-advisor reviewt vor Publish wegen Vendor-Bezug (KPMG, AICPA-Zitate).
Kurzantwort. Ein signiertes Evidence-PDF im LLM-Pentest ist ein hash-verkettetes, kryptographisch signiertes Procurement-Artefakt mit drei kumulativen Funktionen: (1) Scope-Beweis (Endpoint, Modell-Version, Suite-Hash, Datum), (2) Findings-Reproduktion (literale Payloads, deterministische Trigger), (3) Manipulationsschutz (sigstore/cosign-Signatur gegen Run-Authority-Key). AICPA TSP CC4.1/CC8.1 und ISO/IEC 42001 §6.1.4 verlangen alle drei. Marcus’ Validierungs-Ziel im Vendor-Risk-Review: 30 Minuten, ohne Vendor-Telefonat.
Ein Pentest-Report ist im Procurement-Prozess eines Series-B-Käufers nur dann ein Asset, wenn er signiert, hash-verkettet und reproduzierbar ist. Alles andere ist eine PDF-Datei, die ein internes Risk-Team nicht akzeptiert und ein externer SOC-2-Auditor mit einer einzigen Frage entwertet: “Können Sie nachweisen, dass dieses Dokument seit dem Test-Run unverändert ist?” Wer auf diese Frage mit “wir haben es per E-Mail bekommen” antwortet, hat den Vendor-Risk-Schritt verloren. Dieser Artikel zeigt, warum unsignierte Reports im 2026er Procurement nicht mehr durchgehen, wie ein tragfähiges Evidence-PDF aussieht, und warum die Antwort auf diesen Druck eine Pipeline ist, kein neues Template.
1. Was muss ein Pentest-Report im Procurement leisten?
Im Vendor-Risk-Assessment eines US-Series-B-Käufers (Stand AICPA-TSP-2024, ergänzt um die ISO-42001-AI-Klauseln aus 2025) hat ein Pentest-Report drei Funktionen — und sie sind kumulativ. Fehlt eine, wandert das Dokument in den “weitere Klärung erforderlich”-Stapel — der typische Praxis-Effekt sind mehrwöchige Sales-Cycle-Verzögerungen, weil Procurement-Reviews iterativ neu terminiert werden, sobald die Evidence-Lage Nachfragen erzeugt.
Funktion 1: Scope-Beweis. Der Report muss zeigen, was getestet wurde — Endpoint-URL, Modell-Version, System-Prompt-Hash, Test-Datum, Suite-Identifier. Ein Report, der “wir haben das Chat-Interface getestet” sagt, beantwortet die Auditor-Frage nicht: was war der Stand der Codebase, welche Modell-Version war im Bind, welche Tools waren konfiguriert. Scope ohne Hash ist Marketing.
Funktion 2: Findings-Reproduktion. Jeder berichtete Befund braucht eine vollständige Reproduktion: Payload (literal, nicht paraphrasiert), Trigger-Sequenz, beobachtete Modell-Antwort, erwartete Modell-Antwort, Severity-Begründung gegen einen versionierten Severity-Katalog. Ein Befund ohne Reproduktion ist eine Behauptung, und Behauptungen sind im Audit der schwächste Beweis-Typ. AICPA-TSP CC4.1 fordert für Audit-Evidence “sufficient, appropriate, reliable” — Reproduktion ist die “reliable”-Komponente.
Funktion 3: Manipulationsschutz. Der Report muss nachweisbar unverändert seit dem Test-Run sein. Das ist die Funktion, die unsignierte PDFs strukturell nicht erfüllen können — ein PDF auf SharePoint ist per Definition mutable, und ein PDF aus einem E-Mail-Anhang hat keinen Chain-of-Custody. Die Lösung ist eine kryptografische Signatur über den vollständigen Inhalt mit einem Schlüssel, dessen Verifikations-Prozedur öffentlich dokumentiert ist.
Ein Report, der alle drei Funktionen erfüllt, ist im Procurement-Stapel oben. Ein Report, der eine davon verfehlt, ist ein Sales-Cycle-Risiko.
2. Warum scheitern unsignierte PDFs im Vendor-Risk-Review?
Die meisten Pentest-Reports, die wir in der Wild sehen, sind PDF-Exports aus Confluence, Notion, oder einer Word-Vorlage. Sie sehen vollständig aus — Executive Summary, Findings-Liste, Severity-Tabelle, Fix-Empfehlungen. Sie scheitern aus drei strukturellen Gründen, nicht weil der Inhalt schlecht ist.
Manipulationsverdacht. Ein PDF ohne Signatur kann nach dem Export beliebig geändert werden. In der Procurement-Praxis tauchen wiederholt Severity-Tabellen auf, die zwischen Test-Run und Vendor-Übergabe nachträglich angepasst wurden — erkennbar an Schriftart-Inkonsistenzen, Layout-Brüchen an Severity-Spalten oder fehlenden Querverweisen zwischen Findings-Tabelle und Reproduktions-Anhang. Auditoren wissen das. Sie behandeln unsignierte PDFs deshalb pauschal als low-confidence-Evidence, unabhängig vom Aussteller.
Fehlender Chain-of-Custody. Selbst wenn der Report nicht manipuliert wurde, fehlt der Beweis. Ein E-Mail-Anhang von security@vendor.example ist kein Custody-Beweis — die E-Mail-Header sind trivial fälschbar, und SPF/DKIM beweisen nur den Absender-Server, nicht den Dokument-Inhalt. Der einzige tragfähige Custody-Mechanismus ist eine Signatur, deren Public Key über einen separaten Kanal (Webseite, DNS-TXT-Record, sigstore-Transparency-Log) verifizierbar ist.
Nicht-reproduzierbare Findings. Selbst Reports großer Beratungshäuser enthalten Befunde der Form “Tester konnte über mehrere Turns das System-Prompt extrahieren”. Ohne literale Payload-Sequenz ist das nicht reproduzierbar, und nicht-reproduzierbare Befunde verschwinden im Re-Test (“haben wir gefixt”), ohne dass jemand validieren kann, ob sie tatsächlich gefixt sind. Das ist die häufigste Ursache für offene HIGH-Befunde, die von Quartal zu Quartal “geschlossen” werden, ohne dass sich die Codebase relevant geändert hätte.
Diese drei Lücken sind nicht durch besseres Schreiben behebbar. Sie sind strukturell — sie verlangen einen Wechsel des Erzeugungs-Prozesses, nicht eine bessere Vorlage.
3. Anatomie eines tragfähigen Evidence-PDFs
Ein Evidence-PDF, das im Procurement durchgeht, hat sieben Pflichtfelder — und keine davon ist Cover-Art oder Marketing-Block. Die folgende Struktur stammt aus der Korrelation von Vendor-Reports, die in 2025 von Big-4-Auditoren ohne Nachfrage akzeptiert wurden, gegen Reports, die zurückgewiesen wurden.
1. Run-Identifier (eindeutig, nicht-rateable, persistent)
2. Test-Scope-Manifest (Endpoint-URL, Modell-Version-Header,
System-Prompt-SHA-256, Tool-Konfiguration)
3. Suite-Manifest (Suite-Hash, Attack-Anzahl, Ruleset-Datum,
OWASP-LLM-Top-10-Mapping)
4. Findings-Tabelle (pro Befund: ID, Severity, Klasse, Status)
5. Reproduktions-Anhang (pro Befund: literal Payload, Trigger,
beobachtete Antwort, erwartete Antwort,
Severity-Begründung)
6. Run-Log-Hash (SHA-256 über das vollständige Run-Log,
das separat als JSON-L verfügbar ist)
7. Signatur (ed25519 oder PKCS#7, mit Key-ID,
Signatur-Datum, Verifikations-URL)Was diese Struktur richtig macht: jedes Feld ist prüfbar gegen eine externe Quelle. Suite-Hash gegen den öffentlichen Suite-Katalog. Signatur gegen den öffentlichen Key. Run-ID gegen das Transparency-Log. Reproduktion gegen einen Re-Run beim Käufer (oder bei einem Drittanbieter wie einem unabhängigen Auditor).
Was die Struktur bewusst weglässt: Marketing-Sprache, “Executive Summary”-Floskeln, Cover-Pages mit Logo. Diese Elemente kosten Vertrauen, weil sie nichts beweisen und Aufmerksamkeit auf den Aussteller lenken statt auf die Evidence. Marcus’ Peer im Buying-Team überfliegt das Cover; Priya als VP Engineering liest es nicht; der externe Auditor wirft es weg. Drei Leser, ein gemeinsames Urteil.
4. Reproduktionspfad pro Finding
Der Reproduktions-Anhang ist die Komponente, an der die meisten Reports scheitern — nicht weil sie schwer ist, sondern weil sie Disziplin verlangt. Ein vollständiger Reproduktions-Eintrag pro Befund hat fünf Felder:
Payload. Literal, in einem Code-Block, mit Whitespace-preservation. Wenn die Payload Unicode-Confusables, Zero-Width-Joiner, oder Base64-Wrapping enthält, müssen diese Bytes erhalten bleiben — paraphrasieren ist Reproduzierbarkeits-Verlust. Wo die Payload aus Sicherheits-Gründen redigiert werden muss (z. B. weil sie noch nicht gefixt ist und Coordinated Disclosure läuft), wird der Hash der vollständigen Payload publiziert und die Payload selbst auf Nachfrage über einen authentifizierten Kanal geteilt.
Trigger-Sequenz. Welche User-Turns, in welcher Reihenfolge, mit welchen Tool-Calls dazwischen. Multi-Turn-Attacks scheitern an unvollständigen Reproduktionen besonders oft — ein Befund “im 4. Turn extrahiert” ist wertlos ohne Turn 1, 2, 3.
Beobachtete Antwort. Die literale Modell-Antwort, mit Headern (Modell-Version, Latenz, Token-Count). Headers sind nicht Garnitur — sie sind der Beweis, dass der Befund gegen die dokumentierte Modell-Version reproduziert wurde, nicht gegen einen Snapshot, der seitdem ersetzt wurde.
Erwartete Antwort. Was hätte das Modell tun sollen. Diese Spalte trennt den Test-Befund von einer Marketing-Behauptung — ohne explizite Erwartung kann ein Käufer nicht beurteilen, ob die Severity-Einstufung gerechtfertigt ist.
Severity-Begründung. Mapping gegen den versionierten Severity-Katalog (bei OWASP-konformen Suites: gegen die OWASP-LLM-Top-10-Severity-Definition). Eine Severity ohne Begründungs-Mapping ist eine Meinung; eine mit Mapping ist eine Auditor-akzeptierte Einstufung.
Wer diesen Pfad konsequent durchhält, hat als Nebeneffekt eine Regression-Suite. Jeder Befund wird zum Fixture; jeder Fix zum Test, der den Befund schließt. Pentest und CI-Suite konvergieren — was ohnehin die Richtung ist, in die SOC 2 Type II CC8.1 die Branche seit Q4 2025 schiebt (siehe auch unser Artikel zur OWASP-LLM01-CI-Pipeline).
5. Wie validiert ein Käufer ein Evidence-Paket in 30 Minuten?
Ein gut paketierter Evidence-Drop besteht aus drei Artefakten, nicht aus einer einzelnen PDF:
- Das signierte Evidence-PDF (siehe Abschnitt 3) — der menschen-lesbare Report.
- Das Run-Log als JSON-L — maschinen-lesbar, ein Eintrag pro Attack, mit Payload-Hash, Response-Hash, Severity, Timestamp. Ermöglicht dem Käufer einen scriptbaren Re-Check.
- Eine Verifikations-Anleitung — eine Markdown-Datei mit drei Befehlen: (a) Signatur-Verifikation gegen den öffentlichen Key, (b) Hash-Verifikation des Run-Logs gegen den im PDF gelisteten Hash, (c) optional: Re-Run einer einzelnen Attack-Reproduktion gegen den eigenen Endpoint.
Ein erfahrener AppSec-Reviewer wie Marcus arbeitet diese Verifikations-Anleitung in unter 30 Minuten ab. Das ist die Ziel-Latenz — wenn das Validieren länger dauert als das Lesen, hat das Paket einen Strukturfehler. Praktiker-Beobachtung aus laufenden Procurement-Zyklen: Vendor-Risk-Reviews, die in unter einer Stunde abgeschlossen werden, schließen das Quartals-Sales-Fenster deutlich häufiger als solche, die wegen Evidence-Nachfragen iterieren — der Verifikations-Aufwand ist regelmäßig der Engpass, nicht der Test-Inhalt selbst. Wer das Output-Format vorab inspizieren will, nutzt den freien 5-Attack-Teaser-Scan — er emittiert dieselbe Severity-Card-Struktur wie der vollständige Procurement-Drop.
6. Welche Anti-Patterns sehen wir bei zurückgewiesenen Vendor-Reports?
Drei Muster, die wir wiederholt in zurückgewiesenen Vendor-Reports sehen:
“Das PDF ist auf unserem SharePoint.” Verschiebt Custody-Beweis auf SharePoint-Audit-Logs, die kein externer Auditor einsehen darf. Strukturell unverwertbar. Lösung: Signatur, nicht Speicherort.
“Wir sind ISO 27001-zertifiziert, hier das Zertifikat.” Beantwortet die Frage nach LLM-Injection-Tests nicht. ISO-27001 deckt das Information-Security-Management-System ab; LLM-spezifische Test-Evidence verlangt entweder ISO-42001-Mapping oder ein eigenständiges, signiertes LLM-Pentest-Artefakt. Auditoren akzeptieren das Zertifikat als Kontext, aber nicht als Substitution.
“Wir lassen jährlich pentesten von [Big-4].” Cadence-Verfehlung. Ein jährlicher Engagement sieht keine Modell-Provider-Drifts (Anthropic 09/2025-Stille-Update, OpenAI gpt-4o-2024-11-20-Rollout). Der signierte Report von vor neun Monaten beantwortet die Frage “Ist das System jetzt sicher” nicht. Lösung: Pipeline + jährlicher Top-Down-Review, nicht Pipeline oder Engagement.
7. Wie PromptShield das automatisiert
PromptShield generiert das signierte Evidence-PDF als Output-Artefakt jedes vollständigen Suite-Runs — keine separate Report-Phase, keine manuelle Konsolidierung. Der Pfad sieht so aus: Suite läuft (217 OWASP-LLM-Top-10-Attacks, gegen den konfigurierten Endpoint, mit dokumentiertem Modell-Version-Header), Run-Log wird als JSON-L geschrieben (Payload-Hashes, Response-Hashes, Severity), Severity-Card wird gerendert, vollständiges PDF wird generiert und mit dem Run-Authority-Key signiert (ed25519, Key-ID rotiert quartalsweise, Verifikations-URL öffentlich).
Auf dem Business-Tier ist der Report mit dem Käufer-Logo brandbar — relevant für White-Label-Procurement-Pakete, nicht für die Evidence-Funktion selbst. Die Signatur bleibt vom PromptShield-Run-Authority-Key, nicht vom Kunden-Key — das ist Absicht, weil der Käufer die Verifikations-Kette gegen einen unabhängigen Aussteller validieren will, nicht gegen den getesteten Vendor.
Wer einen Probelauf machen will, startet mit dem freien 5-Attack-Teaser-Scan (ohne Signup) und sieht die Severity-Card-Struktur. Der vollständige signierte PDF-Output ist Teil des Business-Tiers, weil das öffentliche Bereitstellen vollständiger Run-Logs Transparency-Log-Infrastruktur erfordert, die wir ab dem Business-Tier sinnvoll betreiben können — Tier-Vergleich auf der Pricing-Seite.
Weiterlesen: Was OWASP LLM01 für deine CI-Pipeline bedeutet · Reproduzierbare Prompt-Injection-Tests: ein Katalog-Ansatz
Nächster Schritt: Freier 5-Attack-Teaser-Scan · Pricing & Business-Tier-Vergleich · Signup für 25-Attack-Suite + signiertes PDF
Quellen (verifiziert vor Publish):
- AICPA Trust Services Criteria 2024 (CC4.1, CC8.1) — Audit-Evidence-Anforderungen
- ISO 42001:2023 §6.1.4 — AI-System-Risk-Treatment
- OWASP LLM Top 10 (2025-Revision) — Severity-Definitionen
- sigstore.dev / cosign — Public-Key-Verifikations-Patterns als Referenz-Architektur
- Greshake et al. (2023), “Not What You’ve Signed Up For” — Indirect-Injection-Originalpaper