Ataques à Cadeia de Suprimentos em IA: O Que Incidentes Recentes Revelam Sobre a Segurança da Infraestrutura de IA

Em 24 de março de 2026, um pesquisador da FutureSearch estava envolvido em uma tarefa rotineira. A tarefa era instalar um pacote Python para um projeto. Em questão de minutos, a estação de trabalho começou a se comportar de forma errática. 

O uso da memória cresceu substancialmente. Processos não reconhecidos apareceram. O sistema travou. O pesquisador havia, sem saber, desencadeado um dos mais sofisticados ataques à cadeia de suprimentos de software já lançados contra o ecossistema de IA. Este ataque estava ativo há meses, infectando milhares de ambientes de desenvolvedores antes que alguém reconhecesse publicamente sua presença. 

Este artigo examinará os eventos que ocorreram e explicará como as ferramentas de IA são particularmente vulneráveis a esse tipo de ataque. Também discutirá como as equipes de engenharia podem se proteger.

O Que Aconteceu: Um Ataque à Cadeia de Suprimentos em Três Etapas Profundas

O grupo de atores de ameaças identificado como "TeamPCP", que está ativo desde pelo menos dezembro de 2025 e foi rastreado em nove fases deste ataque em andamento por pesquisadores da Wiz, não visou diretamente seu objetivo final. Em vez disso, este grupo de atores de ameaças realizou um ataque cuidadoso, ataque multifásico à cadeia de suprimentos.

Etapa 1: Em 19 de março, o TeamPCP comprometeu o Trivy, um scanner de segurança de código aberto amplamente utilizado e integrado aos pipelines de CI/CD de muitos projetos.

Etapa 2: Aproveitando essa brecha, eles obtiveram as credenciais de publicação do PyPI de um mantenedor de uma popular biblioteca proxy de LLM, baixada aproximadamente 3,4 milhões de vezes por dia.

Etapa 3: Em 24 de março, eles carregaram duas versões maliciosas do pacote para o PyPI. As versões comprometidas ficaram ativas por aproximadamente três horas antes que o PyPI as colocasse em quarentena.

Esta é a característica definidora dos ataques modernos à cadeia de suprimentos: o atacante nunca precisa te comprometer diretamente. Eles comprometem alguém em quem suas ferramentas confiam, e deixam que essa confiança os leve até o fim.

Anatomia do Payload: Três Estágios de Comprometimento

O pacote malicioso executou um payload sofisticado de três estágios que pesquisadores de segurança da Snyk documentaram em detalhes.

Estágio 1 — Coleta de informações. A carga maliciosa coletou silenciosamente tudo o que conseguiu encontrar: chaves privadas SSH, credenciais de acesso AWS e GCP, service principals do Azure, configurações do Kubernetes, arquivos .env, credenciais git, senhas de banco de dados, histórico de shell, segredos de CI/CD e frases semente de carteiras de criptomoedas.

Estágio 2 — Criptografia e exfiltração. Os dados coletados foram criptografados e transmitidos para um servidor controlado pelo invasor. Arquivos temporários (session.key, payload.enc, tpcp.tar.gz) foram criados no diretório temporário do sistema durante este processo.

Estágio 3 — Persistência e movimento lateral. A carga maliciosa instalou um script Python de backdoor disfarçado de serviço systemd chamado "System Telemetry Service". Este script de persistência consultava uma URL controlada pelo invasor a cada cinco minutos em busca de novos comandos — e era capaz de se espalhar por todo o seu cluster Kubernetes implantando pods privilegiados em cada nó no kube-system.

O que tornou isso especialmente perigoso foi o mecanismo de entrega: um arquivo .pth. Arquivos de configuração de caminho Python são executados automaticamente sempre que qualquer processo Python é iniciado — incluindo o próprio pip, incluindo etapas de construção de CI/CD, incluindo executores de teste. Você não precisava executar seu aplicativo. Você só precisava ter instalado o pacote, e a carga maliciosa era executada.

