Segurança da cadeia de suprimentos de IA: como defender a pilha de IA

A segurança da cadeia de suprimentos de IA é a prática de proteger todos os componentes externos dos quais um sistema de IA depende, desde conjuntos de dados de treinamento e modelos pré-treinados até os pacotes, pipelines de compilação, gateways e fornecedores que os integram.

O motivo de isso exigir atenção agora resume-se à alavancagem. Um invasor que corrompe um componente upstream atinge milhares de ambientes downstream de uma só vez, aproveitando os canais de distribuição nos quais todo sistema de compilação confia por padrão. Envenenar um único artefato supera milhares de invasões diretas e custa menos ao atacante.

Março de 2026 provou essa lógica. Um pacote de gateway de IA comprometido, ingerido automaticamente por sistemas de compilação, resultou em uma exposição potencial em mais de 2.500 organizações e aproximadamente 434.000 pipelines de CI/CD antes de ser detectado. Inteligência de Ameaças da CloudSEK reconstruiu a exposição total das vítimas daquela campanha, e a seção de anatomia abaixo baseia-se nessa reconstrução. Ameaças como essa abrangem toda a pilha de IA, antes e depois da implantação, onde artefatos opacos, junções expostas e pipelines automatizados se encontram.

Como a Cadeia de Suprimentos de IA Difere da Cadeia de Suprimentos de Software

As cadeias de suprimentos de IA diferem das de software em 5 dimensões: ativo principal, inspecionabilidade, gatilho de execução, maturidade de procedência e amplitude da superfície. Os invasores exploram todas as 5, e os controles projetados para código-fonte não detectam nenhuma delas com eficácia.

A opacidade traz uma consequência que as outras dimensões não possuem. Um conjunto de dados envenenado ou um arquivo de pesos adulterado comporta-se normalmente durante os testes e ativa-se apenas sob condições escolhidas pelo invasor, por isso a verificação de código convencional não o detecta. Um ataque à cadeia de suprimentos contra componentes de IA herda todas as técnicas de software e adiciona esses pontos cegos.

Componentes da Cadeia de Suprimentos de IA

Uma cadeia de suprimentos de IA corporativa contém 4 camadas: a camada de dados, a camada de modelo, a camada de ferramentas e a camada de junção de tempo de execução. Cada camada importa confiança de fora da organização.

• Camada de dados: Conjuntos de dados de treinamento, corpora de ajuste fino, serviços de rotulagem e as fontes de recuperação que alimentam pipelines de RAG (geração aumentada por recuperação). Registros envenenados nesta camada incorporam comportamentos que só aparecem após a implantação.
• Camada de modelo: Modelos base, pontos de verificação de ajuste fino, adaptadores e os hubs públicos que os distribuem. Um arquivo de pesos adulterado envia um backdoor dentro de um ativo que nenhum revisor lê linha por linha.
• Camada de ferramentas: Frameworks de aprendizado de máquina, pacotes Python, imagens de contêiner, plataformas MLOps e os pipelines de CI/CD (integração contínua e entrega contínua) que os montam. O comprometimento aqui se espalha na velocidade da compilação.
• Camada de junção de tempo de execução: Gateways de IA, APIs de serviço de modelo, servidores MCP (Protocolo de Contexto de Modelo), tempos de execução de agentes e bancos de dados vetoriais. Um ativo de junção detém credenciais para modelos, armazenamentos de dados e ferramentas internas simultaneamente.

Os ativos de junção concentram o risco. Um gateway de IA ou tempo de execução de agente situa-se entre dados sensíveis e sistemas que agem autonomamente; portanto, o controle de uma junção expõe identidades ao redor e fornece aos invasores um vetor de acesso inicial a tudo o que a junção toca.

Entendendo os Ataques à Cadeia de Suprimentos de IA: 6 Estágios Principais

