Hugging Face e ModelAudit: pesquisa revelou os limites da proteção integrada de modelos ML

Um pesquisador comparou as verificações de segurança integradas do Hugging Face com o scanner externo ModelAudit e obteve um resultado nada óbvio: uma ferramenta pode detectar mais sinais de risco, mas ao fazer isso cria muito ruído. A principal conclusão do artigo é que o número de alertas críticos por si só nos diz quase nada sobre o quão malicioso um modelo realmente é.

Como o teste foi organizado

No primeiro experimento, o autor não tomou todo o Hugging Face, mas um subconjunto de repositórios com os formatos mais arriscados de armazenamento de modelos. A seleção incluiu apenas modelos abertos que tinham arquivos como `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` e `.npz`. Além disso, repositórios muito grandes e modelos muito populares foram excluídos: o tamanho total foi limitado a 1 GB e o número de downloads por mês a 10 mil. A ideia é simples: se você está procurando por problemas reais, faz sentido primeiro olhar para onde a probabilidade de serialização perigosa é maior.

• No primeiro conjunto, 246 modelos foram escaneados
• ModelAudit encontrou 271 alertas críticos
• Pelo menos um alerta crítico foi disparado por 34 modelos
• Para comparação, os próprios repositórios foram examinados, não pontos de verificação individuais dentro deles

Mas logo no início ficou claro que um grande número de descobertas não é igual à qualidade da detecção. O modelo que se mostrou "mais rico" em detecções foi Ultralytics/YOLO11: recebeu 728 avisos, dos quais 35 eram críticos. No papel, isso parece um sinal forte de comprometimento, mas a análise manual mostrou uma situação mais mundana. Uma porção significativa dos sinalizadores críticos estava ligada a elementos padrão do Python que também podem ser encontrados em modelos legítimos. Em outras palavras, o scanner notou corretamente padrões potencialmente perigosos, mas muito frequentemente os interpretou como evidência direta de um ataque.

Onde as regras criam ruído

A análise do YOLO11 demonstrou claramente o ponto fraco da análise estática. Algumas detecções vieram de `pickle_check` devido a `__builtin__.getattr`, e outras de `pytorch_zip_check` devido a `__builtin__.set` e indicadores semelhantes. O problema é que `getattr` pode de fato ser usado em cadeias maliciosas para contornar regras primitivas, mas também é uma função Python ordinária que aparece em código normal. Com `set` a situação é ainda mais reveladora: um scanner ModelAudit interno considera tal importação aceitável, enquanto outro pode sinalizar o namespace `builtin` inteiro como suspeito. É por isso que o autor enfatiza especificamente: uma alta densidade de até alertas críticos é motivo para triagem manual, não uma sentença para o modelo.

Durante o primeiro experimento, ele também analisou outros tipos de detecções, incluindo suspeitas de assinaturas executáveis dentro de arquivos binários, e novamente se deparou com o mesmo problema: as regras geralmente são convenientes para encontrar candidatos, mas funcionam mal como um veredicto final sem contexto, formato de arquivo e compreensão do framework específico.

"Não foi assim que imaginei quando começamos"

Comparação com Hugging Face

No segundo experimento, o autor mudou o foco e compilou uma lista de modelos que os autores dos repositórios já haviam marcado como malicioso, exploit, ace, deserialization ou poc. Após filtragem adicional através de um LLM, este conjunto foi executado através do ModelAudit e os resultados foram comparados com os status integrados do Hugging Face. A comparação básica mostrou concordância bastante forte: 154 repositórios foram considerados perigosos por ambos os lados, e 49 foram considerados seguros. No entanto, havia 14 casos em que ModelAudit viu um problema enquanto Hugging Face não mostrou nada suspeito.

A nuance mais importante aqui é que alguns dos sinais úteis do ModelAudit existem não apenas nos níveis de aviso e crítico. O artigo fornece um exemplo de `jossefharush/gpt2-rs`, onde um alerta de nível INFO continha sinais de atividade de rede e um link para Pastebin. Verificação adicional mostrou que este link continha uma porta traseira que envia os resultados da execução de comandos na máquina da vítima para um atacante. Ou seja, a mensagem "informacional" naquele caso particular se mostrou ser mais substancialmente importante do que muitos sinalizadores críticos altos no primeiro experimento.

O autor também analisou separadamente discrepâncias inversas, quando Hugging Face sinalizava perigo, mas ModelAudit deixava o modelo passar. Inicialmente, essas falhas ocorriam na versão 0.2.24, mas após atualizações para 0.2.28 e depois para 0.2.31, esses casos desapareceram. O quadro final parecia assim: todos os repositórios que Hugging Face finalmente considerou perigosos também foram capturados pelo ModelAudit, e além disso o scanner externo tinha 17 mais repositórios com sinais perigosos que não estavam nos avisos integrados do HF.

O que isso significa

Nenhum scanner único resolve o problema de segurança dos artefatos de ML, mesmo que pareça ser o mais maduro em sua classe. O artigo sobre Hugging Face e ModelAudit demonstra um insight mais útil: bons resultados vêm não de apostar em uma ferramenta "melhor", mas de uma combinação de múltiplas verificações, atualizações regulares de regras e análise manual obrigatória das detecções mais altas.