Crucible · Model Vetting Firewall

Una scansione pulita lascia aperta la questione del caricamento

Un modello sintetico supera la baseline di PickleScan, quindi tenta di aprire un database durante il caricamento. Crucible registra e blocca tale effetto configurato, restituendo QUARANTINE con le prove allegate.

23/23 vs 19/23

Rilevamento di eventi bloccati vs flag di PickleScan

Stessi 23 fixture sintetici dannosi ed elusivi

4/4 vs 0/4

Quattro elusori appositamente costruiti

Rilevamento comportamentale vs PickleScan 1.0.4

2/2

Fixture con astensione instradati verso REVIEW

Necessarie ulteriori prove; nessuna firma rilasciata

Le schede riportano un'esecuzione di riferimento su pipeline diretta fissa con 33 artefatti sintetici del 6 ottobre 2026 con consulenza deterministica. Non stimano il rilevamento su modelli sconosciuti. Il video registra separatamente controlli configurati eseguiti ex novo nell'app locale: la console principale utilizza consulenza Codex memorizzata nella cache, mentre il benchmark utilizza consulenza deterministica. Nessuna inferenza su modelli nuovi viene acquisita.

La decisione richiede prove relative al caricamento

Quando un team di sicurezza approva un modello serializzato, la domanda rilevante va oltre la sua identità dichiarata: quale operazione tenta di compiere il caricamento e quali prove restano non risolte?

Python avverte che dati pickle manipolati ad arte possono eseguire codice durante l'unpickling. Anche la documentazione sulla scansione pickle di Hugging Face descrive le limitazioni dell'ispezione di import e opcode. Documentazione di Python su pickle; Documentazione di Hugging Face sulla scansione di pickle.

Il nostro fixture SQLite sintetico rende ispezionabile questa distinzione: una baseline priva di flag di infezione si affianca a un tentativo bloccato di apertura di un database. Il record di ammissione conserva entrambi i risultati invece di trattare il campo pulito dello scanner come un'autorizzazione.

Come viene presa la decisione configurata

Ispezionare il contenuto pickle supportato. Il disassemblaggio statico degli opcode registra le variabili globali e stima i callable invocati. La baseline installata di PickleScan fornisce un campo di confronto separato; il suo flag non determina direttamente il verdetto.
Osservare un tentativo di caricamento. Un sottoprocesso Python creato ex novo utilizza un audit hook di CPython per registrare eventi selezionati e sollevare un'eccezione prima degli effetti bloccati configurati, inclusi connessione SQLite e connessione socket. Si tratta di una strumentazione Python con separazione dei processi, senza confinamento a livello di container o di sistema operativo.
Applicare il gate e conservare l'incertezza. Un evento comportamentale bloccato restituisce QUARANTINE. Un arresto anomalo del runner o un timeout, un errore di disassemblaggio pickle o un elemento globale statico pericoloso non eseguito restituiscono REVIEW. Altrimenti, il gate di base restituisce ALLOW; il dubbio del challenger può modificare ALLOW in REVIEW, mentre QUARANTINE rimane in vigore.
Allegare un record delimitato. Ogni risultato riceve un inventario del modello minimale conforme a CycloneDX e campi locali di catena di hash. Solo ALLOW riceve una firma con chiave di sviluppo su nome del modello, hash dell'artefatto e inventario. La cronologia a monte sconosciuta rimane UNKNOWN.

La consulenza impiega ruoli di analista e challenger in un'unica richiesta combinata. La console principale registrata utilizza consulenza memorizzata nella cache; il benchmark utilizza consulenza deterministica. Questi controlli configurati non garantiscono che ogni file non valido, formato non supportato o errore di analisi venga instradato verso REVIEW.

Seguire un artefatto dalla scansione pulita alla decisione di ammissione

Tutti gli artefatti, i nomi dei modelli e hf:// le etichette di origine sottostanti sono fixture locali sintetici, non modelli dei clienti o record verificati di un registro. I primi tre screenshot catturano controlli configurati eseguiti ex novo con consulenza Codex memorizzata nella cache; l'acquisizione separata del benchmark impiega consulenza deterministica. Nessuna inferenza su modelli nuovi viene mostrata.

Esempio pratico: una baseline pulita, un tentativo di accesso al database bloccato

Il pickle generato trusted-looking/finetune-safe tenta di aprire un database SQLite durante la deserializzazione. Il suo nome è un'etichetta creata per il fixture, non una prova di affidabilità. La domanda utile è se il riscontro dello scanner e il comportamento di caricamento osservato supportino la stessa decisione di ammissione.

