softwarefabrik.io
Offline-Verifier · 1.1.0

Nachweise prüfen, ohne der Fabrik zu glauben.

Ein Audit-Export der Fabrik lässt sich mit diesem Werkzeug ohne Zugriff auf die Fabrik prüfen: ob Einträge verändert, weggelassen oder am Ende abgeschnitten wurden, welche Policy für einen Lauf galt und ob alles mit einem vertrauten Schlüssel signiert ist.

nur JDK, keine Abhängigkeiten rund 1 000 Zeilen Java reproduzierbar gebaut

Download

Version 1.1.0, für Exporte ab Schema 2.0 (Fabrik ab v0.32.0); prüft bei Schema 2.1 (Fabrik ab v0.39.0) zusätzlich die signierten Spec-Fassungen und deren Bindung an die Läufe. Benötigt ein JDK 25 oder neuer.

Das Werkzeug kommt bewusst nicht aus der Fabrik, die geprüft wird: Ein Prüfwerkzeug bezieht man nicht von der geprüften Partei. Der Build ist reproduzierbar — zwei Builds aus demselben Quelltext ergeben Byte für Byte dasselbe JAR. Nachbauen: Quelltext entpacken, mvn package mit JDK 25 auf einem Linux-Dateisystem (auf NTFS-Laufwerken unter WSL weichen nur die Dateirechte der JAR-Einträge ab, nicht der Inhalt).

Was Sie brauchen

  1. Den Export — in der Fabrik unter Audit-Export als JSON, je Projekt oder Lauf.
  2. Den Fingerabdruck des Signaturschlüssels — in der Fabrik unter Attestierung → Vertrauensanker. Lassen Sie ihn sich auf einem zweiten Weg bestätigen (Brief, Ticket, signierte E-Mail): Wer Einträge fälscht, kann auch den Schlüssel im Export austauschen.
  3. Den Verifier von dieser Seite.
java -jar softwarefabrik-verifier-1.1.0.jar audit-export.json --schluessel <fingerabdruck>
ExitBedeutung
0Bewiesen: Kette, Signaturen und Lauf-Nachweis gegen die vertrauten Schlüssel belegt
1Verletzung: verändert, unvollständig, fremd signiert oder in sich widersprüchlich
2Keine Verletzung, aber nicht alles beweisbar — etwa ohne --schluessel
3Aufruffehler

Ohne --schluessel endet die Prüfung nie mit 0. Mit --bekannt <seq>:<hash> übergeben Sie einen früher gesehenen Kettenstand, der unverändert enthalten sein muss.

Was geprüft wird

  1. Schlüssel: Fingerabdruck jedes Public Keys gegen Ihre vertrauten Werte.
  2. Einträge: Hash aus der dokumentierten kanonischen Form nachrechnen, Ed25519-Signatur prüfen.
  3. Stellvertreter: Einträge anderer Läufe und Mandanten erscheinen nur als Hash mit Signatur — so ist Vollständigkeit prüfbar, ohne fremde Inhalte offenzulegen.
  4. Verkettung: lückenlose Folge, jeder Eintrag verweist auf seinen Vorgänger. Weglassen, Einfügen und Umordnen fallen auf.
  5. Kopf: Die Kette endet genau am signierten Kopf — sonst fehlen Einträge am Ende.
  6. Policy: die im Lauf angewandte Version, Inhalt und Signatur.
  7. Lauf-Nachweis: welche Ereignisse zu einem Lauf gehören, bezeugt ein signiertes Manifest; jedes muss als geprüfter Eintrag dieses Laufs vorliegen.

Felder, in denen die Fabrik über sich selbst urteilt („intakt“, „Kette ok“), gelten nicht als Beleg.

Grenzen

  • Bewiesen wird die Unversehrtheit ab dem ersten exportierten Eintrag und bis zum Exportzeitpunkt.
  • Wer vor dem Export Datenbankzugriff hatte, könnte die neuesten Einträge löschen und den Kopf zurücksetzen. Dagegen hilft --bekannt mit einem früher festgehaltenen Stand.
  • Die Vollständigkeit der Zuordnung von Ereignissen zu einem Lauf bezeugt die Fabrik mit ihrer Signatur zum Exportzeitpunkt.
  • Tool-Aufrufe der Agenten stehen nur in der Kette, wenn sie über den MCP-Gateway laufen (seit v0.34, opt-in, als MCP_TOOL_AUFRUF); die eingebauten Werkzeuge der Agent-CLIs (Dateien, Shell) nicht.

Hintergrund und Entscheidungen: ADR-0023 „Offline-Verifier für den Audit-Export“.