O que é envenenamento de dados?

Toda equipe de segurança é treinada para monitorar o código durante o seu desenvolvimento. Quase nenhuma é treinada para monitorar os dados durante a sua chegada, e esse ponto cego é exatamente o que o envenenamento de dados explora. Quando um modelo envenenado chega à produção, a vulnerabilidade nunca foi mencionada na revisão de código. Ela estava em um conjunto de dados que ninguém auditou meses antes.

Este verbete do glossário explica o que é envenenamento de dados, como os ataques de envenenamento de dados acontecem na prática e por que o envenenamento de dados por IA se tornou uma das principais ameaças. Riscos de crescimento mais rápido na era da IA SDLCE como seria uma defesa real contra isso.

Significado de envenenamento de dados #

O envenenamento de dados é a manipulação deliberada dos dados usados ​​para treinar, ajustar ou fundamentar um modelo de IA, de modo que o modelo aprenda informações incorretas, se comporte da maneira desejada pelo atacante ou vaze informações que jamais deveria expor. Em vez de atacar o modelo após a implantação, o atacante ataca a matéria-prima a partir da qual o modelo é construído.

A ideia central por trás do envenenamento de dados é simples e perturbadora: um modelo de IA é tão confiável quanto os dados com os quais aprendeu. Se esses dados estiverem corrompidos, tendenciosos ou cheios de armadilhas antes mesmo do início do treinamento, nenhuma revisão de código, teste ou monitoramento em tempo de execução posterior detectará a falha subjacente, porque o modelo estará funcionando exatamente como foi (maliciosamente) programado para funcionar.

Envenenamento de dados por IA versus vulnerabilidades de software tradicionais #

A segurança tradicional de aplicações parte do pressuposto de que o perigo reside no código: uma função defeituosa, uma biblioteca sem patches, um servidor mal configurado. O envenenamento de dados por IA quebra completamente essa premissa. Não há uma linha de código vulnerável a ser encontrada, porque a corrupção ocorreu em um conjunto de treinamento, um conjunto de dados de ajuste fino ou um índice de recuperação, muito antes de qualquer código ser escrito ou qualquer modelo ser implantado.

É por isso que o envenenamento de dados por IA é particularmente difícil de detectar com ferramentas tradicionais. SAST Um scanner lê o código. Um scanner de dependências lê os manifestos dos pacotes. Nenhum deles lê um corpus de treinamento de vários gigabytes ou um banco de dados vetorial cheio de documentos incorporados, o que é pré-cisÉ justamente onde o envenenamento de dados por IA causa danos. Pesquisadores de segurança e divulgam informações de forma responsável. Outros são encontrados e usados ​​como armas por atacantes primeiro, o que é o cenário que causa mais danos.

Como funcionam, na prática, os ataques de envenenamento de dados? #

Os ataques de envenenamento de dados geralmente assumem uma das seguintes formas:

• Envenenamento de dados de treinamentoUm atacante insere exemplos manipulados, rotulados incorretamente ou maliciosos no conjunto de dados usado para treinar um modelo do zero ou ajustar um modelo existente, fazendo com que ele aprenda um viés oculto ou um comportamento de backdoor.
• Inversão de rótulosUma versão mais sutil do método acima, onde um atacante altera apenas os rótulos em um pequeno subconjunto de exemplos de treinamento, distorcendo silenciosamente o que o modelo aprende a associar a quê.
• RAG e envenenamento contextualEm sistemas de geração aumentada por recuperação, um atacante insere documentos adulterados na base de conhecimento ou no repositório de vetores do qual o modelo recupera informações em tempo de execução, de modo que o modelo repita com confiança informações falsas ou manipuladas como se fossem fatos verificados.
• Gatilhos de backdoor: um atacante incorpora um padrão específico nos dados de treinamento de forma que o modelo se comporte normalmente em quase todos os casos, mas produza a saída escolhida pelo atacante no momento em que uma frase ou entrada de gatilho oculta aparecer.
• Envenenamento da cadeia de suprimentos: um invasor compromete um conjunto de dados público ou compartilhado, um ponto de verificação de modelo pré-treinado ou uma incorporação pipeline a montante, de forma que todas as equipes a jusante que utilizam essa técnica herdem o veneno sem nunca tocar no ataque original.

O que une todos esses ataques de envenenamento de dados é o momento em que ocorrem. O dano é causado antes mesmo que o modelo responda a um usuário real, e é exatamente por isso que a frase "antes mesmo de escrever uma linha de código" descreve tão bem essa ameaça.cisely: o modelo está comprometido em sua base, não em seu resultado.

Como os atacantes corrompem um modelo de IA antes mesmo que ele escreva uma linha de código? #

Todos os ataques de envenenamento de dados descritos acima compartilham a mesma vantagem temporal: a invasão ocorre a montante, muito antes de um modelo gerar qualquer resultado que o usuário vá ver. Não há função vulnerável para corrigir nem nenhum ataque malicioso. commit É preciso verificar isso na revisão, pois o modelo ainda não escreveu nada. Ele apenas aprendeu, e o que aprendeu já está errado.