Risultato configurato

PickleScan: CLEAN. Operazione osservata: sqlite3.connect, tentata e bloccata. Verdetto finale: QUARANTINE. Firma: nessuna.

Elusore SQLite sintetico di Crucible che mostra PickleScan CLEAN, sqlite3.connect bloccato e QUARANTINE — Elusore SQLite sintetico: PickleScan non contrassegna l'artefatto; l'audit hook configurato registra e blocca la sua operazione di database tentata. QUARANTINE non rilascia alcuna firma. NO CODE SURFACE indica che non vi è alcuna corrispondenza con elementi globali pericolosi configurati; _sqlite3.connect rimane presente. La dicitura sandbox dell'interfaccia utente si riferisce alla strumentazione di audit tramite sottoprocesso, senza confinamento a livello di sistema operativo o container. Apri l'immagine per l'ispezione a dimensione intera.

1. Leggere i riscontri dello scanner e quelli statici separatamente

PickleScan 1.0.4 registra _sqlite3.connect come sospetto senza impostare il proprio flag di infezione. Anche il disassemblaggio statico di Crucible conserva tale callable importato, ma esso è assente dall'insieme degli elementi globali pericolosi configurati. Il badge visibile NO CODE SURFACE significa pertanto assenza di riscontri tra gli elementi globali pericolosi configurati; non significa che il file non contenga callable eseguibili.

Prove per l'artefatto SQLite sintetico
Controllo	Riscontro registrato	Cosa stabilisce
Baseline di PickleScan	`flagged: false`; `_sqlite3.connect [suspicious]`	Questa baseline non contrassegna l'artefatto. Non stabilisce che il caricamento sia innocuo.
Disassemblaggio statico	`_sqlite3.connect` negli import e nei callable stimati; nessun elemento globale pericoloso configurato	Il callable è visibile anche se la denylist configurata non presenta riscontri.
Caricamento osservato	`sqlite3.connect` con `blocked: true`; `loaded: false`	L'audit hook solleva un'eccezione prima dell'effetto configurato di apertura del database.
Gate finale	QUARANTINE; `signature: null`	Il tentativo bloccato determina questo verdetto. Nessuna firma viene rilasciata.

2. Utilizzare l'effetto tentato per decidere il percorso

Il worker Python avviato ex novo raggiunge sqlite3.connect per /tmp/vp_demo_persist/.store.db. Il suo audit hook di CPython registra l'operazione e solleva un'eccezione prima dell'effetto configurato. Il gate restituisce QUARANTINE perché è stato osservato un evento pericoloso bloccato, indipendentemente dal flag di baseline pulita. Questa prova non mostra un database creato o una persistenza riuscita.

L'interfaccia utente definisce sandbox questo worker. Il confine implementato è un sottoprocesso con audit hook selezionati di Python, senza sandbox del sistema operativo, confinamento tramite container o isolamento di rete. Un sistema di ammissione per la produzione richiede un confine di contenimento stabilito separatamente.

3. Mantenere la decisione vincolata all'artefatto e al record

Il record JSON scaricabile associa lo SHA-256 dell'artefatto ai suoi riscontri statici, al risultato della baseline, alle chiamate tentate, al motivo del gate, all'inventario minimale del modello e ai campi locali della catena di hash. Per questo risultato di QUARANTINE, il campo della firma è null. I revisori possono ispezionare le prove decisionali senza trattare le raccomandazioni di consulenza come un'approvazione o un'azione completata nel registro.

Un hash identifica i byte dell'artefatto ispezionato. La catena locale supporta controlli di coerenza tra i record, ma non dispone di custodia indipendente o di ancoraggio esterno e non costituisce un archivio immutabile. Il payload ALLOW firmato mostrato di seguito copre un insieme di campi più limitato rispetto al record completo delle prove.

Un caricamento senza anomalie lascia irrisolto un riscontro condizionale

Il fixture sintetico separato acme/experimental-rl contiene builtins.eval nell'ispezione statica. Il suo ramo condizionale non viene eseguito in questo ambiente e il caricamento osservato non registra alcun evento pericoloso bloccato. Il riscontro statico non risolto lo invia a REVIEW senza alcuna firma. Questo percorso conserva la necessità di ulteriori prove; non viene mostrata alcuna indagine umana completata.

