Crucible · Pare-feu d'évaluation des modèles

Un scan sain laisse entière la question du chargement

Un modèle synthétique passe la référence PickleScan, puis tente d'ouvrir une base de données lors du chargement. Crucible enregistre et bloque cet effet configuré, renvoyant QUARANTINE avec les preuves jointes.

23/23 vs 19/23

Détection d'événements bloqués vs signalements PickleScan

Mêmes 23 fixtures synthétiques malveillantes et d'évasion

4/4 vs 0/4

Quatre variantes d'évasion construites

Détection comportementale vs PickleScan 1.0.4

2/2

Fixtures d'abstention orientées vers REVIEW

Preuves supplémentaires requises ; aucune signature émise

Les fiches rapportent une exécution de référence de pipeline direct synthétique figée de 33 artefacts le 6 octobre 2026 avec avis déterministe. Elles n'estiment pas la détection sur des modèles inconnus. La vidéo capture séparément de nouvelles vérifications configurées dans l'application locale : la console principale utilise l'avis Codex mis en cache, et le benchmark utilise l'avis déterministe. Aucune inférence de modèle nouvelle n'est capturée.

La décision nécessite des preuves relatives au chargement

Lorsqu'une équipe de sécurité approuve un modèle sérialisé, la question pertinente s'étend au-delà de son identité déclarée : quelle opération le chargement tente-t-il, et quelles preuves demeurent non résolues ?

Python avertit que des données pickle forgées peuvent exécuter du code lors du dépicklage. La documentation de scan de pickle de Hugging Face décrit également les limites de l'inspection des imports et des opcodes. Documentation du pickle Python; Documentation de scan de pickle de Hugging Face.

Notre fixture SQLite synthétique rend cette distinction inspectable : une référence sans indicateur d'infection côtoie une tentative bloquée d'ouverture de base de données. Le registre d'admission préserve les deux constats au lieu de traiter le champ de scanner sain comme une autorisation.

Comment la décision configurée est prise

  1. Inspecter le contenu pickle pris en charge. Le désassemblage statique d'opcodes enregistre les globales et approxime les appelables invoqués. La référence PickleScan installée fournit un champ de comparaison distinct ; son indicateur ne décide pas directement du verdict.
  2. Observer une tentative de chargement. Un nouveau sous-processus Python utilise un audit hook CPython pour enregistrer des événements sélectionnés et lever une exception avant les effets bloqués configurés, notamment la connexion SQLite et la connexion par socket. Il s'agit d'une instrumentation Python avec séparation de processus, sans confinement par conteneur ni par système d'exploitation.
  3. Appliquer la porte et conserver l'incertitude. Un événement comportemental bloqué renvoie QUARANTINE. Un plantage ou un délai d'attente dépassé du lanceur, une erreur de désassemblage de pickle, ou une globale statique dangereuse non exercée renvoie REVIEW. Sinon, la porte de base renvoie ALLOW ; le doute du challenger peut faire passer ALLOW à REVIEW, tandis que QUARANTINE reste en vigueur.
  4. Joindre un enregistrement délimité. Chaque résultat reçoit un inventaire de modèle minimal au format CycloneDX et des champs locaux de chaîne de hachage. Seul ALLOW reçoit une signature par clé de développement sur le nom du modèle, le hash de l'artefact et l'inventaire. L'historique amont inconnu demeure UNKNOWN.

Le service consultatif utilise les rôles d'analyste et de challenger dans une seule requête combinée. La console principale enregistrée utilise des avis mis en cache ; le benchmark utilise des avis déterministes. Ces vérifications configurées ne garantissent pas que chaque fichier malformé, format non pris en charge ou erreur d'analyse soit orienté vers REVIEW.

Suivre un artefact depuis le scan sain jusqu'à la décision d'admission

Tous les artefacts, noms de modèles et hf:// libellés de source ci-dessous sont des fixtures locales synthétiques, non des modèles clients ou des enregistrements de registre vérifiés. Les trois premières captures d'écran saisissent de nouvelles vérifications configurées avec avis Codex mis en cache ; la capture de benchmark distincte utilise un avis déterministe. Aucune inférence de modèle nouvelle n'est présentée.

Exemple concret : une référence saine, une tentative de base de données bloquée

Le fichier généré trusted-looking/finetune-safe pickle tente d'ouvrir une base de données SQLite lors de la désérialisation. Son nom est un libellé de fixture créé pour le test, non une preuve de confiance. La question utile est de savoir si le constat du scanner et le comportement de chargement observé corroborent la même décision d'admission.

Résultat configuré

