Crucible · Firewall de evaluación de modelos

Un escaneo limpio deja abierta la cuestión de la carga

Un modelo sintético supera la línea base de PickleScan y luego intenta abrir una base de datos durante la carga. Crucible registra y bloquea ese efecto configurado, devolviendo QUARANTINE con las pruebas adjuntas.

23/23 vs 19/23

Detección de eventos bloqueados frente a alertas de PickleScan

Los mismos 23 casos de prueba sintéticos maliciosos y evasores

4/4 vs 0/4

Cuatro evasores construidos

Detección conductual frente a PickleScan 1.0.4

2/2

Casos de abstención dirigidos a REVIEW

Se requieren más pruebas; no se emitió firma

Las tarjetas informan sobre una ejecución de referencia fija de 33 artefactos sintéticos en canalización directa realizada el 6 de octubre de 2026 con asesoramiento determinista. No estiman la detección en modelos desconocidos. El video captura por separado comprobaciones configuradas recientes en la aplicación local: la consola principal utiliza asesoramiento en caché de Codex y la prueba de rendimiento utiliza asesoramiento determinista. No se captura inferencia reciente de modelos.

La decisión necesita pruebas sobre la carga

Cuando un equipo de seguridad aprueba un modelo serializado, la pregunta pertinente va más allá de su identidad declarada: ¿qué operación intenta realizar la carga y qué pruebas quedan sin resolver?

Python advierte que los datos pickle manipulados pueden ejecutar código durante la deserialización. La documentación de escaneo de pickle de Hugging Face también describe las limitaciones de la inspección de importaciones y códigos de operación. Documentación de pickle de Python; Documentación de escaneo de pickle de Hugging Face.

Nuestro caso de prueba sintético de SQLite hace que esa distinción sea inspeccionable: una línea base sin alerta de infección se sitúa junto a un intento bloqueado de apertura de base de datos. El registro de admisión conserva ambos hallazgos en lugar de tratar el campo limpio del escáner como una autorización.

Cómo se toma la decisión configurada

  1. Inspeccionar el contenido pickle admitido. El desensamblado estático de códigos de operación registra las variables globales y aproxima los ejecutables invocados. La línea base instalada de PickleScan proporciona un campo de comparación independiente; su alerta no decide directamente el veredicto.
  2. Observar un intento de carga. Un nuevo subproceso de Python utiliza un gancho de auditoría de CPython para registrar eventos seleccionados y generar una excepción antes de los efectos bloqueados configurados, incluidas la conexión SQLite y la conexión por socket. Esto es instrumentación de Python con separación de procesos, sin confinamiento de contenedor ni de sistema operativo.
  3. Aplicar la compuerta y retener la incertidumbre. Un evento conductual bloqueado devuelve QUARANTINE. Una caída o tiempo de espera agotado del ejecutor, un error de desensamblado de pickle o una variable global estática peligrosa no ejecutada devuelven REVIEW. De lo contrario, la compuerta base devuelve ALLOW; la duda del evaluador desafiante puede cambiar ALLOW a REVIEW, mientras que QUARANTINE permanece vigente.
  4. Adjuntar un registro acotado. Cada resultado recibe un inventario de modelo mínimo en formato CycloneDX y campos locales de cadena de hashes. Solo ALLOW recibe una firma con clave de desarrollo sobre el nombre del modelo, el hash del artefacto y el inventario. El historial ascendente desconocido permanece como UNKNOWN.

El asesoramiento utiliza roles de analista y desafiante en una única solicitud combinada. La consola principal grabada utiliza asesoramiento en caché; la prueba de rendimiento utiliza asesoramiento determinista. Estas comprobaciones configuradas no garantizan que cada archivo con formato incorrecto, formato no admitido o error de análisis se dirija a REVIEW.

Seguir un artefacto desde el escaneo limpio hasta la decisión de admisión

Todos los artefactos, nombres de modelos y hf:// etiquetas de origen a continuación son casos de prueba locales sintéticos, no modelos de clientes ni registros verificados de registros de modelos. Las primeras tres capturas de pantalla registran comprobaciones configuradas recientes con asesoramiento en caché de Codex; la captura independiente de la prueba de rendimiento utiliza asesoramiento determinista. No se muestra ninguna inferencia reciente de modelos.

Ejemplo práctico: una línea base limpia, un intento de base de datos bloqueado

El archivo pickle generado trusted-looking/finetune-safe intenta abrir una base de datos SQLite durante la deserialización. Su nombre es una etiqueta de caso de prueba creada por los autores, no una prueba de confianza. La pregunta útil es si el hallazgo del escáner y el comportamiento de carga observado respaldan la misma decisión de admisión.