Por que a infraestrutura de IA é um alvo especial

O pacote afetado não foi escolhido aleatoriamente. Uma das posições mais privilegiadas na pilha de software moderna é a de proxies de Modelos de Linguagem Grandes (LLM) e gateways de IA. Ao instalar e configurar um gateway LLM, você o coloca na posição de estar diretamente entre os aplicativos e os provedores de serviços de IA que estão sendo usados. Ele tem acesso a chaves de API OpenAI, credenciais Anthropic, contas de serviço Azure e Google Cloud Platform. Ele tem acesso a variáveis de ambiente e, em muitos casos, ao gerenciador de segredos. Isso é por design e é necessário para rotear as requisições, impor limites de taxa e registrar o uso. Este é o comportamento esperado.

Isso também significa que, se o gateway LLM e/ou qualquer uma de suas dependências forem comprometidos, o invasor terá visibilidade total da infraestrutura de IA. Pesquisadores da Sonatype escreveram em seu relatório sobre este incidente: “Como o LiteLLM geralmente fica diretamente entre aplicativos e vários provedores de serviços de IA, ele frequentemente tem acesso a chaves de API, variáveis de ambiente e outros dados de configuração sensíveis. Comprometer um pacote nesta posição permite que os invasores interceptem e exfiltrem segredos valiosos sem a necessidade de violar diretamente os sistemas upstream.”

Por que os frameworks de conformidade não detectaram isso

O pacote envolvido possuía certificações SOC 2 Tipo 1 e ISO 27001. Vale a pena examinar isso não para criticar esses frameworks — eles são importantes, e as equipes que os buscam estão fazendo a coisa certa — mas porque isso ilustra uma lacuna estrutural.

Os frameworks de conformidade auditam o que você está fazendo em relação a uma lista de verificação. Eles cobrem controles de acesso, tratamento de dados e resposta a incidentes. Eles geralmente não examinam se o scanner de segurança em seu pipeline de CI/CD foi comprometido por um agente de ameaças que então se voltou para roubar suas credenciais de publicação do PyPI.

Mesmo a verificação padrão de hash do pip não teria detectado este ataque. O arquivo .pth malicioso na versão comprometida foi corretamente declarado no arquivo RECORD do pacote com um hash correspondente. O pacote passou em todas as verificações de integridade que o PyPI oferece. Era um pacote válido que foi transformado em arma.

Esta é a segurança da cadeia de suprimentos lacuna que o ecossistema de IA precisa fechar especificamente: a questão não é apenas "os nossos sistemas são seguros?". É "as ferramentas que usamos para construir e proteger os nossos sistemas são seguras?"

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Como a TrueFoundry aborda este problema

Na TrueFoundry, segurança da cadeia de suprimentos é uma preocupação primordial na forma como projetamos nossa plataforma MLOps — não um mero detalhe.

Quando as empresas implementam modelos e gateways de LLM através da TrueFoundry, fazemos um tipo diferente de pergunta: não apenas "este endpoint é seguro?", mas "qual é o raio de impacto se algum componente desta pilha for comprometido?"

Alguns princípios moldam a forma como construímos:

A infraestrutura é executada na sua VPC. Quando a sua infraestrutura de IA é executada dentro do seu próprio limite de nuvem, os segredos nunca viajam para sistemas externos. Mesmo que uma dependência em algum lugar do ecossistema fosse comprometida, o endpoint de exfiltração não seria acessível de dentro do seu perímetro de rede.

As dependências são fixadas e auditadas. Em vez de atualizar silenciosamente para a versão mais recente a cada build, a TrueFoundry mantém dependências fixadas e revisadas em toda a pilha da plataforma. Isso elimina uma classe inteira de vetor da cadeia de suprimentos.

O isolamento de componentes limita o raio de impacto. Um comprometimento em uma camada da pilha não concede automaticamente acesso a outra. Princípio do menor privilégio, aplicado no nível da infraestrutura.

