Skip to content

Commit 5181ed2

Browse files
authored
Merge pull request #499 from emmanuelgjr/patch-39
Update and rename LLM03_SupplyChain.md to LLM03_CadeiadeSuprimentos.md
2 parents c36e1ad + b27e031 commit 5181ed2

File tree

2 files changed

+95
-98
lines changed

2 files changed

+95
-98
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
## LLM03:2025 Cadeia de Suprimentos
2+
3+
### Descrição
4+
5+
As cadeias de suprimentos de LLMs são suscetíveis a várias vulnerabilidades, que podem afetar a integridade dos dados de treinamento, dos modelos e das plataformas de implantação. Esses riscos podem resultar em saídas tendenciosas, violações de segurança ou falhas no sistema. Enquanto as vulnerabilidades tradicionais de software focam em questões como falhas de código e dependências, em aprendizado de máquina, os riscos também se estendem a modelos pré-treinados e dados de terceiros.
6+
7+
Esses elementos externos podem ser manipulados por meio de ataques de adulteração ou envenenamento.
8+
9+
A criação de LLMs é uma tarefa especializada que frequentemente depende de modelos de terceiros. O surgimento de LLMs de acesso aberto e novos métodos de ajuste fino, como "LoRA" (Adaptação de Baixa Dimensão) e "PEFT" (Ajuste Fino com Eficiência de Parâmetros), especialmente em plataformas como Hugging Face, introduzem novos riscos à cadeia de suprimentos. Finalmente, o surgimento de LLMs em dispositivos aumenta a superfície de ataque e os riscos na cadeia de suprimentos para aplicações de LLM.
10+
11+
Alguns dos riscos discutidos aqui também são abordados em "LLM04 Data and Model Poisoning". Esta entrada foca no aspecto da cadeia de suprimentos desses riscos. Um modelo de ameaça simples pode ser encontrado [aqui](https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png).
12+
13+
### Exemplos Comuns de Riscos
14+
15+
#### 1. Vulnerabilidades Tradicionais de Pacotes de Terceiros
16+
Como componentes desatualizados ou obsoletos, que os atacantes podem explorar para comprometer aplicações de LLM. Isso é semelhante a "A06:2021 – Componentes Vulneráveis e Desatualizados," com riscos aumentados quando os componentes são usados durante o desenvolvimento ou ajuste fino do modelo.
17+
(Ref. link: [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/))
18+
#### 2. Riscos de Licenciamento
19+
O desenvolvimento de IA frequentemente envolve diferentes licenças de software e conjuntos de dados, criando riscos se não forem gerenciados adequadamente. Licenças abertas e proprietárias impõem diferentes requisitos legais. Licenças de conjuntos de dados podem restringir uso, distribuição ou comercialização.
20+
#### 3. Modelos Desatualizados ou Obsoletos
21+
Usar modelos desatualizados ou obsoletos que não são mais mantidos leva a problemas de segurança.
22+
#### 4. Modelo Pré-treinado Vulnerável
23+
Modelos são caixas-pretas binárias e, ao contrário de código aberto, a inspeção estática oferece poucas garantias de segurança. Modelos pré-treinados vulneráveis podem conter vieses ocultos, backdoors ou outras funcionalidades maliciosas que não foram identificadas nas avaliações de segurança dos repositórios de modelos. Modelos vulneráveis podem ser criados tanto por conjuntos de dados envenenados quanto por adulteração direta do modelo usando técnicas como ROME, também conhecida como "lobotomização."
24+
#### 5. Proveniência Fraca do Modelo
25+
Atualmente, não há garantias fortes de proveniência em modelos publicados. Cartões de Modelo e documentação associada fornecem informações sobre os modelos e são confiáveis pelos usuários, mas não oferecem garantias sobre a origem do modelo. Um atacante pode comprometer a conta de um fornecedor em um repositório de modelos ou criar uma conta semelhante e usar técnicas de engenharia social para comprometer a cadeia de suprimentos de uma aplicação de LLM.
26+
#### 6. Adaptadores LoRA Vulneráveis
27+
LoRA é uma técnica popular de ajuste fino que aumenta a modularidade permitindo que camadas pré-treinadas sejam acopladas a um LLM existente. Embora eficiente, essa abordagem cria novos riscos, onde um adaptador LoRA malicioso compromete a integridade e a segurança do modelo base pré-treinado. Isso pode ocorrer tanto em ambientes colaborativos quanto explorando plataformas populares de implantação de inferência, como vLLM e OpenLLM, que suportam adaptadores LoRA.
28+
#### 7. Exploração de Processos de Desenvolvimento Colaborativo
29+
O desenvolvimento colaborativo de modelos e os serviços de manipulação de modelos (e.g., conversões) hospedados em ambientes compartilhados podem ser explorados para introduzir vulnerabilidades em modelos compartilhados. Por exemplo, a fusão de modelos é popular no Hugging Face, com modelos combinados liderando o ranking do OpenLLM, mas pode ser explorada para burlar revisões.
30+
#### 8. Vulnerabilidades na Cadeia de Suprimentos de Modelos em Dispositivos
31+
Modelos de LLM em dispositivos aumentam a superfície de ataque com processos de fabricação comprometidos e exploração de vulnerabilidades no sistema operacional ou firmware do dispositivo para comprometer os modelos. Atacantes podem fazer engenharia reversa e reempacotar aplicações com modelos adulterados.
32+
#### 9. Termos e Condições e Políticas de Privacidade Ambíguos
33+
Termos e Condições (T&Cs) e políticas de privacidade pouco claros dos operadores de modelos podem levar à utilização de dados sensíveis da aplicação para treinamento do modelo, expondo informações confidenciais.
34+
35+
### Estratégias de Prevenção e Mitigação
36+
37+
1. Avalie cuidadosamente fontes de dados e fornecedores, incluindo T&Cs e suas políticas de privacidade, usando apenas fornecedores confiáveis. Revise e audite regularmente a segurança e o acesso do fornecedor, garantindo que não haja mudanças em sua postura de segurança ou T&Cs.
38+
2. Entenda e aplique as mitigações encontradas no "OWASP Top Ten's A06:2021 – Componentes Vulneráveis e Desatualizados." Isso inclui varreduras de vulnerabilidade, gerenciamento e correção de componentes. Para ambientes de desenvolvimento com acesso a dados sensíveis, aplique esses controles também nesses ambientes.
39+
(Ref. link: [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/))
40+
3. Realize avaliações extensivas com equipes vermelhas de IA ao selecionar um modelo de terceiros. Use benchmarks confiáveis de IA, como o Decoding Trust, para avaliar a confiabilidade dos modelos.
41+
4. Mantenha um inventário atualizado de componentes usando um Software Bill of Materials (SBOM) para garantir uma lista precisa e assinada, prevenindo adulterações em pacotes implantados. SBOMs podem detectar e alertar rapidamente sobre novas vulnerabilidades de dia zero.
42+
5. Para mitigar riscos de licenciamento, crie um inventário de todos os tipos de licenças envolvidos usando SBOMs e conduza auditorias regulares, garantindo conformidade e transparência.
43+
6. Use modelos de fontes verificáveis e realize verificações de integridade de modelos com assinatura e hashes de arquivos para compensar a falta de proveniência robusta. Da mesma forma, use assinatura de código para códigos fornecidos externamente.
44+
7. Implemente práticas rigorosas de monitoramento e auditoria para ambientes colaborativos de desenvolvimento de modelos.
45+
8. Testes de robustez contra adversários e detecção de anomalias em modelos e dados fornecidos podem ajudar a detectar adulterações e envenenamentos, como discutido em "LLM04 Data and Model Poisoning."
46+
9. Implemente uma política de correção para mitigar componentes vulneráveis ou desatualizados. Certifique-se de que a aplicação depende de uma versão mantida de APIs e modelos subjacentes.
47+
10. Encripte modelos implantados na borda de IA com verificações de integridade e use APIs de atestação de fornecedores para prevenir aplicativos adulterados e modelos não reconhecidos.
48+
49+
### Cenários de Ataques Exemplares
50+
51+
#### Cenário #1: Biblioteca Python Vulnerável
52+
Um atacante explora uma biblioteca Python vulnerável para comprometer um aplicativo LLM. Isso aconteceu na primeira violação de dados da OpenAI.
53+
#### Cenário #2: Adulteração Direta
54+
Um atacante adultera diretamente um modelo para disseminar desinformação. Este ataque real é exemplificado pelo PoisonGPT.
55+
#### Cenário #3: Ajuste Fino de Modelo Popular
56+
Um atacante ajusta fino um modelo popular de acesso aberto para remover recursos de segurança importantes, implantando-o em plataformas confiáveis.
57+
#### Cenário #4: Modelos Pré-Treinados
58+
Um sistema LLM implanta modelos pré-treinados de um repositório amplamente usado sem verificação detalhada, introduzindo vieses e resultados manipulados.
59+
#### Cenário #5: Fornecedor Comprometido
60+
Um fornecedor comprometido fornece um adaptador LoRA vulnerável que é integrado a um modelo LLM.
61+
#### Cenário #6: Infiltração de Fornecedor
62+
Um atacante compromete a produção de um adaptador LoRA integrado a um LLM implantado em dispositivos.
63+
#### Cenário #7: Ataques CloudBorne e CloudJacking
64+
Esses ataques visam infraestruturas em nuvem, comprometendo instâncias virtuais e ambientes compartilhados.
65+
#### Cenário #8: LeftOvers (CVE-2023-4969)
66+
Um ataque que explora memória local de GPUs para recuperar dados sensíveis.
67+
#### Cenário #9: WizardLM
68+
Um modelo falso com o mesmo nome é publicado contendo malware e backdoors.
69+
#### Cenário #10: Serviço de Conversão de Formato de Modelo
70+
Um atacante usa serviços de manipulação de modelos para comprometer um modelo disponível publicamente.
71+
#### Cenário #11: Engenharia Reversa de Aplicativos Móveis
72+
Um atacante substitui o modelo de um aplicativo por uma versão adulterada, conduzindo usuários a sites fraudulentos.
73+
#### Cenário #12: Envenenamento de Conjuntos de Dados
74+
Um atacante adultera conjuntos de dados públicos para criar backdoors em modelos ajustados finos.
75+
#### Cenário #13: Termos e Condições e Política de Privacidade
76+
Alterações nos T&Cs e políticas de privacidade levam ao uso de dados sensíveis da aplicação no treinamento do modelo.
77+
78+
### Links de Referência
79+
80+
1. [PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news)
81+
2. [Large Language Models On-Device with MediaPipe and TensorFlow Lite](https://developers.googleblog.com/en/large-language-models-on-device-with-mediapipe-and-tensorflow-lite/)
82+
3. [Hijacking Safetensors Conversion on Hugging Face](https://hiddenlayer.com/research/silent-sabotage/)
83+
4. [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010)
84+
5. [Using LoRA Adapters with vLLM](https://docs.vllm.ai/en/latest/models/lora.html)
85+
6. [Removing RLHF Protections in GPT-4 via Fine-Tuning](https://arxiv.org/pdf/2311.05553)
86+
7. [Model Merging with PEFT](https://huggingface.co/blog/peft_merging)
87+
8. [HuggingFace SF_Convertbot Scanner](https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163)
88+
9. [Thousands of servers hacked due to insecurely deployed Ray AI framework](https://www.csoonline.com/article/2075540/thousands-of-servers-hacked-due-to-insecurely-deployed-ray-ai-framework.html)
89+
10. [LeftoverLocals: Listening to LLM responses through leaked GPU local memory](https://blog.trailofbits.com/2024/01/16/leftoverlocals-listening-to-llm-responses-through-leaked-gpu-local-memory/)
90+
91+
### Frameworks e Taxonomias Relacionados
92+
93+
Consulte esta seção para informações abrangentes, cenários e estratégias relacionados à implantação de infraestrutura, controles no ambiente aplicado e outras melhores práticas.
94+
95+
- [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010) - **MITRE ATLAS**

0 commit comments

Comments
 (0)