Os ataques à cadeia de suprimentos de IA ocorrem em 6 estágios sequenciais, desde o comprometimento upstream até a reutilização de credenciais downstream. Incidentes recentes, desde a confusão de dependências do PyTorch em 2022 até o comprometimento do LiteLLM em 2026, seguiram essas etapas em ordem.

1. Comprometimento upstream 

Os atacantes assumem o controle de uma conta de mantenedor, um token de automação ou um sistema de build por trás de um componente confiável. Uma única credencial obsoleta concede controle sobre softwares que milhares de organizações utilizam.

2. Publicação de artefato envenenado 

Os atacantes enviam uma versão maliciosa de pacote, checkpoint de modelo ou revisão de conjunto de dados através de canais de lançamento legítimos. Fluxos de trabalho de assinatura autênticos fazem com que o artefato envenenado pareça confiável.

3. Ingestão automatizada

Resolvedores de dependências, tarefas de CI/CD agendadas e downloads de modelos copiam o artefato minutos após a publicação. A automação comprime uma janela de publicação curta em uma distribuição ampla.

4. Execução e coleta de segredos

Hooks de tempo de instalação ou desserialização de tempo de carregamento executam o código do atacante dentro do ambiente da vítima. O código coleta todas as credenciais visíveis ao processo, incluindo variáveis de ambiente, arquivos de credenciais e respostas de metadados de nuvem.

5. Expansão de privilégios

Tokens roubados abrem contas em nuvem, repositórios de código-fonte, registros de contêineres, tenants de SaaS (software como serviço) e provedores de IA. O acesso se espalha por sistemas que o pacote original nunca tocou.

6. Persistência e reutilização

Os atacantes vendem, negociam ou utilizam credenciais coletadas semanas após o artefato desaparecer. A remoção do pacote fecha o ponto de entrada, mas não encerra o incidente.

O estágio 4 marca a transição de um problema de software para uma violação corporativa, pois as credenciais sobrevivem ao código que as roubou.

Tipos de ataques à cadeia de suprimentos de IA

Sete tipos de ataques dominam o cenário de ameaças à cadeia de suprimentos de IA: envenenamento de conjuntos de dados, modelos maliciosos, comprometimento de dependências, comprometimento de pipelines, comprometimento de ferramentas, exploração de frameworks e comprometimento de serviços de IA de terceiros. Cada tipo já produziu pelo menos um incidente documentado.

1. Envenenamento de conjuntos de dados

O envenenamento de conjuntos de dados insere registros manipulados em dados de treinamento ou ajuste fino para que o modelo final apresente comportamentos ocultos. Em 2023, a demonstração de pesquisa PoisonGPT alterou um modelo GPT-J de código aberto para gerar declarações falsas direcionadas, enquanto passava em benchmarks padrão. Fontes de recuperação envenenadas estendem a técnica para pipelines de RAG, onde documentos corrompidos direcionam as respostas do modelo no momento da consulta.

2. Modelos maliciosos em hubs públicos

Pesquisadores da JFrog identificaram cerca de 100 modelos maliciosos no Hugging Face em 2024, vários abrindo reverse shells no momento em que a vítima os carregava. O mecanismo de entrega é o pickle, o formato de serialização Python por trás de muitos arquivos de modelo, e o pickle executa instruções incorporadas durante a desserialização. Um download de modelo rotineiro torna-se execução de código, sem necessidade de exploit.

3. Comprometimento de Dependências e Typosquatting

O comprometimento de dependências insere código hostil dentro dos pacotes que projetos de IA importam. Em dezembro de 2022, a compilação noturna do PyTorch baixou um pacote malicioso chamado torchtriton por meio de confusão de dependências, uma técnica que engana os resolvedores para que busquem um impostor público no lugar de um pacote interno privado.

