Hugging Face y ModelAudit: la investigación reveló los límites de la protección integrada de modelos ML

Un investigador comparó las comprobaciones de seguridad integradas de Hugging Face con el escáner externo ModelAudit y obtuvo un resultado nada obvio: una herramienta puede detectar más señales de riesgo, pero al hacerlo crea mucho ruido. La conclusión principal del artículo es que el número de alertas críticas por sí solo nos dice casi nada sobre lo maligno que es realmente un modelo.

Cómo se organizó la prueba

En el primer experimento, el autor no tomó todo Hugging Face, sino un subconjunto de repositorios con los formatos más riesgosos de almacenamiento de modelos. La selección incluyó solo modelos abiertos que tenían archivos como `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` y `.npz`. Además, se excluyeron repositorios muy grandes y modelos muy populares: el tamaño total se limitó a 1 GB y el número de descargas por mes a 10.000. La idea es simple: si busca problemas reales, tiene sentido primero mirar dónde la probabilidad de serialización peligrosa es mayor.

• En el primer conjunto se escanearon 246 modelos
• ModelAudit encontró 271 advertencias críticas
• Al menos una alerta crítica fue desencadenada por 34 modelos
• Para la comparación, se examinaron los repositorios mismos, no puntos de control individuales dentro de ellos

Pero desde el principio quedó claro que un gran número de hallazgos no es igual a la calidad de la detección. El modelo que resultó ser el "más rico" en detecciones fue Ultralytics/YOLO11: recibió 728 advertencias, de las cuales 35 eran críticas. En el papel, esto parece una señal fuerte de compromiso, pero el análisis manual mostró una situación más mundana. Una porción significativa de las banderas críticas estaba vinculada a elementos estándar de Python que también se pueden encontrar en modelos legítimos. En otras palabras, el escáner notó correctamente patrones potencialmente peligrosos, pero muy a menudo los interpretó como evidencia directa de un ataque.

Dónde las reglas crean ruido

El análisis de YOLO11 demostró claramente el punto débil del análisis estático. Algunas detecciones vinieron de `pickle_check` debido a `__builtin__.getattr`, y otras de `pytorch_zip_check` debido a `__builtin__.set` e indicadores similares. El problema es que `getattr` puede usarse en cadenas maliciosas para eludir reglas primitivas, pero también es una función Python ordinaria que aparece en código normal. Con `set` la situación es aún más reveladora: un escáner ModelAudit interno considera que tal importación es aceptable, mientras que otro podría marcar todo el espacio de nombres `builtin` como sospechoso. Por eso el autor enfatiza específicamente: una alta densidad incluso de alertas críticas es razón para un triaje manual, no una sentencia para el modelo.

Durante el primer experimento, también analizó otros tipos de detecciones, incluidas sospechas de firmas ejecutables dentro de archivos binarios, y nuevamente se topó con el mismo problema: las reglas generalmente son convenientes para encontrar candidatos, pero funcionan mal como un veredicto final sin contexto, formato de archivo y comprensión del marco específico.

"Así no me lo imaginé cuando comenzamos"

Comparación con Hugging Face

En el segundo experimento, el autor cambió de enfoque y compiló una lista de modelos que los autores de los repositorios ya habían marcado como malicioso, exploit, ace, deserialization o poc. Después de un filtrado adicional a través de un LLM, este conjunto se ejecutó a través de ModelAudit y los resultados se compararon con los estados integrados de Hugging Face. La comparación básica mostró una concordancia bastante fuerte: 154 repositorios fueron considerados peligrosos por ambos lados, y 49 fueron considerados seguros. Sin embargo, había 14 casos en los que ModelAudit vio un problema mientras que Hugging Face no mostró nada sospechoso.

El matiz más importante aquí es que algunas de las señales útiles de ModelAudit existen no solo en los niveles de advertencia y crítico. El artículo proporciona un ejemplo de `jossefharush/gpt2-rs`, donde una alerta de nivel INFO contenía signos de actividad de red y un enlace a Pastebin. La verificación adicional mostró que este enlace contenía una puerta trasera que envía los resultados de la ejecución de comandos en la máquina de la víctima a un atacante. Es decir, el mensaje "informativo" en ese caso particular resultó ser más sustancialmente importante que muchas banderas críticas ruidosas del primer experimento.

El autor también analizó por separado discrepancias inversas, cuando Hugging Face señalaba peligro pero ModelAudit dejaba pasar el modelo. Inicialmente, tales errores ocurrían en la versión 0.2.24, pero después de actualizaciones a 0.2.28 y luego a 0.2.31, estos casos desaparecieron. El panorama final se veía así: todos los repositorios que Hugging Face finalmente consideró peligrosos también fueron capturados por ModelAudit, y además el escáner externo tenía 17 repositorios más con señales peligrosas que no estaban en las advertencias integradas del HF.

Qué significa esto

Ningún escáner único resuelve el problema de seguridad de los artefactos de ML, incluso si parece ser el más maduro en su clase. El artículo sobre Hugging Face y ModelAudit demuestra una idea más útil: los buenos resultados no provienen de apostar en una herramienta "mejor", sino de una combinación de múltiples comprobaciones, actualizaciones regulares de reglas y análisis manual obligatorio de las detecciones más ruidosas.