Crucible · Model Vetting Firewall

Ein sauberer Scan lässt die Ladefrage offen

Ein synthetisches Modell besteht die PickleScan-Baseline und versucht anschließend beim Laden, eine Datenbank zu öffnen. Crucible erfasst und blockiert diesen konfigurierten Effekt und gibt QUARANTINE mit angehängter Evidenz zurück.

23/23 vs 19/23

Erkennung blockierter Ereignisse vs. PickleScan-Flags

Dieselben 23 synthetischen Fixtures aus Schadcode und Evadern

4/4 vs 0/4

Vier konstruierte Evader

Verhaltensbasierte Erkennung vs. PickleScan 1.0.4

2/2

Enthaltungs-Fixtures an REVIEW weitergeleitet

Weitere Evidenz erforderlich; keine Signatur ausgestellt

Karten berichten über einen einzelnen festen synthetischen Direct-Pipeline-Referenzlauf mit 33 Artefakten vom 6. Oktober 2026 mit deterministischer Beurteilung. Sie schätzen die Erkennung bei unbekannten Modellen nicht ab. Das Video erfasst separat frische konfigurierte Prüfungen in der lokalen App: Die Hauptkonsole verwendet zwischengespeicherte Codex-Beurteilungen, und der Benchmark nutzt deterministische Beurteilungen. Es wird keine frische Modellinferenz erfasst.

Die Entscheidung benötigt Evidenz über das Ladeverhalten

Wenn ein Sicherheitsteam ein serialisiertes Modell genehmigt, reicht die relevante Frage über dessen deklarierte Identität hinaus: Welche Operation versucht der Ladevorgang, und welche Evidenz bleibt unaufgeklärt?

Python warnt davor, dass manipulierte Pickle-Daten beim Unpickling Code ausführen können. Die Pickle-Scanning-Dokumentation von Hugging Face beschreibt ebenfalls Grenzen der Import- und Opcode-Inspektion. Python-Pickle-Dokumentation; Hugging-Face-Pickle-Scanning-Dokumentation.

Unser synthetisches SQLite-Fixture macht diese Unterscheidung überprüfbar: Eine Baseline ohne Infektions-Flag steht neben einem blockierten Versuch, eine Datenbank zu öffnen. Der Zulassungsdatensatz bewahrt beide Befunde, anstatt das saubere Scanner-Feld als Freigabe zu behandeln.

Wie die konfigurierte Entscheidung getroffen wird

Unterstützten Pickle-Inhalt prüfen. Statische Opcode-Disassemblierung erfasst Globals und approximiert aufgerufene Callables. Die installierte PickleScan-Baseline liefert ein separates Vergleichsfeld; ihr Flag entscheidet das Urteil nicht direkt.
Einen Ladeversuch beobachten. Ein frischer Python-Subprozess nutzt einen CPython-Audit-Hook, um ausgewählte Ereignisse zu protokollieren und vor konfigurierten blockierten Effekten auszulösen, einschließlich SQLite- und Socket-Verbindungen. Dies ist eine Python-Instrumentierung mit Prozesstrennung, ohne Container- oder Betriebssystem-Isolierung.
Das Gate anwenden und Unsicherheit beibehalten. Ein blockiertes Verhaltensereignis führt zu QUARANTINE. Ein Runner-Absturz oder -Timeout, ein Pickle-Disassemblierungsfehler oder ein nicht ausgeführter gefährlicher statischer Global führt zu REVIEW. Andernfalls gibt das Basis-Gate ALLOW zurück; Zweifel des Challengers können ALLOW zu REVIEW ändern, während QUARANTINE in Kraft bleibt.
Einen abgegrenzten Datensatz anhängen. Jedes Ergebnis erhält ein minimales CycloneDX-förmiges Modellinventar und lokale Hash-Chain-Felder. Nur ALLOW erhält eine Signatur mit Entwicklungsschlüssel über Modellname, Artefakt-Hash und Inventar. Unbekannte Upstream-Historie bleibt UNKNOWN.