A investigação TXTBOOK da CloudSEK rastreou 993 pacotes npm que reproduziam o namespace privado de um banco, a mesma técnica de confusão voltada para compilações corporativas. O typosquatting registra nomes de pacotes quase idênticos para capturar instalações digitadas incorretamente. O slopsquatting, uma variante mais recente, registra nomes que assistentes de codificação de IA alucinam e aguarda que os desenvolvedores instalem a dependência fabricada.

4. Comprometimento de Pipeline de Build e CI/CD

O comprometimento do pipeline de build tem como alvo a automação que monta o software de IA. Os atacantes envenenaram as versões do Ultralytics YOLO em dezembro de 2024 ao abusar de um fluxo de trabalho do GitHub Actions, enviando código de mineração de criptomoedas para o PyPI através do próprio pipeline do projeto. Os executores possuem privilégios amplos e instalam dependências sem revisão humana, portanto, um fluxo de trabalho sequestrado contamina todos os artefatos que produz.

5. Comprometimento de Ferramentas de Desenvolvimento e Segurança

O comprometimento de ferramentas transforma em armas os utilitários em que as equipes de engenharia confiam por padrão, incluindo scanners, analisadores de código e SDKs (kits de desenvolvimento de software).

Durante a campanha TeamPCP de 2026, o grupo de ameaças transformou em armas ferramentas confiáveis de segurança e desenvolvimento, incluindo o scanner Trivy e o Checkmarx KICS, transformando softwares de segurança em um canal de roubo de credenciais em pipelines corporativos. Ferramentas confiáveis recebem acesso elevado por design. Um scanner comprometido herda todas as permissões que a equipe de segurança lhe concedeu.

6. Exploração de Frameworks e Gateways de IA

A exploração de frameworks abusa de vulnerabilidades na camada de serviço que executa modelos em produção. A campanha ShadowRay explorou a vulnerabilidade CVE-2023-48022 no framework Ray para sequestrar clusters de GPU (unidade de processamento gráfico) e roubar credenciais de carga de trabalho de implantações expostas. Gateways de IA situam-se um nível acima na pilha, e uma versão de gateway envenenada atinge todas as aplicações roteadas através dele.

7. Comprometimento de Serviços de IA de Terceiros

O comprometimento de serviços chega às empresas através dos produtos de IA SaaS e APIs de provedores de modelos que elas assinam. Um fornecedor de IA violado expõe os prompts, fontes de dados conectadas e credenciais armazenadas de cada locatário em um único evento. A concentração de fornecedores aprofunda a exposição, porque milhares de organizações roteiam cargas de trabalho sensíveis através de um punhado de plataformas de IA compartilhadas.

Por dentro do ataque ao LiteLLM: Anatomia de uma violação da cadeia de suprimentos de IA em 2026

Em março de 2026, o grupo de ameaças TeamPCP comprometeu o LiteLLM, um gateway de IA de código aberto que roteia o tráfego de aplicações para provedores de modelos. A CloudSEK avalia a campanha como o maior ataque à cadeia de suprimentos na infraestrutura de IA identificado em 2026.

A entrada ocorreu um nível acima na cadeia. Um token de automação vazado para o scanner Trivy foi rotacionado, mas nunca totalmente revogado, o que deu aos atacantes uma janela de aproximadamente 20 dias para sobrescrever as tags de versão publicadas do scanner. O pipeline de build do LiteLLM instalou o Trivy sem fixação de versão, então o scanner envenenado fluiu para o build automaticamente e publicou as versões maliciosas 1.82.7 e 1.82.8 do LiteLLM no PyPI. O vetor de acesso inicial foi um scanner de segurança: a ferramenta que as organizações executam para detectar riscos na cadeia de suprimentos acabou por entregá-los.

Ambas as versões permaneceram ativas por cerca de 40 minutos. A execução não exigiu nenhuma instrução de importação: um arquivo .pth malicioso, um arquivo de configuração de caminho do Python que é executado na inicialização do interpretador, foi acionado onde quer que o pacote fosse simplesmente instalado, contornando a proteção --ignore-scripts na qual as ferramentas de instalação confiam.