Fixture condizionale sintetico di Crucible che mostra builtins.eval, nessun evento di runtime bloccato e REVIEW — Fixture condizionale sintetico: l'ispezione statica rileva builtins.eval, mentre il caricamento osservato non registra alcun evento pericoloso bloccato. REVIEW non rilascia firme e instrada l'artefatto per ulteriori prove anziché per una revisione umana completata. Apri l'immagine per l'ispezione a dimensione intera.

ALLOW firma l'inventario locale mentre la provenienza rimane sconosciuta

Il dizionario di pesi generato acme/sentiment-mlp segue il percorso pulito: non viene registrato alcun evento pericoloso bloccato, i controlli configurati restituiscono ALLOW e viene rilasciata una firma Ed25519. Il suo inventario indica il nome e l'hash dell'artefatto, il formato di serializzazione, il framework dedotto e la sorgente dichiarata. La provenienza dei dati di addestramento e la cronologia di fine-tuning rimangono UNKNOWN.

Inventario dei pesi puliti sintetici di Crucible che mostra provenienza UNKNOWN e firma Ed25519 locale — Dizionario di pesi puliti sintetico: ALLOW riceve una firma con chiave di sviluppo locale su nome del modello, hash e inventario. La provenienza dell'addestramento e la cronologia di fine-tuning rimangono UNKNOWN. Il testo visibile di riferimento al framework è un'etichetta configurata, priva di convalida legale o di accertamento di conformità. Apri l'immagine per l'ispezione a dimensione intera.

La firma autentica il nome canonico del modello, l'hash dell'artefatto e il payload minimale dell'inventario conforme a CycloneDX rispetto a una chiave di sviluppo locale. Non firma ciascun verdetto o l'intero record, non compila la cronologia a monte, non stabilisce i diritti di addestramento né dimostra che un modello arbitrario sia sicuro. Il testo visibile di riferimento normativo costituisce un metadato configurato del fixture, non una conformità convalidata.

Leggere il confronto su insieme fisso con il relativo denominatore

Un'esecuzione di riferimento su pipeline diretta congelata del 6 ottobre 2026 utilizza consulenza deterministica, PickleScan 1.0.4, chiavi di sviluppo temporanee e un registro temporaneo. I suoi 33 artefatti generati comprendono 8 benigni, 19 dannosi, 4 elusori appositamente costruiti e 2 fixture di astensione. Il confronto tra dannosi ed elusori conteggia gli stessi 23 artefatti in entrambe le colonne.

Esecuzione di riferimento su pipeline diretta fissa con 33 artefatti sintetici
Misurazione	Risultato osservato	Ambito
Rilevamento di dannosi ed elusori	Comportamentale 23/23; PickleScan 19/23	Rilevamento di eventi bloccati confrontato con il flag di infezione della baseline sugli stessi 23 fixture.
Elusori appositamente costruiti	Comportamentale 4/4; PickleScan 0/4	Quattro fixture progettati per illustrare la differenza tra questi controlli.
Decisioni su benigni	0/8 ha ricevuto un verdetto diverso da ALLOW	Otto fixture benigni, non una stima dei falsi positivi su modelli sconosciuti.
Firme ALLOW	8/8 rilasciate e verificate	La verifica impiega la funzione inclusa e la chiave di sviluppo locale.
Percorso di astensione	2/2 REVIEW	I fixture non risolti rimangono non firmati; l'indagine non è completata.
Verdetti attesi e catena locale	33/33 corrispondenti; collegamenti hash intatti	Aspettative create per i fixture e controllo di coerenza locale, senza un ancoraggio esterno.

Lo screenshot seguente è un'esecuzione separata e completata del benchmark HTTP/SSE nell'app locale, con consulenza deterministica. Mostra lo stesso confronto sull'insieme fisso e 33/33 corrispondenze di verdetti attesi. Non è la fonte della misurazione di riferimento congelata su pipeline diretta riportata sopra; le tempistiche visualizzate appartengono a quell'esecuzione acquisita.

Benchmark sintetico completato di Crucible che mostra 33 su 33 verdetti attesi, rilevamento comportamentale 23 su 23 e flag di PickleScan 19 su 23 — Benchmark HTTP/SSE locale completato: tutti i 33 fixture sintetici corrispondono ai loro verdetti attesi. Il rilevamento comportamentale di eventi bloccati è 23/23 e i flag di PickleScan sono 19/23 sullo stesso insieme di dannosi ed elusori. La consulenza è deterministica. Solo ALLOW firma il payload dell'inventario; REVIEW e QUARANTINE non sono firmati. La catena locale di hash non ha un ancoraggio esterno e i tempi visualizzati non rappresentano la latenza di produzione. Apri l'immagine per l'ispezione a dimensione intera.