Die Beurteilung nutzt Analysten- und Challenger-Rollen in einer kombinierten Anfrage. Die aufgezeichnete Hauptkonsole verwendet zwischengespeicherten Rat; der Benchmark nutzt deterministische Beurteilungen. Diese konfigurierten Prüfungen garantieren nicht, dass jede fehlerhafte Datei, jedes nicht unterstützte Format oder jeder Analysefehler zu REVIEW weitergeleitet wird.

Einem Artefakt vom sauberen Scan bis zur Zulassungsentscheidung folgen

Alle Artefakte, Modellnamen und hf:// Quell-Labels unten sind synthetische lokale Fixtures, keine Kundenmodelle oder verifizierten Registry-Datensätze. Die ersten drei Screenshots erfassen frische konfigurierte Prüfungen mit zwischengespeicherter Codex-Beurteilung; die separate Benchmark-Erfassung nutzt deterministische Beurteilungen. Es wird keine frische Modellinferenz gezeigt.

Praxisbeispiel: eine saubere Baseline, ein blockierter Datenbankversuch

Das generierte trusted-looking/finetune-safe -Pickle versucht während der Deserialisierung, eine SQLite-Datenbank zu öffnen. Sein Name ist ein verfasstes Fixture-Label, kein Vertrauensbeweis. Die zielführende Frage ist, ob der Scanner-Befund und das beobachtete Ladeverhalten dieselbe Zulassungsentscheidung stützen.

Konfiguriertes Ergebnis

PickleScan: CLEAN. Beobachtete Operation: sqlite3.connect, versucht und blockiert. Endgültiges Urteil: QUARANTINE. Signatur: keine.

Synthetischer SQLite-Evader in Crucible mit PickleScan CLEAN, blockiertem sqlite3.connect und QUARANTINE — Synthetischer SQLite-Evader: PickleScan markiert das Artefakt nicht; der konfigurierte Audit-Hook erfasst und blockiert die versuchte Datenbankoperation. QUARANTINE stellt keine Signatur aus. NO CODE SURFACE bedeutet keinen Treffer bei konfigurierten gefährlichen Globals; _sqlite3.connect bleibt vorhanden. Der Sandbox-Wortlaut der Benutzeroberfläche bezieht sich auf Subprozess-Audit-Instrumentierung ohne Betriebssystem- oder Container-Isolierung. Bild zur Prüfung in Originalgröße öffnen.

1. Scanner- und statische Befunde getrennt lesen

PickleScan 1.0.4 erfasst _sqlite3.connect als verdächtig, ohne das Infektions-Flag zu setzen. Die statische Disassemblierung von Crucible behält dieses importierte Callable ebenfalls bei, es fehlt jedoch in der konfigurierten Menge gefährlicher Globals. Das sichtbare Badge NO CODE SURFACE bedeutet daher keinen Treffer bei konfigurierten gefährlichen Globals; es bedeutet nicht, dass die Datei kein ausführbares Callable enthält.

Evidenz für das synthetische SQLite-Artefakt
Prüfung	Erfasster Befund	Was dies feststellt
PickleScan-Baseline	`flagged: false`; `_sqlite3.connect [suspicious]`	Diese Baseline markiert das Artefakt nicht. Sie stellt kein harmloses Ladeverhalten fest.
Statische Disassemblierung	`_sqlite3.connect` in Importen und approximierten Callables; kein konfigurierter gefährlicher Global	Das Callable ist sichtbar, obwohl die konfigurierte Denylist keinen Treffer aufweist.
Beobachtetes Laden	`sqlite3.connect` mit `blocked: true`; `loaded: false`	Der Audit-Hook löst vor dem konfigurierten datenbanköffnenden Effekt aus.
Finales Gate	QUARANTINE; `signature: null`	Der blockierte Versuch bestimmt dieses Urteil. Es wird keine Signatur ausgestellt.

2. Den versuchten Effekt zur Routenentscheidung nutzen

Der frische Python-Worker greift auf sqlite3.connect für /tmp/vp_demo_persist/.store.dbzu. Sein CPython-Audit-Hook protokolliert die Operation und löst vor dem konfigurierten Effekt aus. Das Gate gibt QUARANTINE zurück, da ein blockiertes gefährliches Ereignis beobachtet wurde, ungeachtet des sauberen Baseline-Flags. Diese Evidenz zeigt weder eine erstellte Datenbank noch eine erfolgreiche Persistenz.