PickleScan : CLEAN. Opération observée : sqlite3.connect, tentée et bloquée. Verdict final : QUARANTINE. Signature : aucune.

Artefact d'évasion SQLite synthétique de Crucible montrant PickleScan CLEAN, sqlite3.connect bloqué et QUARANTINE
Artefact d'évasion SQLite synthétique : PickleScan ne signale pas l'artefact ; l'audit hook configuré enregistre et bloque sa tentative d'opération de base de données. QUARANTINE n'émet aucune signature. NO CODE SURFACE signifie qu'aucune globale dangereuse configurée n'a été détectée ; _sqlite3.connect reste présent. Le terme de bac à sable de l'interface utilisateur fait référence à l'instrumentation d'audit en sous-processus, sans confinement par l'OS ou par conteneur. Ouvrez l'image pour une inspection en taille réelle.

1. Lire séparément les constats du scanner et les constats statiques

PickleScan 1.0.4 enregistre _sqlite3.connect comme suspect sans activer son indicateur d'infection. Le désassemblage statique de Crucible conserve également cet appelable importé, mais il est absent de l'ensemble de globales dangereuses configuré. Le badge visible NO CODE SURFACE signifie donc qu'aucune globale dangereuse configurée n'a été atteinte ; il ne signifie pas que le fichier ne contient aucun appelable exécutable.

Preuves pour l'artefact SQLite synthétique
VérificationConstat enregistréCe que cela établit
Référence PickleScanflagged: false; _sqlite3.connect [suspicious]Cette référence ne signale pas l'artefact. Elle n'établit pas un chargement inoffensif.
Désassemblage statique_sqlite3.connect dans les imports et appelables approximés ; aucune globale dangereuse configuréeL'appelable est visible même si la liste de blocage configurée ne compte aucune correspondance.
Chargement observésqlite3.connect avec blocked: true; loaded: falseL'audit hook lève une exception avant l'effet d'ouverture de base de données configuré.
Porte finaleQUARANTINE; signature: nullLa tentative bloquée détermine ce verdict. Aucune signature n'est émise.

2. Utiliser l'effet tenté pour décider de l'orientation

Le nouveau worker Python atteint sqlite3.connect pour /tmp/vp_demo_persist/.store.db. Son audit hook CPython enregistre l'opération et lève une exception avant l'effet configuré. La porte renvoie QUARANTINE car un événement dangereux bloqué a été observé, indépendamment de l'indicateur de référence sain. Cette preuve ne montre pas de base de données créée ni de persistance réussie.

L'interface utilisateur qualifie ce worker de bac à sable. Sa frontière mise en œuvre est un sous-processus doté d'audit hooks Python sélectionnés, sans bac à sable au niveau du système d'exploitation, confinement par conteneur ni isolation réseau. Un système d'admission en production nécessite une frontière de confinement établie séparément.

3. Maintenir la décision liée à l'artefact et au registre

L'enregistrement JSON téléchargeable associe le SHA-256 de l'artefact à ses constats statiques, au résultat de référence, aux appels tentés, au motif de la porte, à l'inventaire minimal du modèle et aux champs locaux de chaîne de hachage. Pour ce résultat QUARANTINE, le champ de signature est null. Les réviseurs peuvent inspecter les preuves de décision sans traiter les recommandations consultatives comme une approbation ou une action de registre finalisée.

Un hash identifie les octets de l'artefact inspecté. La chaîne locale prend en charge les contrôles de cohérence entre enregistrements, mais elle ne dispose d'aucune garde indépendante ni d'ancrage externe et ne constitue pas une archive immuable. La charge utile ALLOW signée présentée ci-dessous couvre un ensemble de champs plus restreint que le registre de preuves complet.

Un chargement silencieux laisse un constat conditionnel non résolu

L'artefact synthétique distinct acme/experimental-rl fixture contient builtins.eval en inspection statique. Sa branche conditionnelle n'est pas exécutée dans cet environnement, et le chargement observé n'enregistre aucun événement dangereux bloqué. Le constat statique non résolu l'oriente vers REVIEW sans signature. Ce routage préserve la nécessité de preuves supplémentaires ; aucune investigation humaine achevée n'est présentée.

Fixture conditionnelle synthétique de Crucible montrant builtins.eval, aucun événement d'exécution bloqué et REVIEW
Fixture conditionnelle synthétique : l'inspection statique détecte builtins.eval, tandis que le chargement observé n'enregistre aucun événement dangereux bloqué. REVIEW n'émet aucune signature et oriente l'artefact vers une demande de preuves supplémentaires plutôt qu'une révision humaine achevée. Ouvrez l'image pour une inspection en taille réelle.

