Riscos de modelo, dados e cadeia de suprimentos

Uma aplicação de LLM é composta por muitas peças de terceiros: modelos-base, ajustes finos, conjuntos de dados, representações vetoriais, plug-ins e dependências de software comuns. Cada elo é um ponto em que um invasor pode inserir uma comprometimento.

Diferentemente do software tradicional, os artefatos de aprendizado de máquina costumam ser binários grandes e opacos, obtidos de repositórios públicos com proveniência fraca. Um arquivo de pesos envenenado ou um conjunto de dados com uma porta dos fundos é difícil de identificar apenas por inspeção.

Proteger o fluxo significa rastrear e verificar cada componente desde a origem até a produção.

O envenenamento de dados manipula dados de treinamento ou de ajuste fino para corromper o modelo resultante. Um invasor que consiga contribuir com até mesmo uma pequena fração das amostras de treinamento pode alterar o comportamento de forma mensurável.

• Ataques de disponibilidade: reduzem a precisão geral.
• Ataques direcionados: causam classificações incorretas específicas.
• Ataques de porta dos fundos: implantam um gatilho oculto (veja a próxima cena).

Dados coletados da web e documentos do RAG enviados por usuários são pontos de entrada comuns para envenenamento, pois são grandes e passam por pouca verificação.

Uma porta dos fundos é um ataque de envenenamento que faz o modelo se comportar normalmente, exceto quando um gatilho secreto aparece na entrada. O gatilho pode ser uma frase rara, uma sequência de tokens ou um padrão de marca d'água.

Exemplo: um modelo de conclusão de código ajustado com dados envenenados se comporta corretamente até que um comentário mágico apareça e, então, gera código inseguro. As portas dos fundos são discretas porque as avaliações padrão parecem normais.

Defesas: obtenha modelos apenas de provedores confiáveis que assinem seus modelos; execute detecção de gatilhos e análises de anomalias; faça o ajuste fino com dados verificados sob seu controle.

Os pesos do modelo não são apenas dados; alguns formatos executam código ao serem carregados. O pickle do Python (usado em arquivos .bin e .pt mais antigos do PyTorch) pode executar código arbitrário durante a desserialização.

Carregar um modelo serializado com pickle que não é confiável equivale a executar um programa não confiável.

• Dê preferência a safetensors, que armazena apenas tensores e não pode executar código.
• Analise ou execute em um ambiente isolado qualquer arquivo pickle que precise carregar.
• Trate os arquivos de modelo de repositórios públicos como binários não confiáveis.

Estabeleça a origem de cada artefato e confirme que ele não foi adulterado.

• Fixe versões e revisões exatas do modelo e do conjunto de dados; nunca use latest.
• Verifique somas de verificação ou hashes em relação a um valor conhecido como correto.
• Dê preferência a artefatos assinados; verifique as assinaturas quando o editor as fornecer.
• Mantenha uma BOM de aprendizado de máquina (lista de materiais) que registre os modelos, os conjuntos de dados e suas fontes.

Os modelos podem memorizar e posteriormente reproduzir partes dos dados de treinamento, incluindo segredos, PII ou textos protegidos por direitos autorais. Os invasores usam ataques de extração para induzir a divulgação desse conteúdo.

• Remova PII e segredos dos corpora de treinamento e de ajuste fino.
• Aplique deduplicação; a memorização se correlaciona com amostras repetidas.
• Considere técnicas de privacidade diferencial para conjuntos de dados sensíveis.
• Teste os modelos com sondas de extração antes da publicação.

Dois ataques de privacidade têm como alvo modelos implantados:

• Inferência de associação: determinar se um registro específico estava no conjunto de treinamento. Isso por si só pode constituir uma violação de privacidade (por exemplo, em um conjunto de dados médicos).
• Inversão de modelo: reconstruir entradas de treinamento representativas a partir do comportamento ou das representações vetoriais do modelo.

Mitigue o risco limitando a exposição das pontuações de confiança, adicionando regularização ou privacidade diferencial e restringindo o acesso irrestrito a consultas de modelos de alto valor.

Os sistemas RAG armazenam representações vetoriais de documentos em um banco de dados vetorial. Elas trazem riscos próprios:

• Inversão de representações vetoriais: as representações podem vazar informações suficientes para reconstruir parcialmente o texto de origem, portanto são dados sensíveis.
• Vazamento entre locatários: a recuperação sem controle de acesso pode expor documentos de outro locatário.
• Envenenamento do índice: um documento malicioso adicionado ao índice pode sequestrar recuperações posteriores (injeção indireta).

Aplique o controle de acesso no momento da recuperação e verifique os documentos antes de indexá-los.

Além dos modelos, as aplicações de LLM dependem da cadeia usual de fornecimento de software, além de plug-ins e conectores que concedem novos recursos ao modelo.

• Um plug-in malicioso ou comprometido pode ler o contexto e extrair dados.
• Pacotes PyPI/npm com nomes falsificados por erros tipográficos ou sequestrados podem inserir uma porta dos fundos na aplicação.
• Dependências transitivas vulneráveis ampliam a superfície de ataque.

Use arquivos de bloqueio, analise com ferramentas de SCA, revise as permissões dos plug-ins e dê preferência a fontes verificadas e assinadas.

Trate o fluxo de aprendizado de máquina como qualquer outro caminho de CI/CD de produção, com controles robustos:

• isole os ambientes de treinamento e de ajuste fino; restrinja quem pode enviar dados.
• Assine e verifique os artefatos em cada etapa; rejeite os que não tiverem assinatura ou forem incompatíveis.
• Valide os conjuntos de dados com detecção de anomalias e verificações de proveniência.
• Monitore continuamente os modelos implantados quanto à deriva e ao comportamento inesperado.

Estruturas como o MITRE ATLAS e o RMF de IA do NIST ajudam a estruturar esses controles.

A segurança de modelos, dados e da cadeia de fornecimento trata de confiança e verificação em todo o ciclo de vida:

• Conheça suas fontes (proveniência, assinaturas, BOM de aprendizado de máquina).
• Trate pesos e conjuntos de dados como potencialmente hostis até que sejam verificados.
• Proteja a privacidade contra vazamentos, inferências e inversões.
• Restrinja dependências, plug-ins e armazenamentos vetoriais.

O lugar mais barato para interromper um artefato envenenado é antes que ele entre no seu fluxo.

Teste sua compreensão da segurança da cadeia de fornecimento de modelos.

Riscos de modelos, dados e da cadeia de fornecimento:

• A cadeia de fornecimento do aprendizado de máquina abrange modelos-base, ajustes finos, conjuntos de dados, representações vetoriais, plug-ins e dependências.
• O envenenamento e as portas dos fundos corrompem o treinamento; verifique e assine as fontes de dados.
• Evite formatos pickle inseguros; dê preferência a safetensors para pesos não confiáveis.
• Verifique a proveniência com versões, somas de verificação, assinaturas e uma BOM de aprendizado de máquina.
• Proteja a privacidade contra vazamentos, inferência de associação e inversão; proteja as representações vetoriais e os armazenamentos vetoriais.
• Restrinja dependências e plug-ins; proteja o fluxo de ponta a ponta usando ATLAS e o RMF de IA do NIST como guias.