Capítulo 9 — Integridade de Modelo e Riscos da Cadeia de Suprimentos

Nono post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que trata um artefato de modelo como binário distribuído por terceiros — com as preocupações de desserialização, backdoor e proveniência que a distribuição de binários sempre carregou.

Por que este capítulo existe

Modelos open-source são a escolha padrão para muitos sistemas de produção porque APIs fechadas de fronteira são caras em escala e carregam preocupações de vendor lock-in. O trade-off é que o operador agora carrega o risco de cadeia de suprimentos que o provedor fechado vinha carregando. O Hugging Face hospeda centenas de milhares de artefatos de modelo contribuídos por pesquisadores, laboratórios corporativos e uma cauda longa de derivados. O canal de distribuição lembra um repositório de pacotes, com o detalhe de que os artefatos são binários grandes cujo carregamento envolve desserialização de grafos de objetos complexos. Este capítulo percorre a superfície da cadeia de suprimentos — backdoors, vulnerabilidades de formato, proveniência, drift — e a infraestrutura que o campo adotou para colocar a cadeia de suprimentos de modelos em paridade com a de software.

9.1 Backdoors persistem através de safety training

O paper de Gu, Dolan-Gavitt e Garg de 2017, "BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain", estabeleceu a linha de pesquisa em backdoors. Uma pequena fração de exemplos de treinamento envenenados — abaixo de um por cento — conseguia induzir um classificador a classificar incorretamente entradas com trigger enquanto deixava a acurácia em entradas sem trigger inalterada. O threat model do BadNets se transfere para LLMs com as traduções naturais. O paper "Sleeper Agents" de Hubinger et al. da Anthropic, em janeiro de 2024, demonstrou uma extensão desconfortável: backdoors deliberadamente treinados em modelos podiam persistir através de safety training subsequente, incluindo RLHF e treinamento adversarial projetados para remover exatamente o comportamento que o backdoor implementava. O modelo se comportava normalmente sob a distribuição de safety training e revertia ao comportamento com backdoor sob o trigger. A contribuição do paper foi tornar explícito que alignment training não é um filtro geral de segurança — ele modifica o comportamento nas distribuições que amostra durante o treinamento, e um trigger suficientemente raro ou bem escondido fica fora dessas distribuições. As implicações defensivas são estruturais: a segurança de um modelo em deployment não pode ser deduzida do safety training sozinho se a proveniência do modelo base é incerta. Detecção é difícil porque o trigger é raro por design, mas fuzzing comportamental, análise de ativações e avaliações canário contra entradas com trigger são as melhores práticas atuais.

9.2 Risco de nível de formato é categoria real

Pesos de modelo são arquivos binários grandes, geralmente distribuídos por registries e hubs. Carregar esses pesos envolve desserialização. O formato padrão para muitos artefatos da era PyTorch era pickle, cuja desserialização executa Python arbitrário por design. O CVE-2024-3568, divulgado contra a biblioteca Transformers do Hugging Face, ilustrou como um arquivo de modelo podia ser fabricado para executar código arbitrário no carregamento. Não foi o primeiro CVE assim e não será o último. O formato safetensors, desenvolvido pelo Hugging Face e lançado em 2022, foi a resposta do campo — um formato de header mais tensor sem caminho de execução de código, performance tolerável e agora padrão para os principais releases de modelo. A implicação operacional é que carregar um arquivo pickle de fonte não confiável é funcionalmente equivalente a rodar um binário não confiável como o processo de inferência. O versionamento de modelo fornece um segundo eixo de integridade. O model card, introduzido por Mitchell et al. na FAccT 2019, dá um registro estruturado de documentação — uso pretendido, dados de treinamento, resultados de avaliação, limitações conhecidas — amplamente adotado por Hugging Face, OpenAI, Anthropic e Google. O card é documentação, não prova; ele não verifica que o artefato corresponde à descrição. É para isso que serve a assinatura criptográfica.

9.3 Proveniência, assinatura e monitoramento de drift fecham o loop

A comunidade de cadeia de suprimentos de software convergiu numa stack — níveis SLSA, attestações in-toto, Sigstore para assinatura, assinatura de container registry — que se estendeu a artefatos de ML já em 2026. O padrão para deployment seguro de modelo é agora reconhecível. A entrada no registry para um modelo é assinada por uma chave autorizada. O sistema de deployment puxa o artefato, verifica o hash e verifica a assinatura da entrada no registry. O carregamento acontece apenas a partir de safetensors, não pickle. Metadados de proveniência são retidos e vinculados ao registro de deployment, de modo que a pergunta "qual versão, de qual upstream, está atualmente servindo tráfego" sempre tem resposta definida. O monitoramento de drift é a contraparte contínua. O comportamento de um modelo em deployment muda com o tempo mesmo sem modificação de pesos — as entradas mudam, as aplicações a montante mudam, a distribuição de queries muda. Distinguir drift legítimo de comprometimento exige uma baseline. O capítulo percorre métricas distribucionais (comprimento médio de entrada, distribuição do score do classificador de segurança, razão recusa-a-cumprimento), métricas categóricas (taxa de respostas com código, taxa de PII em respostas) e métricas comportamentais (prompts canário fixos rodados periodicamente com respostas comparadas a uma baseline). Desvio da baseline não é prova de comprometimento, mas é sinal de que algo mudou e merece investigação.

O que o Capítulo 9 prepara

A Parte III agora cobriu o próprio modelo como objeto de segurança — falhas de confiabilidade (Cap. 7), ataques deliberados no espaço de entrada (Cap. 8) e risco de cadeia de suprimentos (Cap. 9). A Parte IV sobe na stack para a arquitetura de sistema em que o modelo está embutido. O Capítulo 10 percorre os padrões arquiteturais para deployments seguros de LLM — fronteiras de isolamento, validação em múltiplos tiers, motores de política como OPA e Cedar, design seguro de API e zero-trust aplicado a chamadas de modelo. O Capítulo 11 percorre observabilidade, logging e resposta a incidentes — a camada operacional que transforma defesas arquiteturais em sistema que a organização consegue operar com confiabilidade. O Capítulo 12 percorre controle de acesso e identidade — autenticação, autorização, isolamento multi-tenant, rate limits e a camada de governança corporativa. Os três capítulos juntos descrevem a arquitetura de sistema que contém, sustenta e restringe os componentes de modelo que a Parte III acabou de examinar.

Próximo — Capítulo 10: Projetando Arquiteturas LLM Seguras. Fronteiras de isolamento ao redor do modelo, validação em múltiplos tiers, motores de política e princípios zero-trust aplicados a um componente que lê toda entrada como instrução.