ALLOW signe l'inventaire local tandis que la provenance reste inconnue

Le fichier généré acme/sentiment-mlp dictionnaire de poids suit le chemin sain : aucun événement dangereux bloqué n'est enregistré, les vérifications configurées renvoient ALLOW et une signature Ed25519 est émise. Son inventaire mentionne l'artefact et le hash, le format de sérialisation, le framework déduit et la source déclarée. La provenance des données d'entraînement et l'historique d'ajustement fin demeurent UNKNOWN.

Inventaire de poids sains synthétiques de Crucible montrant une provenance UNKNOWN et une signature Ed25519 locale
Dictionnaire de poids sains synthétique : ALLOW reçoit une signature par clé de développement locale sur le nom du modèle, le hash et l'inventaire. La provenance de l'entraînement et l'historique d'ajustement fin demeurent UNKNOWN. Le texte de référence de framework visible est un libellé configuré, sans validation juridique ni constat de conformité. Ouvrez l'image pour une inspection en taille réelle.

La signature authentifie le nom canonique du modèle, le hash de l'artefact et la charge utile minimale d'inventaire au format CycloneDX par rapport à une clé de développement locale. Elle ne signe pas chaque verdict ni l'intégralité du registre, ne complète pas l'historique amont, n'établit pas les droits d'entraînement et ne prouve pas qu'un modèle arbitraire est sûr. Le texte de référence réglementaire visible est une métadonnée de fixture configurée, non une conformité validée.

Lire la comparaison sur ensemble figé avec son dénominateur

Une exécution de référence de pipeline direct figée le 6 octobre 2026 utilise un avis déterministe, PickleScan 1.0.4, des clés de développement temporaires et un registre temporaire. Ses 33 artefacts générés comprennent 8 fixtures bénignes, 19 malveillantes, 4 variantes d'évasion construites et 2 d'abstention. La comparaison malveillantes et d'évasion comptabilise les mêmes 23 artefacts dans les deux colonnes.

Exécution de référence de pipeline direct synthétique figée de 33 artefacts
MesureRésultat observéPérimètre
Détection des malveillants et d'évasionComportementale 23/23 ; PickleScan 19/23Détection d'événements bloqués comparée à l'indicateur d'infection de référence sur les mêmes 23 fixtures.
Variantes d'évasion construitesComportementale 4/4 ; PickleScan 0/4Quatre fixtures conçues pour illustrer la différence entre ces vérifications.
Décisions bénignes0/8 ayant reçu un verdict autre que ALLOWHuit fixtures bénignes, non une estimation des faux positifs sur des modèles inconnus.
Signatures ALLOW8/8 émises et vérifiéesLa vérification utilise la fonction incluse et la clé de développement locale.
Routage d'abstention2/2 REVIEWLes fixtures non résolues restent non signées ; l'investigation n'est pas finalisée.
Verdicts attendus et chaîne locale33/33 correspondances ; liens de hachage intactsAttentes de fixtures rédigées et contrôle de cohérence locale, sans ancrage externe.

La capture d'écran ci-dessous est une exécution de benchmark HTTP/SSE achevée distincte dans l'application locale, avec avis déterministe. Elle montre la même comparaison sur ensemble figé et 33/33 correspondances de verdict attendues. Elle n'est pas la source de la mesure de référence de pipeline direct figée ci-dessus ; les durées affichées appartiennent à cette exécution capturée.

Benchmark synthétique Crucible achevé montrant 33 verdicts attendus sur 33, une détection comportementale de 23 sur 23 et 19 signalements PickleScan sur 23
Benchmark local HTTP/SSE achevé : l'ensemble des 33 fixtures synthétiques correspondent à leurs verdicts attendus. La détection comportementale d'événements bloqués est de 23/23 et les signalements PickleScan sont de 19/23 sur le même ensemble malveillantes et d'évasion. L'avis est déterministe. Seul ALLOW signe la charge utile d'inventaire ; REVIEW et QUARANTINE ne sont pas signés. La chaîne de hachage locale n'a aucun ancrage externe, et les durées affichées ne constituent pas une latence de production. Ouvrez l'image pour une inspection en taille réelle.

Ces observations sur fixtures construites n'estiment pas la détection sur des modèles inconnus, la latence de production ou la réduction des brèches. ALLOW décrit le résultat des vérifications configurées sur le chargement observé ; il n'établit pas une sécurité exhaustive du modèle.

Ce que chaque couche peut établir