Em cada runner comprometido, um ladrão de credenciais rastreado como SANDCLOCK escalou privilégios e coletou 5 categorias de segredos:

• Chaves SSH (secure shell) e tokens de implantação de repositório
• Credenciais da AWS, Google Cloud e Microsoft Azure lidas a partir de serviços de metadados de instância
• Tokens de conta de serviço do Kubernetes
• Segredos de CI/CD extraídos da memória do processo, onde a mascaramento do GitHub Actions não oferece proteção
• Chaves de API de LLM (modelo de linguagem grande) e configuração de gateway

Quando a exfiltração para a infraestrutura do atacante falhava, o malware criava repositórios públicos chamados tpcp-docs ou docs-tpcp dentro das próprias contas do GitHub das vítimas e carregava os dados roubados como ativos de lançamento. As organizações afetadas estavam expondo seus próprios segredos publicamente sem saber.

O conjunto de dados de exposição reconstruído apresenta correspondências de alta confiança em empresas como Cisco, S&P Global, Siemens e Deloitte, e a abrangência alcançou organizações indianas também, abrangendo fintechs, manufatura, SaaS e uma entidade governamental estadual. Números desse tipo descrevem uma exposição potencial, não um comprometimento confirmado, e cada correspondência justifica validação privada, rotação de credenciais e investigação de logs.

A presença importou mais do que a escolha. O LiteLLM chega como uma dependência transitiva de frameworks de agentes e ferramentas de orquestração, portanto, uma parte dos pipelines expostos o instalou sem que nenhum engenheiro o tivesse selecionado.

A persistência define as consequências. O aviso FLASH do FBI FLASH-20260702-01 alerta que agentes afiliados provavelmente usarão as credenciais coletadas muito tempo após o fechamento da janela de intrusão, o que mantém o incidente ativo para qualquer organização que tenha ignorado a rotação.

Como defender a pilha de IA contra ataques à cadeia de suprimentos

Para defender a pilha de IA contra ataques à cadeia de suprimentos, as equipes de segurança implementam 8 controles, cada um voltado para uma etapa específica da cadeia de ataque. Os controles 1 e 2 pressupõem que a pilha ainda está limpa. O controle 8 pressupõe que nunca esteve.

Inventarie a pilha de IA com um AI-BOM

Crie um AI-BOM que registre cada modelo, conjunto de dados, pacote, adaptador e serviço de IA em produção, usando os formatos CycloneDX ML-BOM ou o perfil de IA do SPDX 3.0. O inventário elimina a cegueira que permite que as etapas 1 a 3 passem despercebidas, pois as equipes só defendem os componentes que sabem que existem.

Verifique a procedência antes que qualquer artefato entre na pilha

Exija modelos assinados, hashes verificados e atestados de procedência no estilo SLSA, registros que provam quem criou um artefato, a partir de quais entradas e em qual sistema, para cada pacote, checkpoint e conjunto de dados. Prefira o formato safetensors em vez da serialização pickle, já que o safetensors armazena pesos sem código executável. A procedência bloqueia a etapa 2: artefatos cuja origem ou integridade falham na verificação nunca entram na pilha.

Fixe todas as dependências em uma versão verificada

Fixe pacotes, imagens base, ações de CI e ferramentas de build em hashes exatos ou identificadores de nível de commit, em vez de tags flutuantes, e bloqueie dependências transitivas com instalações que exigem hash. 

Aplique um limite mínimo de idade de 7 dias para pacotes, um controle recomendado pelo FBI, para bloquear versões maliciosas recém-publicadas antes que a detecção da comunidade as identifique. A fixação interrompe o estágio 3, a ingestão automatizada que transformou uma janela de publicação de 40 minutos em exposição em centenas de milhares de pipelines.

Proteja os ambientes de execução de CI/CD