É isso que torna o envenenamento de dados por IA fundamentalmente diferente das vulnerabilidades que as equipes de segurança de aplicativos são treinadas para detectar. Um modelo com backdoor parece idêntico a um modelo limpo em uma comparação de código. Ele passa despercebido. pull request revisão. Compila, implementa e responde à maioria das consultas corretamente, até o momento em que a condição específica plantada por um invasor finalmente aparece em produção. Nesse ponto, a questão não é mais "qual código introduziu isso", mas sim "quais dados fizeram isso e até que ponto isso remonta?".

Por que o envenenamento de dados por IA é uma prioridade crescente? #

O envenenamento de dados por IA deixou de ser uma preocupação teórica. É formalmente reconhecido como um fenômeno real. LLM04: Envenenamento de Dados e Modelos Na lista OWASP Top 10 para aplicações LLM, figurando ao lado de injeção imediata e riscos na cadeia de suprimentos como uma das principais ameaças da era da IA ​​generativa. Três tendências estão elevando o seu status de prioridade para todas as equipes de segurança:

• O dano é invisível até ser acionado. Um modelo envenenado pode passar em todos os testes funcionais e comportar-se perfeitamente durante meses, até que a condição específica que o atacante plantou finalmente apareça em produção.

• A geração aumentada por recuperação está em toda parte. Qualquer sistema que permita a um modelo extrair contexto em tempo real de documentos, wikis, tickets ou um banco de dados vetorial possui uma nova superfície de entrada não auditada, e essa superfície é exatamente o alvo de ataques de envenenamento de dados.

• Os conjuntos de dados agora são ativos da cadeia de suprimentos. As equipes rotineiramente extraem modelos pré-treinados, embeddings e conjuntos de dados públicos de fontes externas da mesma forma que extraem pacotes de código aberto e, assim como um pacote comprometido, um conjunto de dados comprometido pode levar o ataque silenciosamente a todas as equipes que o utilizam.

Detecção e defesa contra envenenamento de dados #

Como o envenenamento de dados ocorre antes do próprio modelo, a defesa também precisa começar antes:

• Fique atento a fontes de dados anômalas, não apenas a códigos anômalos. A detecção de comportamentos e anomalias precisa ser estendida até o ponto de entrada dos dados. pipeline, não pare no limite do repositório.

• Conheça todos os conjuntos de dados no pipeline. Não é possível auditar o risco de contaminação em um conjunto de dados cuja existência você desconhece. A descoberta contínua de conjuntos de dados para treinamento, avaliação e recuperação é a primeira linha de defesa.

• Rastreie a linhagem desde o conjunto de dados até o modelo e, finalmente, ao resultado. Mapear o caminho que um conjunto de dados percorre até chegar a um modelo, e de um modelo até um agente, um ponto final ou uma ferramenta de codificação, é o que transforma "obtivemos uma saída ruim" em "sabemos exatamente qual conjunto de dados a originou".

• Analise criteriosamente as fontes de recuperação de dados, e não apenas os conjuntos de treinamento. Em sistemas RAG, o armazenamento de vetores e a base de conhecimento precisam das mesmas verificações de integridade que os dados de treinamento, uma vez que o envenenamento de contexto ocorre no momento da consulta, e não no momento do treinamento.

Como a Xygeni ajuda a reduzir a lacuna no combate ao envenenamento de dados? #

A defesa contra o envenenamento de dados começa com a visibilidade que a maioria das organizações simplesmente não possui. Xygeni'O Inventário de IA descobre continuamente todos os ativos de IA em todo o sistema. SDLC, incluindo os conjuntos de dados subjacentes: dados de treinamento, conjuntos de avaliação e fontes RAG ou de recuperação, e os mapeia em um grafo de relacionamento dinâmico que vai do conjunto de dados ao modelo e ao ponto final. do agente para o servidor MCP para ferramenta de codificação. Esse gráfico é o que transforma a saída suspeita de um modelo em uma questão rastreável: qual conjunto de dados a alimentou e de onde ela veio.

Além desse estoque, o de Xygeni Segurança AI Detecta vulnerabilidades em vetores e incorporações, incluindo contexto comprometido na recuperação e no RAG. pipelines, alinhado ao OWASP Top 10 para candidaturas a mestrado em Direito (LLM). Em vez de presumir que as fontes de treinamento e recuperação de um modelo sejam limpas, o Xygeni as trata como parte da superfície de ataque, da mesma forma que já trata o código, as dependências e pipelineSe você não consegue responder atualmente à pergunta “quais dados treinaram este modelo e podemos provar isso?”, essa é exatamente a lacuna que precisa ser preenchida antes que um incidente de envenenamento de dados de IA force a pergunta.

Perguntas frequentes #