CouchePreuves dans cette démonstrationFrontière à retenir
Inspection statique et PickleScanGlobales, appelables approximés et indicateur de référenceUn indicateur sain seul ne résout pas le comportement au chargement
Observation comportementaleEffets tentés sélectionnés sur un chargement observéUn chargement silencieux peut laisser un comportement conditionnel non résolu
Inventaire signéNom de modèle local, hash et charge utile d'inventaire pour ALLOWLa signature n'atteste pas l'historique amont inconnu
Registre local à chaîne de hachageLiens de hachage prenant en charge les contrôles de cohérence localeAucune garde indépendante ni ancrage externe

Ce que cette démonstration ne fait PAS

Crucible est une démonstration locale sur des artefacts synthétiques. Elle ne comporte aucun connecteur de registre public, application d'admission en entreprise, bac à sable au niveau de l'OS, infrastructure de clés de production ou reconstruction complète des dépendances. Elle n'évalue pas la qualité du modèle, la sécurité de l'inférence ou l'empoisonnement des données d'entraînement, et ses libellés de référence de framework n'établissent pas la conformité.

Python avertit que les audit hooks ne conviennent pas pour implémenter un bac à sable. Documentation des audit hooks de Python. Les déploiements en production doivent établir le confinement, les frontières de confiance et une garde contrôlée au-delà de cette démonstration locale.

Questions que se posent les équipes de sécurité et de plateforme

Que peut établir un scan de pickle sain ?

Un résultat PickleScan sain signifie que cette référence n'a pas signalé l'artefact inspecté. Dans l'exemple SQLite synthétique de Crucible, l'audit hook configuré enregistre et bloque une tentative d'opération de base de données lors du chargement tandis que la référence reste saine. Un résultat de scanner à lui seul n'établit pas un chargement exempt d'effets secondaires.

Que se passe-t-il si des preuves statiques suspectes ne sont pas exercées lors du chargement ?

Crucible oriente une globale statique dangereuse configurée vers REVIEW lorsque le chargement observé n'exerce pas d'événement dangereux bloqué. La fixture conditionnelle synthétique contient builtins.eval et emprunte cette voie sans signature. REVIEW requiert des preuves supplémentaires ; cela ne signifie pas qu'une investigation humaine est achevée.

Que couvre la signature ?

Seul ALLOW reçoit une signature Ed25519 sur le nom canonique du modèle, le hash de l'artefact et la charge utile d'inventaire, à l'aide d'une clé de développement locale. Elle authentifie cette charge utile par rapport à cette clé. Elle n'établit pas la garde en amont, l'authenticité de la source ou une provenance complète.

Quelle provenance en amont demeure inconnue ?

L'inventaire de modèle minimal au format CycloneDX enregistre la provenance des données d'entraînement et l'historique d'ajustement fin sous la mention UNKNOWN. Il comprend le hash de l'artefact, le format de sérialisation, le framework déduit et la source déclarée. Un verdict ALLOW et une signature locale valide ne complètent pas l'historique manquant.

Comment le worker est-il isolé ?

Le worker est un nouveau sous-processus Python disposant d'un répertoire de travail temporaire et d'un audit hook CPython qui enregistre les événements sélectionnés et bloque les effets configurés. Il ne comporte aucun conteneur ni bac à sable de système d'exploitation et ne constitue pas un environnement isolé du réseau. Cette démonstration n'établit pas de confinement de production ni de sécurité exhaustive.

Cela s'intègre-t-il à notre registre et à notre pipeline d'admission ?

La démonstration lit les artefacts générés à partir d'un registre synthétique local. Ses chaînes sources hf:// sont des libellés de fixtures, et elle ne comporte aucun connecteur de registre public ni application d'admission en entreprise. Une intégration en production exigerait des frontières de confiance de registre, un confinement, une gestion des clés et un stockage d'audit contrôlé de manière indépendante.

Recherche technique

Explorez les recherches associées pour un contexte plus large sur cette démonstration.

Définissez les preuves requises par votre porte d'admission

Échangez sur votre flux d'ingestion de modèles avec notre équipe.

Nous utilisons ces distinctions démontrées pour structurer une discussion d'évaluation ou d'implémentation autour de votre registre, de votre frontière de chargement et de vos exigences de preuves.

Évaluation de la conception de l'admission

  • ✓ Formats d'artefacts et voies d'ingestion
  • ✓ Vérifications et verdicts non résolus
  • ✓ Frontières de chargement et d'isolation
  • ✓ Exigences d'inventaire et d'audit

Planification de la mise en œuvre en production

  • ✓ Intégration au registre et au pipeline
  • ✓ Conception du confinement et du déploiement
  • ✓ Clés de signature et garde des preuves
  • ✓ Plan d'évaluation représentatif