Die Benutzeroberfläche bezeichnet diesen Worker als Sandbox. Seine implementierte Grenze ist ein Subprozess mit ausgewählten Python-Audit-Hooks, ohne Betriebssystem-Sandbox, Container-Isolierung oder Netzwerktrennung. Ein produktives Zulassungssystem benötigt eine separat eingerichtete Containment-Grenze.

3. Die Entscheidung an das Artefakt und den Datensatz gebunden halten

Der herunterladbare JSON-Datensatz verknüpft den SHA-256 des Artefakts mit seinen statischen Befunden, dem Baseline-Ergebnis, versuchten Aufrufen, dem Gate-Grund, dem minimalen Modellinventar und lokalen Hash-Chain-Feldern. Für dieses QUARANTINE-Ergebnis ist das Signaturfeld null. Prüfer können die Entscheidungsevidenz einsehen, ohne Gutachterempfehlungen als Genehmigung oder abgeschlossene Registry-Aktion zu behandeln.

Ein Hash identifiziert die geprüften Artefakt-Bytes. Die lokale Kette unterstützt Konsistenzprüfungen zwischen Datensätzen, besitzt jedoch keine unabhängige Verwahrung oder externe Verankerung und ist kein unveränderliches Archiv. Die unten gezeigte signierte ALLOW-Nutzlast deckt eine engere Auswahl an Feldern ab als der vollständige Evidenzdatensatz.

Ein unauffälliges Laden lässt einen bedingten Befund unaufgeklärt

Das separate synthetische Fixture acme/experimental-rl enthält builtins.eval in der statischen Inspektion. Sein bedingter Zweig wird in dieser Umgebung nicht durchlaufen, und das beobachtete Laden verzeichnet kein blockiertes gefährliches Ereignis. Der unaufgeklärte statische Befund leitet es ohne Signatur an REVIEW weiter. Diese Route bewahrt den Bedarf an weiterer Evidenz; es wird keine abgeschlossene menschliche Untersuchung gezeigt.

Synthetisches bedingtes Fixture in Crucible mit builtins.eval, keinem blockierten Laufzeitereignis und REVIEW — Synthetisches bedingtes Fixture: Die statische Inspektion findet builtins.eval, während das beobachtete Laden kein blockiertes gefährliches Ereignis verzeichnet. REVIEW stellt keine Signatur aus und leitet das Artefakt zur Beschaffung weiterer Evidenz weiter, statt eine abgeschlossene menschliche Prüfung darzustellen. Bild zur Prüfung in Originalgröße öffnen.

ALLOW signiert das lokale Inventar, während die Provenienz unbekannt bleibt

Das generierte Gewichtungs-Dictionary acme/sentiment-mlp folgt dem sauberen Pfad: Es wird kein blockiertes gefährliches Ereignis verzeichnet, die konfigurierten Prüfungen geben ALLOW zurück und eine Ed25519-Signatur wird ausgestellt. Sein Inventar nennt Artefakt und Hash, Serialisierungsformat, abgeleitetes Framework und deklarierte Quelle. Die Trainingsdaten-Provenienz und die Fine-Tuning-Historie bleiben UNKNOWN.

Synthetisches Inventar sauberer Gewichte in Crucible mit UNKNOWN-Provenienz und lokaler Ed25519-Signatur — Synthetisches Dictionary sauberer Gewichte: ALLOW erhält eine Signatur mit lokalem Entwicklungsschlüssel über Modellname, Hash und Inventar. Trainingsprovenienz und Fine-Tuning-Historie bleiben UNKNOWN. Der sichtbare Framework-Referenztext ist ein konfiguriertes Label ohne rechtliche Validierung oder Compliance-Feststellung. Bild zur Prüfung in Originalgröße öffnen.

Die Signatur authentifiziert den kanonischen Modellnamen, den Artefakt-Hash und die minimale CycloneDX-förmige Inventar-Nutzlast gegenüber einem lokalen Entwicklungsschlüssel. Sie signiert weder jedes Urteil noch den gesamten Datensatz, ergänzt keine Upstream-Historie, begründet keine Trainingsrechte und beweist nicht, dass ein beliebiges Modell sicher ist. Der sichtbare regulatorische Referenztext stellt konfigurierte Fixture-Metadaten dar, keine validierte Compliance.