Nada disso é engenharia exótica. É disciplina aplicada a um modelo de ameaça que as ferramentas de IA, como indústria, não levaram a sério o suficiente: a ameaça não está vindo através do seu firewall. Ela está vindo através do seu requirements.txt.

O Que Sua Equipe Deve Fazer Agora

Se você usa ferramentas de IA baseadas em Python, e quase toda equipe que constrói sobre LLMs o faz, as seguintes ações merecem ser priorizadas imediatamente.

1. Verifique as versões dos seus pacotes instalados. Execute pip show litellm | grep Version. Se a sua saída mostrar 1.82.7 ou 1.82.8, considere o sistema comprometido e não faça apenas uma atualização no local. O payload pode já ter sido executado. Reconstrua a partir de um estado limpo numa máquina comprovadamente segura.

2. Audite os ficheiros .pth em todas as máquinas e runners de CI.

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

3. Verifique a existência de artefactos de persistência.

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
systemctl --user status sysmon.service 2>/dev/null
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc 2>/dev/null

4. Altere as credenciais de forma agressiva. Se alguma máquina afetada teve acesso a credenciais de cloud, chaves SSH, chaves de API, tokens de conta de serviço Kubernetes ou palavras-passe de base de dados, altere todas elas agora. Não avalie — altere. O payload visou especificamente o AWS Secrets Manager, o SSM Parameter Store e os segredos de cluster Kubernetes em todos os namespaces.

5. Verifique o Kubernetes quanto a pods maliciosos.

kubectl get pods -A | grep "node-setup-"

Pods com o nome node-setup-{node_name} no namespace kube-system são um indicador conhecido de comprometimento desta campanha.

6. Avance para um registo de pacotes privado. O PyPI não é a única opção para a resolução de dependências. Um espelho de pacotes privado com hashes fixos e um fluxo de trabalho de aprovação elimina toda esta classe de vetor de ataque. Ferramentas como Artifactory, AWS CodeArtifact ou Google Artifact Registry podem servir como intermediários.

7. Trate a sua cadeia de fornecimento de CI/CD como uma superfície de ataque. O comprometimento inicial na campanha TeamPCP não foi da biblioteca alvo — foi do scanner de segurança usado no pipeline de CI dessa biblioteca. A sua infraestrutura de compilação, as suas GitHub Actions e as suas integrações de terceiros fazem todas parte da sua superfície de ataque. Audite-as em conformidade.

O Padrão Mais Amplo: Isto Não É Isolado

O que torna este caso particularmente interessante é que não foi um ataque oportunista. Pelo contrário, o TeamPCP tem vindo a executar esta campanha meticulosa desde, pelo menos, dezembro de 2025. Antes de atacar o LiteLLM, o TeamPCP comprometeu o scanner de segurança Trivy da Aqua (19 de março), as extensões do VS Code e as GitHub Actions da CheckMarx (23 de março), e múltiplos pacotes NPM contendo um worm auto-propagável.

Note-se que o par de chaves RSA utilizado é idêntico ao utilizado em todos os outros ataques, assim como o nome do pacote tpcp.tar.gz e dos repositórios GitHub com o prefixo tpcp-docs. Isto sugere que o TeamPCP é um ator de ameaça profissional que está a executar a sua campanha de forma metódica.

A implicação aqui é que as equipas que foram comprometidas por esta campanha não foram negligentes. Pelo contrário, estavam a seguir as melhores práticas: a utilizar software de código aberto muito popular e bem avaliado.

O que torna isto interessante é que o TeamPCP não identificou uma fraqueza nas defesas de uma organização específica. Pelo contrário, o TeamPCP identificou uma fraqueza na forma como o ecossistema de IA mais amplo tem abordado a confiança na sua cadeia de dependências.

O Problema de Confiança que a Infraestrutura de IA Precisa Resolver

