Hugging Face e ModelAudit: estudo mostra os limites da proteção embutida para modelos de ML

Um pesquisador comparou as verificações de segurança embutidas do Hugging Face com o scanner externo ModelAudit e chegou a um resultado nada óbvio: uma ferramenta pode enxergar mais sinais de risco, mas ao mesmo tempo gerar muito ruído. A principal conclusão do artigo é que o número de alertas críticos, sozinho, diz quase nada sobre o quanto um modelo é de fato malicioso.

Como o teste foi montado

No primeiro experimento, o autor não pegou todo o Hugging Face, mas um subconjunto de repositórios com os formatos de armazenamento de modelos mais arriscados. A amostra incluía apenas modelos abertos com arquivos como `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` e `.npz`. Além disso, foram descartados repositórios grandes demais e modelos populares demais: o tamanho total foi limitado a 1 GB e os downloads mensais a 10 mil. A ideia é simples: para achar problemas reais, é mais sensato começar onde a probabilidade de serialização perigosa é maior.

• No primeiro conjunto, foram escaneados 246 modelos
• O ModelAudit encontrou 271 avisos críticos
• Pelo menos um alerta crítico atingiu 34 modelos
• A comparação usou repositórios inteiros, e não checkpoints individuais dentro deles

Mas logo no início ficou claro que muitos achados não significam qualidade de detecção. O modelo com mais disparos foi o Ultralytics/YOLO11: recebeu 728 avisos, 35 deles críticos. No papel, parece um forte sinal de comprometimento, mas a análise manual mostrou um quadro mais banal. Boa parte das marcações críticas estava ligada a elementos padrão do Python, que também podem aparecer em modelos legítimos. Ou seja, o scanner identificava corretamente padrões potencialmente perigosos, mas com frequência demais os tratava como prova direta de ataque.

Onde as regras fazem barulho

A análise do YOLO11 mostrou bem o ponto fraco da análise estática. Parte dos disparos vinha do `pickle_check` por causa de `__builtin__.getattr`, e parte do `pytorch_zip_check` por causa de `__builtin__.set` e indícios semelhantes. O problema é que o `getattr` realmente pode ser usado em cadeias maliciosas para driblar regras primitivas, mas também é uma função comum do Python, presente em código normal. Com o `set`, o caso é ainda mais revelador: um scanner interno do ModelAudit considera esse import aceitável, enquanto outro pode marcar todo o espaço `builtin` como suspeito.

Por isso o autor ressalta que uma alta densidade de alertas, mesmo críticos, é motivo para triagem manual, e não uma sentença para o modelo. Ao longo do primeiro experimento, ele examinou também outros tipos de disparo, incluindo suspeitas de assinaturas executáveis dentro de arquivos binários, e esbarrou de novo no mesmo problema: as regras costumam ser úteis para encontrar candidatos, mas funcionam mal como veredito final sem contexto, sem o formato do arquivo e sem entender o framework específico.

"Não era isso que eu imaginava quando começamos"

Comparação com o Hugging Face

No segundo experimento, o autor mudou o foco e montou uma lista de modelos que os próprios autores dos repositórios já tinham marcado como malicious, exploit, ace, deserialization ou poc. Depois de uma filtragem adicional com um LLM, o conjunto passou pelo ModelAudit e os resultados foram comparados com os status embutidos do Hugging Face.

A comparação básica mostrou uma concordância bastante forte: ambos os lados consideraram 154 repositórios perigosos e 49 seguros. Também houve 14 casos em que o ModelAudit via um problema e o Hugging Face não mostrava nada suspeito.

A nuance mais importante é que parte dos sinais úteis do ModelAudit não está apenas nos níveis warning e critical. O artigo traz o exemplo de `jossefharush/gpt2-rs`, em que um alerta de nível INFO continha indícios de atividade de rede e um link para o Pastebin. A verificação posterior mostrou que nesse link há um backdoor que envia ao invasor os resultados de comandos executados na máquina da vítima. Ou seja, nesse caso concreto a mensagem "informativa" se revelou mais relevante do que muitas das barulhentas marcações críticas do primeiro experimento.

Separadamente, o autor analisou as divergências inversas, em que o Hugging Face sinalizava perigo e o ModelAudit deixava o modelo passar. Essas falhas ocorriam inicialmente na versão 0.2.24, mas, após as atualizações para a 0.2.28 e depois a 0.2.31, esses casos sumiram. O quadro final: todos os repositórios que o Hugging Face acabou considerando perigosos também foram pegos pelo ModelAudit, e, além disso, o scanner externo manteve mais 17 repositórios com sinais perigosos que não estavam nos avisos embutidos do HF.

O que isso significa

Um único scanner não resolve o problema de segurança dos artefatos de ML, mesmo que pareça o mais maduro da categoria. O artigo sobre Hugging Face e ModelAudit traz uma lição mais útil: bons resultados não vêm de apostar em uma única "melhor" ferramenta, mas de combinar várias verificações, atualizar as regras com regularidade e revisar manualmente os disparos mais barulhentos.