Den Vergleich der festen Menge mit seinem Nenner lesen

Ein fixierter Direct-Pipeline-Referenzlauf vom 6. Oktober 2026 verwendet deterministische Beurteilungen, PickleScan 1.0.4, temporäre Entwicklungsschlüssel und ein temporäres Ledger. Seine 33 generierten Artefakte umfassen 8 gutartige, 19 bösartige, 4 konstruierte Evader und 2 Enthaltungs-Fixtures. Der Vergleich aus Schadcode und Evadern zählt in beiden Spalten dieselben 23 Artefakte.

Fester synthetischer Direct-Pipeline-Referenzlauf mit 33 Artefakten
Messung	Beobachtetes Ergebnis	Umfang
Erkennung von Schadcode und Evadern	Verhaltensbasiert 23/23; PickleScan 19/23	Erkennung blockierter Ereignisse im Vergleich zum Baseline-Infektions-Flag bei denselben 23 Fixtures.
Konstruierte Evader	Verhaltensbasiert 4/4; PickleScan 0/4	Vier Fixtures, die entwickelt wurden, um den Unterschied zwischen diesen Prüfungen zu veranschaulichen.
Gutartige Entscheidungen	0/8 mit einem anderen Urteil als ALLOW	Acht gutartige Fixtures, keine Schätzung von Falsch-Positiven bei unbekannten Modellen.
ALLOW-Signaturen	8/8 ausgestellt und verifiziert	Die Verifikation verwendet die enthaltene Funktion und den lokalen Entwicklungsschlüssel.
Enthaltungs-Route	2/2 REVIEW	Unaufgeklärte Fixtures bleiben unsigniert; die Untersuchung ist nicht abgeschlossen.
Erwartete Urteile und lokale Kette	33/33 übereinstimmend; Hash-Verknüpfungen intakt	Verfasste Fixture-Erwartungen und eine lokale Konsistenzprüfung ohne externe Verankerung.

Der Screenshot unten zeigt einen separaten abgeschlossenen HTTP/SSE-Benchmark-Lauf in der lokalen App mit deterministischer Beurteilung. Er zeigt denselben Vergleich auf fester Menge und 33/33 erwartete Urteilsübereinstimmungen. Er ist nicht die Quelle der obigen fixierten Direct-Pipeline-Referenzmessung; seine angezeigten Laufzeiten gehören zu diesem erfassten Lauf.

Abgeschlossener synthetischer Crucible-Benchmark mit 33 von 33 erwarteten Urteilen, verhaltensbasierter Erkennung von 23 von 23 und PickleScan-Flags von 19 von 23 — Abgeschlossener lokaler HTTP/SSE-Benchmark: Alle 33 synthetischen Fixtures stimmen mit ihren erwarteten Urteilen überein. Die verhaltensbasierte Erkennung blockierter Ereignisse liegt bei 23/23 und PickleScan-Flags bei 19/23 auf derselben Menge aus Schadcode und Evadern. Die Beurteilung ist deterministisch. Nur ALLOW signiert die Inventar-Nutzlast; REVIEW und QUARANTINE sind unsigniert. Die lokale Hash-Kette besitzt keine externe Verankerung, und angezeigte Laufzeiten entsprechen keiner Produktionslatenz. Bild zur Prüfung in Originalgröße öffnen.

Diese Beobachtungen an konstruierten Fixtures schätzen weder die Erkennung bei unbekannten Modellen, noch die Produktionslatenz oder die Reduzierung von Sicherheitsverletzungen ab. ALLOW beschreibt das Ergebnis der konfigurierten Prüfungen beim beobachteten Ladevorgang; es stellt keine lückenlose Modellsicherheit fest.

Was jede Ebene feststellen kann

Ebene	Evidenz in dieser Demo	Beizubehaltende Grenze
Statische Inspektion und PickleScan	Globals, approximierte Callables und Baseline-Flag	Ein sauberes Flag allein klärt das Ladeverhalten nicht auf
Verhaltensbeobachtung	Ausgewählte versuchte Effekte bei einem beobachteten Ladevorgang	Ein unauffälliges Laden kann bedingtes Verhalten unaufgeklärt lassen
Signiertes Inventar	Lokaler Modellname, Hash und Inventar-Nutzlast für ALLOW	Die Signatur beglaubigt keine unbekannte Upstream-Historie
Lokales hash-verkettetes Ledger	Hash-Links zur Unterstützung lokaler Konsistenzprüfungen	Keine unabhängige Verwahrung oder externe Verankerung