Resultado configurado

PickleScan: CLEAN. Operación observada: sqlite3.connect, intentada y bloqueada. Veredicto final: QUARANTINE. Firma: ninguna.

Evasor sintético de SQLite en Crucible que muestra PickleScan CLEAN, sqlite3.connect bloqueado y QUARANTINE
Evasor sintético de SQLite: PickleScan no alerta sobre el artefacto; el gancho de auditoría configurado registra y bloquea su intento de operación de base de datos. QUARANTINE no emite firma. NO CODE SURFACE significa que no hubo coincidencias con variables globales peligrosas configuradas; _sqlite3.connect sigue presente. La mención del entorno aislado en la interfaz de usuario hace referencia a la instrumentación de auditoría en un subproceso, sin confinamiento de sistema operativo ni de contenedor. Abra la imagen para inspeccionarla a tamaño completo.

1. Leer los hallazgos del escáner y los estáticos por separado

PickleScan 1.0.4 registra _sqlite3.connect como sospechoso sin activar su alerta de infección. El desensamblado estático de Crucible también conserva ese ejecutable importado, pero está ausente del conjunto configurado de variables globales peligrosas. Por lo tanto, el distintivo visible NO CODE SURFACE significa que no hubo coincidencias con variables globales peligrosas configuradas; no significa que el archivo no contenga ningún ejecutable.

Pruebas del artefacto sintético de SQLite
ComprobaciónHallazgo registradoQué determina
Línea base de PickleScanflagged: false; _sqlite3.connect [suspicious]Esta línea base no alerta sobre el artefacto. No determina una carga inocua.
Desensamblado estático_sqlite3.connect en importaciones y ejecutables aproximados; ninguna variable global peligrosa configuradaEl ejecutable es visible aunque la lista de denegación configurada no tenga coincidencias.
Carga observadasqlite3.connect con blocked: true; loaded: falseEl gancho de auditoría genera una excepción antes del efecto configurado de apertura de base de datos.
Compuerta finalQUARANTINE; signature: nullEl intento bloqueado determina este veredicto. No se emite ninguna firma.

2. Utilizar el efecto intentado para decidir la ruta

El nuevo proceso de trabajo de Python llega a sqlite3.connect para /tmp/vp_demo_persist/.store.db. Su gancho de auditoría de CPython registra la operación y genera una excepción antes del efecto configurado. La compuerta devuelve QUARANTINE porque se observó un evento peligroso bloqueado, independientemente de la alerta limpia de la línea base. Esta prueba no muestra una base de datos creada ni una persistencia correcta.

La interfaz de usuario llama a este proceso de trabajo un entorno aislado (sandbox). Su límite implementado es un subproceso con ganchos de auditoría de Python seleccionados, sin un entorno aislado del sistema operativo, confinamiento de contenedor ni aislamiento de red. Un sistema de admisión en producción necesita un límite de contención establecido por separado.

3. Mantener la decisión vinculada al artefacto y al registro

El registro JSON descargable asocia el SHA-256 del artefacto con sus hallazgos estáticos, el resultado de la línea base, las llamadas intentadas, el motivo de la compuerta, el inventario mínimo del modelo y los campos locales de cadena de hashes. Para este resultado de QUARANTINE, el campo de firma es null. Los revisores pueden inspeccionar las pruebas de la decisión sin tratar las recomendaciones de asesoramiento como una aprobación o una acción completada en el registro de modelos.

Un hash identifica los bytes del artefacto inspeccionado. La cadena local permite comprobaciones de coherencia entre registros, pero no tiene custodia independiente ni anclaje externo, y no es un archivo inmutable. La carga útil de ALLOW firmada que se muestra a continuación cubre un conjunto de campos más restringido que el registro completo de pruebas.

Una carga silenciosa deja un hallazgo condicional sin resolver

El caso de prueba sintético independiente acme/experimental-rl contiene builtins.eval en la inspección estática. Su bifurcación condicional no se ejecuta en este entorno, y la carga observada no registra ningún evento peligroso bloqueado. El hallazgo estático no resuelto lo envía a REVIEW sin firma. Esta ruta preserva la necesidad de más pruebas; no se muestra una investigación humana completada.

Caso de prueba condicional sintético en Crucible que muestra builtins.eval, ningún evento de tiempo de ejecución bloqueado y REVIEW
Caso de prueba condicional sintético: la inspección estática detecta builtins.eval, mientras que la carga observada no registra ningún evento peligroso bloqueado. REVIEW no emite firma y desvía el artefacto para obtener más pruebas en lugar de considerarlo una revisión humana completada. Abra la imagen para inspeccionarla a tamaño completo.

