Hugging Face y ModelAudit: un estudio muestra los límites de la protección integrada de modelos de ML

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

Cómo se montó la prueba

En el primer experimento, el autor no tomó todo Hugging Face, sino un subconjunto de repositorios con los formatos de almacenamiento de modelos más arriesgados. La muestra incluía solo modelos abiertos con archivos como `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` y `.npz`. Además, se descartaron los repositorios demasiado grandes y los modelos demasiado populares: el tamaño total se limitó a 1 GB y las descargas mensuales a 10 mil. La idea es simple: si se buscan problemas reales, es más razonable empezar por donde es mayor la probabilidad de serialización peligrosa.

• En el primer conjunto se escanearon 246 modelos
• ModelAudit encontró 271 advertencias críticas
• Al menos una alerta crítica recibieron 34 modelos
• Para la comparación se usaron repositorios completos, no checkpoints individuales dentro de ellos

Pero desde el principio quedó claro que un gran número de hallazgos no equivale a calidad de detección. El modelo con más detecciones fue Ultralytics/YOLO11: recibió 728 advertencias, 35 de ellas críticas. Sobre el papel parece una señal fuerte de compromiso, pero el análisis manual mostró un panorama más aburrido. Buena parte de las marcas críticas se debía a elementos estándar de Python que también pueden aparecer en modelos legítimos. Es decir, el escáner detectaba correctamente patrones potencialmente peligrosos, pero con demasiada frecuencia los trataba como prueba directa de un ataque.

Dónde hacen ruido las reglas

El análisis de YOLO11 mostró bien el punto débil del análisis estático. Algunas detecciones venían de `pickle_check` por `__builtin__.getattr`, y otras de `pytorch_zip_check` por `__builtin__.set` y rasgos similares. El problema es que `getattr` sí puede usarse en cadenas maliciosas para sortear reglas primitivas, pero también es una función corriente de Python presente en código normal. Con `set` el caso es aún más ilustrativo: un escáner interno de ModelAudit considera aceptable esa importación, mientras que otro puede marcar todo el espacio `builtin` como sospechoso.

Por eso el autor subraya que una alta densidad de alertas, incluso críticas, es motivo de triaje manual, no una sentencia contra el modelo. A lo largo del primer experimento examinó también otros tipos de detecciones, incluidas sospechas de firmas ejecutables dentro de archivos binarios, y volvió a toparse con el mismo problema: las reglas suelen servir para encontrar candidatos, pero funcionan mal como veredicto final sin contexto, sin conocer el formato del archivo y sin entender el framework concreto.

«No es lo que imaginaba cuando empezamos»

Comparación con Hugging Face

En el segundo experimento, el autor cambió el enfoque y reunió una lista de modelos que los propios autores de los repositorios ya habían etiquetado como malicious, exploit, ace, deserialization o poc. Tras un filtrado adicional con un LLM, el conjunto se pasó por ModelAudit y se compararon los resultados con los estados integrados de Hugging Face.

La comparación básica arrojó una coincidencia bastante alta: ambas partes consideraron peligrosos 154 repositorios y seguros 49. Además, hubo 14 casos en los que ModelAudit veía un problema y Hugging Face no mostraba nada sospechoso.

El matiz más importante es que parte de las señales útiles de ModelAudit no se sitúa solo en los niveles warning y critical. El artículo cita el ejemplo de `jossefharush/gpt2-rs`, donde una alerta de nivel INFO contenía indicios de actividad de red y un enlace a Pastebin. La comprobación posterior mostró que en ese enlace hay una puerta trasera que envía al atacante los resultados de los comandos ejecutados en la máquina de la víctima. Es decir, en este caso concreto el mensaje «informativo» resultó más relevante que muchas de las ruidosas marcas críticas del primer experimento.

Por separado, el autor analizó las discrepancias inversas, cuando Hugging Face avisaba de un peligro y ModelAudit pasaba el modelo por alto. Esos fallos se daban inicialmente en la versión 0.2.24, pero tras las actualizaciones a la 0.2.28 y luego a la 0.2.31 desaparecieron. El panorama final: todos los repositorios que Hugging Face acabó considerando peligrosos también fueron detectados por ModelAudit, y además el escáner externo conservó otros 17 repositorios con señales peligrosas que no aparecían en las advertencias integradas de HF.

Qué significa

Un solo escáner no resuelve el problema de seguridad de los artefactos de ML, aunque parezca el más maduro de su clase. El artículo sobre Hugging Face y ModelAudit deja una idea más útil: los buenos resultados no vienen de apostar por una única «mejor» herramienta, sino de combinar varias comprobaciones, actualizar las reglas con regularidad y revisar manualmente las detecciones más llamativas.