Queste osservazioni su fixture costruiti non stimano il rilevamento su modelli mai visti, la latenza di produzione o la riduzione delle violazioni. ALLOW descrive l'esito dei controlli configurati sul caricamento osservato; non stabilisce una sicurezza esaustiva del modello.

Cosa può stabilire ciascun livello

Livello	Prove in questa demo	Confine da preservare
Ispezione statica e PickleScan	Elementi globali, callable stimati e flag di baseline	Un flag pulito da solo non risolve il comportamento di caricamento
Osservazione comportamentale	Effetti tentati selezionati su un caricamento osservato	Un caricamento senza anomalie può lasciare irrisolto un comportamento condizionale
Inventario firmato	Nome del modello locale, hash e payload dell'inventario per ALLOW	La firma non attesta la cronologia a monte sconosciuta
Registro locale a catena di hash	Collegamenti hash a supporto dei controlli di coerenza locali	Nessuna custodia indipendente o ancoraggio esterno

Cosa NON fa questa demo

Crucible è una dimostrazione locale su artefatti sintetici. Non dispone di connettori verso registri pubblici, imposizione dell'ammissione aziendale, sandbox del sistema operativo, infrastruttura di chiavi di produzione o ricostruzione completa delle dipendenze. Non valuta la qualità del modello, la sicurezza dell'inferenza o l'avvelenamento dei dati di addestramento e le sue etichette di riferimento al framework non stabiliscono conformità.

Python avverte che gli audit hook non sono adatti per implementare una sandbox. Documentazione di Python sugli audit hook. Le attività in produzione devono stabilire contenimento, confini di attendibilità e custodia controllata oltre questa dimostrazione locale.

Domande frequenti dei team di sicurezza e di piattaforma

Cosa può stabilire una scansione pickle pulita?

Un risultato pulito di PickleScan indica che questa baseline non ha contrassegnato l'artefatto ispezionato. Nell'esempio SQLite sintetico di Crucible, l'audit hook configurato registra e blocca un'operazione di database tentata durante il caricamento mentre la baseline rimane pulita. Il solo risultato di uno scanner non stabilisce un caricamento esente da effetti collaterali.

Cosa succede se prove statiche sospette non vengono eseguite durante il caricamento?

Crucible instrada un elemento globale statico pericoloso configurato verso REVIEW quando il caricamento osservato non esegue un evento pericoloso bloccato. Il fixture condizionale sintetico contiene builtins.eval e segue questo percorso senza firma. REVIEW richiede ulteriori prove; non implica che un'indagine umana sia completata.

Cosa copre la firma?

Solo ALLOW riceve una firma Ed25519 sul nome canonico del modello, sull'hash dell'artefatto e sul payload dell'inventario, impiegando una chiave di sviluppo locale. Autentica tale payload rispetto a questa chiave. Non stabilisce custodia a monte, autenticità dell'origine o provenienza completa.

Quale provenienza a monte rimane sconosciuta?

L'inventario del modello minimale conforme a CycloneDX registra la provenienza dei dati di addestramento e la cronologia di fine-tuning come UNKNOWN. Include l'hash dell'artefatto, il formato di serializzazione, il framework dedotto e la sorgente dichiarata. Un verdetto ALLOW e una firma locale valida non colmano la cronologia mancante.

Come viene isolato il worker?

Il worker è un sottoprocesso Python creato ex novo con una directory di lavoro temporanea e un audit hook di CPython che registra eventi selezionati e blocca effetti configurati. Non dispone di container o sandbox del sistema operativo e non è un ambiente isolato a livello di rete. Questa dimostrazione non stabilisce un contenimento per la produzione o una sicurezza esaustiva.

Questa soluzione si integra con il nostro registro e con la nostra pipeline di ammissione?

La dimostrazione legge gli artefatti generati da un registro sintetico locale. Le sue stringhe di origine hf:// sono etichette di fixture e non dispone di connettori per registri pubblici o di applicazione dell'ammissione aziendale. L'integrazione in produzione richiederebbe confini di attendibilità del registro, contenimento, gestione delle chiavi e archiviazione di audit controllata in modo indipendente.