O ecossistema de IA construiu algo extraordinário num período muito curto. A velocidade e a abertura que tornaram isso possível — a cultura de pip install e partilha, de construir sobre o trabalho uns dos outros, é genuinamente valiosa e merece ser preservada.

Mas velocidade sem segurança da cadeia de fornecimento gera dívida. A superfície de ataque de uma pilha de IA moderna não são mais apenas os endpoints que você expõe. É cada pacote na sua árvore de dependências, cada ferramenta no seu pipeline de CI/CD, cada componente de código aberto que tem acesso aos seus segredos durante a compilação ou execução.

Fechar essa lacuna exige mais do que uma melhor resposta a incidentes por parte das equipes afetadas. Exige que todo o ecossistema de infraestrutura de IA — mantenedores, fornecedores de plataforma, empresas e equipes de segurança — trate a proveniência da cadeia de suprimentos como uma preocupação de engenharia de primeira classe.

O pesquisador cuja máquina travou provavelmente não imaginava que estava prestes a expor uma campanha de meses visando a infraestrutura de IA. Nem os desenvolvedores que executaram um 'pip install' rotineiro. Essa é a natureza dos ataques à cadeia de suprimentos de software. Quando você os percebe, o dano muitas vezes já está feito.

A indústria de IA pode construir melhor. Ela precisa.

Perguntas Frequentes 

O que é um ataque à cadeia de suprimentos de software?

Um ataque à cadeia de suprimentos de software ocorre quando um agente de ameaça compromete um componente confiável a montante do alvo final — como uma ferramenta de desenvolvedor, biblioteca de código aberto ou pipeline de CI/CD — e o utiliza para distribuir código malicioso a cada usuário a jusante desse componente. Em vez de atacar uma organização diretamente, os atacantes exploram a confiança implícita que os desenvolvedores depositam em pacotes e ferramentas amplamente utilizados. 

Como as equipes de IA e ML podem proteger sua infraestrutura contra ataques à cadeia de suprimentos?

Proteger a infraestrutura de IA e ML contra ataques à cadeia de suprimentos exige várias medidas complementares. As equipes devem usar um registro de pacotes privado (como AWS CodeArtifact, Google Artifact Registry ou Artifactory) com hashes de dependência fixados, em vez de puxar diretamente do PyPI público. Auditar regularmente os arquivos .pth nos diretórios 'site-packages' do Python pode revelar adições maliciosas precocemente. Executar a infraestrutura de IA — incluindo gateways LLM e componentes de serviço de modelo — dentro de uma VPC privada limita a capacidade de um atacante de exfiltrar credenciais para servidores externos, mesmo que uma dependência seja comprometida. Manter uma Lista de Materiais de Software (SBOM) para sua pilha de ML permite uma identificação mais rápida da exposição quando um novo incidente é divulgado. Finalmente, os próprios pipelines de CI/CD devem ser tratados como superfície de ataque: as ferramentas usadas para construir e proteger software — incluindo scanners de segurança e GitHub Actions — podem ser e foram comprometidas como parte de campanhas mais amplas da cadeia de suprimentos.

Quais são os fatores que as equipes devem considerar na avaliação de um gateway LLM seguro para mitigar os riscos de ataques à cadeia de suprimentos?

O gateway LLM deve funcionar na VPC da organização. Dessa forma, se as dependências forem comprometidas, não há rotas de exfiltração. As dependências devem ser fixadas e auditadas, em vez de serem resolvidas no momento da instalação usando registros públicos. As credenciais não devem ser gerenciadas por meio de variáveis de ambiente, mas sim por meio do gerenciador de segredos nativo do provedor de nuvem. O registro de auditoria de todas as invocações de modelo, uso de chaves e alterações de configuração também deve ser realizado. Dessa forma, qualquer comportamento anormal pode ser facilmente identificado. A TrueFoundry possui todas essas configurações definidas por padrão, reduzindo assim a superfície de ataque em comparação com ferramentas de código aberto autogerenciadas.