ALLOW firma el inventario local mientras la procedencia permanece desconocida

El diccionario de pesos generado acme/sentiment-mlp sigue la ruta limpia: no se registra ningún evento peligroso bloqueado, las comprobaciones configuradas devuelven ALLOW y se emite una firma Ed25519. Su inventario indica el artefacto y su hash, el formato de serialización, el marco inferido y el origen declarado. La procedencia de los datos de entrenamiento y el historial de ajuste fino permanecen como UNKNOWN.

Inventario sintético de pesos limpios en Crucible que muestra procedencia UNKNOWN y firma local Ed25519
Diccionario sintético de pesos limpios: ALLOW recibe una firma con clave de desarrollo local sobre el nombre del modelo, el hash y el inventario. La procedencia del entrenamiento y el historial de ajuste fino permanecen como UNKNOWN. El texto visible de referencia del marco de trabajo es una etiqueta configurada, sin validación legal ni dictamen de cumplimiento normativo. Abra la imagen para inspeccionarla a tamaño completo.

La firma autentica el nombre canónico del modelo, el hash del artefacto y la carga útil mínima del inventario en formato CycloneDX con respecto a una clave de desarrollo local. No firma cada veredicto ni el registro completo, no completa el historial ascendente, no establece derechos de entrenamiento ni demuestra que un modelo arbitrario sea seguro. El texto visible de referencia regulatoria son metadatos configurados del caso de prueba, no un cumplimiento validado.

Interpretar la comparación del conjunto fijo con su denominador

Una ejecución de referencia congelada en canalización directa del 6 de octubre de 2026 utiliza asesoramiento determinista, PickleScan 1.0.4, claves de desarrollo temporales y un libro mayor temporal. Sus 33 artefactos generados comprenden 8 benignos, 19 maliciosos, 4 evasores construidos y 2 casos de abstención. La comparación de maliciosos y evasores contabiliza los mismos 23 artefactos en ambas columnas.

Ejecución de referencia sintética fija de 33 artefactos en canalización directa
MediciónResultado observadoAlcance
Detección de maliciosos y evasoresConductual 23/23; PickleScan 19/23Detección de eventos bloqueados en comparación con la alerta de infección de la línea base en los mismos 23 casos de prueba.
Evasores construidosConductual 4/4; PickleScan 0/4Cuatro casos de prueba diseñados para ilustrar la diferencia entre estas comprobaciones.
Decisiones sobre benignos0/8 recibieron un veredicto distinto de ALLOWOcho casos de prueba benignos, no una estimación de falsos positivos en modelos desconocidos.
Firmas de ALLOW8/8 emitidas y verificadasLa verificación utiliza la función incluida y la clave de desarrollo local.
Ruta de abstención2/2 REVIEWLos casos de prueba no resueltos permanecen sin firmar; la investigación no está completada.
Veredictos esperados y cadena local33/33 coincidieron; enlaces de hash intactosExpectativas definidas para los casos de prueba y una comprobación de coherencia local, sin anclaje externo.

La captura de pantalla siguiente corresponde a una ejecución independiente completada de la prueba de rendimiento HTTP/SSE en la aplicación local, con asesoramiento determinista. Muestra la misma comparación sobre el conjunto fijo y 33/33 coincidencias de veredictos esperados. No es la fuente de la medición de referencia congelada en canalización directa anterior; los tiempos mostrados pertenecen a esa ejecución capturada.

Prueba de rendimiento sintética completada en Crucible que muestra 33 de 33 veredictos esperados, detección conductual 23 de 23 y alertas de PickleScan 19 de 23
Prueba de rendimiento local HTTP/SSE completada: los 33 casos de prueba sintéticos coinciden con sus veredictos esperados. La detección conductual de eventos bloqueados es de 23/23 y las alertas de PickleScan de 19/23 en el mismo conjunto de maliciosos y evasores. El asesoramiento es determinista. Solo ALLOW firma la carga útil del inventario; REVIEW y QUARANTINE no están firmados. La cadena local de hashes no tiene anclaje externo y los tiempos mostrados no representan la latencia en producción. Abra la imagen para inspeccionarla a tamaño completo.

Estas observaciones sobre casos de prueba construidos no estiman la detección en modelos no vistos, la latencia en producción ni la reducción de brechas de seguridad. ALLOW describe el resultado de las comprobaciones configuradas en la carga observada; no establece una seguridad exhaustiva del modelo.

Qué puede determinar cada capa