Execute builds em runners efêmeros com privilégios mínimos e tráfego de saída restrito a destinos aprovados. Isole segredos de etapas de build que instalam código de terceiros e monitore processos dos runners em busca de conexões de rede inesperadas.

Isso inviabiliza o estágio 4: payloads de tempo de instalação não encontram privilégios que valham a pena roubar nem rota de saída. Configure alertas para etapas de build que leiam endpoints de metadados da instância, já que quase nenhum build legítimo precisa fazer isso.

Substitua credenciais estáticas por identidades de curta duração

Emita identidades de carga de trabalho por meio de federação OIDC (OpenID Connect) em vez de armazenar chaves de nuvem de longa duração nos segredos do pipeline. Tokens de curta duração expiram antes que invasores possam reutilizá-los. A expiração anula o valor da coleta no estágio 4 e enfraquece a expansão no estágio 5.

Analise modelos e artefatos de IA em busca de ameaças incorporadas

Analise cada arquivo de modelo recebido em busca de código incorporado, comportamento suspeito de desserialização e camadas adulteradas antes do carregamento. A análise de modelos fecha a lacuna que os scanners de dependência convencionais deixam aberta, pois arquivos de pesos carregam payloads que nenhuma base de dados pública de vulnerabilidades lista.

Monitore a superfície de ataque de IA continuamente

Rastreie endpoints de modelos expostos, implantações de IA não gerenciadas, chaves de IA vazadase IA sombra, os serviços de IA que as equipes adotam fora do inventário aprovado. O monitoramento contínuo da superfície de ataque de IA detecta atividades dos estágios 5 e 6 a partir de fora, revelando os ativos de junção que os invasores escaneiam diariamente.

Prepare a rotação ampla de credenciais como doutrina permanente

Trate qualquer credencial legível por um processo comprometido como exposta até que seja validada e siga uma ordem de prioridade baseada em ondas para rotacionar credenciais após exposição em CI/CD. Primeiro, rotacione todos os segredos ao alcance do ambiente afetado, incluindo chaves de nuvem, repositório, registro, Kubernetes e provedores de IA. 

Segundo, procure por repositórios, tokens e contas de serviço não autorizados criados durante a janela de exposição. Terceiro, reconstrua os sistemas afetados a partir de fontes comprovadamente limpas. A doutrina de rotação neutraliza o estágio 6, onde credenciais roubadas sobrevivem ao pacote malicioso.

O mapeamento abaixo associa cada estágio ao controle que o interrompe. A ausência de um controle na pilha deixa seu estágio vulnerável.

O inventário de AI-BOM sustenta cada linha, pois componentes não mapeados nunca recebem nenhum desses controles.

Como a CloudSEK aborda a exposição da cadeia de suprimentos de IA

Os controles de pipeline resolvem metade do problema. A exposição visível de fora, incluindo chaves de IA vazadas, endpoints de modelos não gerenciados e implantações de gateway esquecidas, exige uma descoberta de fora para dentro, e é nessa lacuna que a CloudSEK atua.

CloudSEK AIVigil monitora a superfície de ataque de IA continuamente, descobrindo infraestrutura de IA exposta, servidores MCP, bancos de dados vetoriais, fluxos de trabalho de agentes, credenciais de IA vazadas e IA sombra antes que os invasores os encadeiem em um caminho de ataque. A plataforma correlaciona cada descoberta com a inteligência da CloudSEK Threat Intelligence, a equipe de pesquisa que reconstruiu a exposição da vítima do TeamPCP, para que as equipes de segurança vejam qual ativo exposto se conecta a qual ameaça ativa. Para riscos causados por fornecedores, o SVigil estende esse monitoramento contínuo aos ecossistemas de terceiros.

Nenhuma dessas descobertas substitui a fixação de dependências, verificações de procedência ou pipelines protegidos. O AIVigil complementa esses controles respondendo à pergunta que as ferramentas internas nunca fazem: quais partes da pilha de IA já estão visíveis para os invasores.