Was diese Demo NICHT leistet

Crucible ist eine lokale Demonstration auf synthetischen Artefakten. Es verfügt über keinen Konnektor für öffentliche Registries, keine Durchsetzung von Unternehmenszulassungen, keine Betriebssystem-Sandbox, keine produktive Schlüssel-Infrastruktur und keine vollständige Rekonstruktion von Abhängigkeiten. Es bewertet weder Modellqualität, Inferenzsicherheit noch Vergiftung von Trainingsdaten (Poisoning), und seine Framework-Referenz-Labels begründen keine Compliance.

Python warnt davor, dass Audit-Hooks ungeeignet für die Implementierung einer Sandbox sind. Python-Audit-Hook-Dokumentation. Produktionsarbeit muss Containment, Vertrauensgrenzen und kontrollierte Verwahrung über diese lokale Demonstration hinaus etablieren.

Fragen, die Sicherheits- und Plattformteams stellen

Was kann ein sauberer Pickle-Scan feststellen?

Ein sauberes PickleScan-Ergebnis bedeutet, dass diese Baseline das geprüfte Artefakt nicht markiert hat. Im synthetischen SQLite-Beispiel von Crucible erfasst und blockiert der konfigurierte Audit-Hook eine versuchte Datenbankoperation während des Ladens, während die Baseline sauber bleibt. Ein Scanner-Ergebnis allein stellt kein nebenwirkungsfreies Laden fest.

Was geschieht, wenn verdächtige statische Evidenz beim Laden nicht ausgeführt wird?

Crucible leitet einen konfigurierten gefährlichen statischen Global an REVIEW weiter, wenn der beobachtete Ladevorgang kein blockiertes gefährliches Ereignis auslöst. Das synthetische bedingte Fixture enthält builtins.eval und nimmt diese Route ohne Signatur. REVIEW fordert weitere Evidenz an; es bedeutet nicht, dass eine menschliche Untersuchung abgeschlossen ist.

Was deckt die Signatur ab?

Nur ALLOW erhält eine Ed25519-Signatur über den kanonischen Modellnamen, den Artefakt-Hash und die Inventar-Nutzlast unter Verwendung eines lokalen Entwicklungsschlüssels. Sie authentifiziert diese Nutzlast relativ zu diesem Schlüssel. Sie begründet weder Upstream-Verwahrung, Quell-Authentizität noch vollständige Provenienz.

Welche Upstream-Provenienz bleibt unbekannt?

Das minimale CycloneDX-förmige Modellinventar erfasst Trainingsdaten-Provenienz und Fine-Tuning-Historie als UNKNOWN. Es enthält den Artefakt-Hash, das Serialisierungsformat, das abgeleitete Framework und die deklarierte Quelle. Ein ALLOW-Urteil und eine gültige lokale Signatur füllen die fehlende Historie nicht aus.

Wie ist der Worker isoliert?

Der Worker ist ein frischer Python-Subprozess mit einem temporären Arbeitsverzeichnis und einem CPython-Audit-Hook, der ausgewählte Ereignisse erfasst und konfigurierte Effekte blockiert. Er verfügt über keinen Container oder eine Betriebssystem-Sandbox und ist keine netzwerkisolierte Umgebung. Diese Demonstration begründet kein produktives Containment oder lückenlose Sicherheit.

Lässt sich dies in unsere Registry- und Zulassungspipeline integrieren?

Die Demonstration liest generierte Artefakte aus einer lokalen synthetischen Registry. Ihre hf://-Quellstrings sind Fixture-Labels, und sie besitzt weder einen Konnektor für öffentliche Registries noch eine Durchsetzung von Unternehmenszulassungen. Eine Produktionsintegration würde Vertrauensgrenzen für die Registry, Containment, Schlüsselverwaltung und unabhängig kontrollierten Audit-Speicher erfordern.