CapaPruebas en esta demostraciónLímite que se debe mantener
Inspección estática y PickleScanVariables globales, ejecutables aproximados y alerta de la línea baseUna alerta limpia por sí sola no resuelve el comportamiento de carga
Observación conductualEfectos intentados seleccionados en una carga observadaUna carga silenciosa puede dejar el comportamiento condicional sin resolver
Inventario firmadoNombre local del modelo, hash y carga útil de inventario para ALLOWLa firma no certifica el historial ascendente desconocido
Libro mayor local encadenado por hashesEnlaces de hash que respaldan las comprobaciones de coherencia localSin custodia independiente ni anclaje externo

Lo que esta demostración NO hace

Crucible es una demostración local sobre artefactos sintéticos. No dispone de conector con registros públicos, aplicación de políticas de admisión empresarial, entorno aislado del sistema operativo, infraestructura de claves de producción ni reconstrucción completa de dependencias. No evalúa la calidad del modelo, la seguridad de la inferencia ni el envenenamiento de datos de entrenamiento, y sus etiquetas de referencia del marco no determinan cumplimiento normativo.

Python advierte de que los ganchos de auditoría no son adecuados para implementar un entorno aislado. Documentación de ganchos de auditoría de Python. El trabajo en producción debe establecer contención, límites de confianza y custodia controlada más allá de esta demostración local.

Preguntas que se hacen los equipos de seguridad y plataformas

¿Qué puede determinar un escaneo de pickle limpio?

Un resultado limpio de PickleScan significa que esta línea base no alertó sobre el artefacto inspeccionado. En el ejemplo sintético de SQLite en Crucible, el gancho de auditoría configurado registra y bloquea un intento de operación de base de datos durante la carga mientras la línea base permanece limpia. El resultado del escáner por sí solo no determina una carga libre de efectos secundarios.

¿Qué sucede si las pruebas estáticas sospechosas no se ejecutan durante la carga?

Crucible desvía una variable global estática peligrosa configurada a REVIEW cuando la carga observada no ejecuta un evento peligroso bloqueado. El caso de prueba condicional sintético contiene builtins.eval y sigue esta ruta sin firma. REVIEW solicita más pruebas; no significa que una investigación humana esté completada.

¿Qué cubre la firma?

Solo ALLOW recibe una firma Ed25519 sobre el nombre canónico del modelo, el hash del artefacto y la carga útil del inventario, utilizando una clave de desarrollo local. Autentica esa carga útil en relación con esta clave. No establece custodia ascendente, autenticidad del origen ni una procedencia completa.

¿Qué procedencia ascendente permanece desconocida?

El inventario mínimo de modelos en formato CycloneDX registra la procedencia de los datos de entrenamiento y el historial de ajuste fino como UNKNOWN. Incluye el hash del artefacto, el formato de serialización, el marco inferido y el origen declarado. Un veredicto ALLOW y una firma local válida no completan el historial ausente.

¿Cómo se aísla el proceso de trabajo?

El proceso de trabajo es un nuevo subproceso de Python con un directorio de trabajo temporal y un gancho de auditoría de CPython que registra eventos seleccionados y bloquea efectos configurados. No cuenta con contenedor ni entorno aislado del sistema operativo y no es un entorno aislado de la red. Esta demostración no establece contención de producción ni seguridad exhaustiva.

¿Se integra esto con nuestro registro de modelos y canalización de admisión?

La demostración lee artefactos generados desde un registro sintético local. Sus cadenas de origen hf:// son etiquetas de casos de prueba y no dispone de conector con registros públicos ni aplicación de admisión empresarial. La integración en producción requeriría límites de confianza del registro, contención, gestión de claves y almacenamiento de auditoría controlado de forma independiente.

Investigación técnica

Explore las investigaciones relacionadas para obtener un contexto más amplio sobre esta demostración.

Defina las pruebas que necesita su compuerta de admisión

Analice su flujo de trabajo de incorporación de modelos con nuestro equipo.

Utilizamos estas distinciones demostradas para orientar una conversación de evaluación o implementación sobre su registro de modelos, el límite de carga y los requisitos de pruebas.

Evaluación del diseño de admisión

  • ✓ Formatos de artefactos y rutas de incorporación
  • ✓ Comprobaciones y veredictos no resueltos
  • ✓ Límites de carga y aislamiento
  • ✓ Requisitos de inventario y auditoría

Planificación de la implementación en producción

  • ✓ Integración con registros y canalizaciones
  • ✓ Diseño de contención e implementación
  • ✓ Claves de firma y custodia de pruebas
  • ✓ Plan de evaluación representativa